From nobody Sun Mar 2 00:09:27 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A41A0C0D for ; Sun, 2 Mar 2014 00:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sk65AFgnjSb for ; Sun, 2 Mar 2014 00:09:18 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) by ietfa.amsl.com (Postfix) with ESMTP id 81E841A042B for ; Sun, 2 Mar 2014 00:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1393747754; l=6893; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=1jcNk8Utun/9b1d7qf/BNy2889g=; b=oDrtLylAbnR1xhQG2lokMAe2I+uStxSnl9GTBKKA9ZLGpuRGSYTym0KvdIjfRbqyB8n XFOKFiw/3DXaUQ2UQUuOPaXWdbUr2VpLPsjwpGCdnNqo2qFQrc7gX+gaW1bPamrafq8cO UvsAwVO+k4BO29nwSaLUWy40Tgw4oHdmv6A= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSEIQZmrXj X-RZG-CLASS-ID: mo00 Received: from mail-ea0-f176.google.com ([209.85.215.176]) by smtp.strato.de (RZmta 32.27 AUTH) with ESMTPSA id c0460cq2289C3sS (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - certificate not trusted)) (Client hostname not verified) for ; Sun, 2 Mar 2014 09:09:12 +0100 (CET) Received: by mail-ea0-f176.google.com with SMTP id o10so3129334eaj.35 for ; Sun, 02 Mar 2014 00:09:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=etzwyG4+X3WDv/FAty0B4wgYyXSDv4AeGQsHp9k2/c0=; b=PUKrtvaFWNHlSMa4VQ936BajFNYXapsEolOKWyJeq8PN8l6Rye5MyzCr7WoU+MND5l t/FiOLdMPsWBL9vdgUuUzxfOtc9Rb9R+iSAFH/EqU+DDP2/MCSXSPkM3feUCNaWYFJVC 73zv11FIDWZ6x/WSMruvJNmlzbdmW/tPTlHurWdhbtwFvTFWdKt5iUdXzrSq6bMvov5S dKMEVPPiG+kpfaY++XrENK068klx6oxkkQzRJxX48WeE5CHKPJQUhnL4diBj67notGRu Rg/pAgvxOHZqYkYGs0IrbkLMMt7mFK+jOmx1Pz9gBw5nv+trO85nSP/B9dUPBWoSojHx YG+A== MIME-Version: 1.0 X-Received: by 10.204.72.9 with SMTP id k9mr5481756bkj.1.1393747752265; Sun, 02 Mar 2014 00:09:12 -0800 (PST) Received: by 10.205.97.8 with HTTP; Sun, 2 Mar 2014 00:09:12 -0800 (PST) In-Reply-To: References: <5300B9E8.9050804@gmx.net> Date: Sun, 2 Mar 2014 09:09:12 +0100 Message-ID: From: Sandeep Kumar To: =?ISO-8859-1?Q?G=F6ran_Selander?= Content-Type: multipart/alternative; boundary=001a1132f326ae889804f39b2f70 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/LakC0tHWC1Dcxa7S_xbXRW_teUY Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] draft-tschofenig-ace-overview-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 08:09:22 -0000 --001a1132f326ae889804f39b2f70 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agree with G=F6ran that MIKEY is a very promising algorithm for the IoT domain. There has been some work to adapt it to the context of LLN, AMIKEY http://tools.ietf.org/html/draft-alexander-roll-mikey-lln-key-mgmt-04 That work seems to have stopped progressing. Good to check how (A)MIKEY can be used in the ACE context. regards Sandeep On Fri, Feb 28, 2014 at 2:58 PM, G=F6ran Selander wrote: > Hi Hannes, > > I have read your draft and I think it is motivating well the usefulness o= f > a three party protocol and the candidate protocols in this context. I > would like to add to the list of candidate protocols the Multimedia > Internet KEYing protocol (MIKEY, RFC 3830), or more specifically > MIKEY-TICKET (RFC 6043). > > MIKEY is a lightweight key management protocol designed for peer-to-peer, > one-to-many and small sized groups. MICKEY-TICKET is specifically > addressing the case of a trusted key management service (=B3Authorization > Server=B2) like other three party authentication protocols considered and > reuses the ticket concept from Kerberos, but also adds e.g. public-key > encryption-based key distribution and, as mentioned, group key management= . > It also has the concept of =B3Ticket Policy=B2 containing certain > authorization information. > > Clearly, Kerberos is more widely deployed, but I think this protocol > merits to be considered in the evaluation. > > > G=F6ran > > > > On 16/02/14 14:15, "Hannes Tschofenig" wrote: > > >Hi all, > > > >last Friday I have submitted a document that informs about available > >three party authentication and authorization protocols developed in the > >IETF. > > > >The described security protocols are Kerberos, OAuth, ABFAB (which > >builds on the AAA/EAP architecture), and the certificate/PKI model. > >With each protocol I provide references to the relevant specifications > >and a discussion about the pros & cons. As you can imagine, there was a > >lot of standardization work on each of these protocols and quite > >naturally there are many extensions available. Not all of them are > >relevant for the IoT context. > > > >I have not yet tried to map the features of the protocols against the > >use cases and requirements since those are obviously still in flux. For > >a future version of the document this is, however, the goal. > > > >In any case, here is the document: > >http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 > > > >I am looking forward to see your reaction to the document. > > > >Ciao > >Hannes > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a1132f326ae889804f39b2f70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree with G=F6ran that MIKEY is a very pro= mising algorithm for the IoT domain.
There has been some work to adapt = it to the context of LLN,=A0 AMIKEY http://tools.ietf.org/html/draft= -alexander-roll-mikey-lln-key-mgmt-04
That work seems to have stopped progressing. Good to check how (A)MIK= EY can be used in the ACE context.

regards
Sandeep


On Fri= , Feb 28, 2014 at 2:58 PM, G=F6ran Selander <goran.selander@er= icsson.com> wrote:
Hi Hannes,

I have read your draft and I think it is motivating well the usefulness of<= br> a three party protocol and the candidate protocols in this context. I
would like to add to the list of candidate protocols the Multimedia
Internet KEYing protocol (MIKEY, RFC 3830), or more specifically
MIKEY-TICKET (RFC 6043).

MIKEY is a lightweight key management protocol designed for peer-to-peer, one-to-many and small sized groups. MICKEY-TICKET is specifically
addressing the case of a trusted key management service (=B3Authorization Server=B2) like other three party authentication protocols considered and reuses the ticket concept from Kerberos, but also adds e.g. public-key
encryption-based key distribution and, as mentioned, group key management.<= br> It also has the concept of =B3Ticket Policy=B2 containing certain
authorization information.

Clearly, Kerberos is more widely deployed, but I think this protocol
merits to be considered in the evaluation.


G=F6ran



On 16/02/14 14:15, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:

>Hi all,
>
>last Friday I have submitted a document that informs about available >three party authentication and authorization protocols developed in the=
>IETF.
>
>The described security protocols are Kerberos, OAuth, ABFAB (which
>builds on the AAA/EAP architecture), and the certificate/PKI model.
>With each protocol I provide references to the relevant specifications<= br> >and a discussion about the pros & cons. As you can imagine, there w= as a
>lot of standardization work on each of these protocols and quite
>naturally there are many extensions available. Not all of them are
>relevant for the IoT context.
>
>I have not yet tried to map the features of the protocols against the >use cases and requirements since those are obviously still in flux. For=
>a future version of the document this is, however, the goal.
>
>In any case, here is the document:
>http://tools.ietf.org/html/draft-tschofenig-ace-overview= -00
>
>I am looking forward to see your reaction to the document.
>
>Ciao
>Hannes
>
>

_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace

--001a1132f326ae889804f39b2f70-- From nobody Sun Mar 2 07:29:46 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8461A07D9 for ; Sun, 2 Mar 2014 07:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, T_HK_NAME_DR=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBV1wLWC95mG for ; Sun, 2 Mar 2014 07:29:35 -0800 (PST) Received: from ladislav.ifi.uzh.ch (ladislav.ifi.uzh.ch [130.60.156.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2273C1A07CC for ; Sun, 2 Mar 2014 07:29:34 -0800 (PST) Received: from authenticated sender schmitt by ladislav.ifi.uzh.ch (postfix) with ESMTPSA id SA; <27C0676061> Message-ID: <53134E58.20608@ifi.uzh.ch> Date: Sun, 02 Mar 2014 16:29:28 +0100 From: "Dr. Corinna Schmitt" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ace@ietf.org References: <53086642.5050609@gmx.net> In-Reply-To: <53086642.5050609@gmx.net> Content-Type: multipart/alternative; boundary="------------070808020103020504020001" X-Virus-Scanned: clamav-milter 0.97.8 at ladislav X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ace/BczvbKrQorUAQ68iGWr-ZbQox44 Cc: Burkhard Stiller Subject: Re: [Ace] draft-schmitt-two-way-authentication-for-iot-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 15:29:42 -0000 This is a multi-part message in MIME format. --------------070808020103020504020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Hannes, > Hi Corinna, Hi Burkhard, > > thanks for your document. I have read through it and I ran into a few > questions. Your response would help me to better understand the proposed > idea. Thanks for reading the draft and make comments to it to improve it. Some comments can be answered right away. > 1) Why do you assume IEEE 802.15.4? Currently it seems that the 15.4 > radio will mostly be used in specialized industry segments only. Is > there anything in the document that would make the idea less suitable > for other radio technologies, for example BTLE? Potentially the proposed solution can work on every stack you like. So you can do an implementation independently of IEEE 802.15.4. We put IEEE 802.15.4 there, because our used stack (BLIP) uses it. > 2) The assumed network stack does not show 6lowpan. Was this intentional? Same as above. You can use the stack you want. So also 6lowpan can be used. It depends n you what you require and what you want to support. > 3) You show RPL in the stack and I was wondering whether you assume it > being mandatory to implement for your assumed architecture? It does not > seem to show up elsewhere in the document. It appears to be irrelevant > for your design. RPL was just mentioned due to our other publications. Currently our plan is to change to RPL (CoAP) in the future. > 4) Subscriber identity: You write -- > " > The identity of a default subscriber is usually preconfigured on a > publisher before it is deployed. > " > > Could you explain more what you assume is pre-configured and where it is > preconfigured? Here pre-configures means that our devices are equipped with the certification during compiling and programming them before deployment. This is due to the application scenario we support at the moment. Before deploying the device you have to run to steps: First creation of certificate, and second compiling code and play it on the device. > I would also suggest to avoid the term subscriber since it has two other > meanings that might confuse: > a) The term subscriber is often used in context of telecommunication as > the user who has a contract with a telecommunication operator. > b) The second use is in context of protocols that use asynchronous > communication (like XMPP). > > I believe your notion of subscriber does not relate to those two > existing uses. I guess you are more using the term subscriber to refer > to a device that wants some data from a sensor. Is this correct? Thanks for the hint. Yes you are right. The subscriber should be a device that wants data from the sensor. Usually this is one outside of the WSN. Do you have a suggestion for new name? > 5) Roles in your architecture. > > It seems that you assume that the IoT devices are publishers and that > there are subscribers who talk to these publishers. In some other cases > I have seen architectures where the IoT devices (sensors) upload the > data to some servers without having to act as servers themselves. In > your architecture it feels like the sensor nodes implement the > server-side functionality That was not our intention. Our network has push characteristics up to the server. Data publishing runs over server, because it has more resources and, therefore, can handle requests better. It is the gate to the world. Pull is only performed if you require data (measurements) at a time that is not pre-defined. > In Section 4.2.2 you write that you recommend an OpenSSL implementation > on the server side but the server-side would be the IoT device. While it > would be inappropriate to recommend a specific implementation in an IETF > draft/RFC it also raises the questions about the expectations on the > server-side. Thanks for the hint. We use OpenSSL on the server but not within the WSN. OpenSSL is used especially for managing rights, requests, and certificates. > 6. Certificate content > > In Section 4.2.2 you describe the content of a certificate and you > indicate that the commonName is set to "localhost". It seems to be > useless to include this in the certificate since a CA would not be able > to verify this identity information nor would any party verifying it be > able to use it in a meaningful way. Localhost in our case is a special IP address (here: sink). You are right, we should rename it and make clear that it is an IP address. So you can set is like you want. > It also seems to be in violation of what you write in Section 5.2 where > you state that "every publisher in the network MUST have an unique > identity.". > > You also indicated more complete information for inclusion in the > certificate but it is not clear to me what purpose it serves. Could you > explain? Will do it asap. > 7. Privacy > > In Section 5 you indicate some privacy related aspects and you hint to " > access regulations based on legal and regulative implications". Could > you briefly explain what those requirements are? This part we put in due to the deployment and project relations we are running at the moment. Here it means that not every device can be able to access the data, for example, due to legal issues in the region (EU, CH, US rights). This has to be stored central in the network and it has to be checked before giving access and creating the corresponding access ticket. Here we refer to the following publications: Radhika Garg, Corinna Schmitt, Burkhard Stiller: /Investigating Regulative Implications for User-generated Content and a Design Proposal/; Degruyter, PIK-Praxis der Informationsverarbeitung und Kommunikation, Vol. 36, No. 4, December 2013, ISSN 0930-5157, pp 1--11. doi:10.1515/pik-2013-0042 URL: http://www.degruyter.com/view/j/piko.ahead-of-print/pik-2013-0042/pik-2013-0042.xml Radhika Garg, Christos Tsiaras, Burkhard Stiller, Corinna Schmitt, Daniel Dönni: /Deliverable D7.1 - Basics, Requirements, Scenarios, and Architecture: In FLAMINGO/; Radhika Garg (Edt.), Zürich, Switzerland, October 2013 > 8. Use Cases. > > I suggest to omit the use cases from the document since the description > is too brief to be useful. A small remark: From my work in the emergency > services environment I had gotten the impression that there are no plans > to take sensor input directly when initiating alerts. In fact, sensor > alerts do rarely even get directly to the emergency services authorities > but are rather pre-processed by an intermediate organization (by > humans). Maybe you have spoken with other people, who have different > plans. Where did you got your information from? This section is based on discussion with our project partners within SmartenIT (www.smartenit.eu) and Flamingo ( http://www.fp7-flamingo.eu). > 9. Architecture > > Figure 3 shows the architecture but it is a bit confusing since it is > not clear what the boxes and the lines mean. The publisher is a box > separate from the sensors and from the earlier description I thought > that the sensors are actually the publishers. Furthermore, the gateway > was not discussed as a role up to that point in the document. The > gateway shows up in Section 5.3 and its role confuses me. You write: > > " A sensor node has published its data, which is transmitted in > direction to the global sink (cf. Figure 3 where global sink is > located in the gateway component). > " > > Does the sensor publish the data at the gateway? From the earlier > sections I thought that the subscriber talks to the publisher instead. > Is the gateway the subscriber? Why doesn't the sensor uploads the data > to some server instead (which is frequently done in today's IoT > deployments). Lots of comments. I will address and clarify them asap. Furthermore, I will add a legend to the Figure and perhaps modify it based on you aforementioned comments. > Why do you call the entire document "two-way authentication" when the > the two way authentication is just one small part of the overall > authentication procedure. In fact the two-way authentication is used > between the subscriber and the access control server (as shown in Figure > 4), and between the publisher and the gateway. Furthermore, there has to > be some authentication between the subscriber and the publisher as well > (at least I hope so). > > What is the purpose of the access ticket? It shows up in Section 5.3 and > I wonder why there is a need for an access ticket when the two parties > (subscriber and publisher) already have a certificate. Why cannot you > use the certificate for authentication with the publisher right away? > > Where do you see the access control server being deployed? Is this an > entity in the local network or something you would have on the Internet? > > Why does the publisher have to authenticate to the gateway? From Figure > 4 it is not clear whether the gateway is just an optional component or > an integral part of the architecture. > > The document does not explain what the access token is and how it is > exchanged between the subscriber and the publisher. > > Btw, the term CA standards for Certification Authority rather than > Certificate Authority. Will be addressed soon. > 10. Hardware requirements. > > Hardware requirements typically are not appropriate for IETF documents. > While you make the argument that an RSA-based public key cryptosystem is > good enough from a performance point of view the currently mandatory > ciphersuites used in CoAP are based on ECC (for those that rely on > asymmetric crypto). While having hardware support for key storage is a > great idea I was wondering how much your architecture actually relies on > it. My impression that it would work fine just without a TPM chip. But > you might have more hardware experience than I have. Could you point me > to some hardware that you have in mind using? > We put this section for completeness and to show that an implementation exists. Concerning sensor nodes and TPM we are using OPAL from CSIRO. Trusting Computing becomes relevant nowadays when thinking about securing data. Drawback is that if the TPM chip is broken or you change something during booting everything is lost. Advantage is that the storage root key is stored safely and only derivates are used for your applications. Hope to answer most important questions or comments now. Others will be addressed soon. You can also talk to me during IETF in London. Regards, Corinna --------------070808020103020504020001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Hannes, 
Hi Corinna, Hi Burkhard,

thanks for your document. I have read through it and I ran into a few
questions. Your response would help me to better understand the proposed
idea.
Thanks for reading the draft and make comments to it to improve it. Some comments can be answered right away. 
1) Why do you assume IEEE 802.15.4? Currently it seems that the 15.4
radio will mostly be used in specialized industry segments only. Is
there anything in the document that would make the idea less suitable
for other radio technologies, for example BTLE?
Potentially the proposed solution can work on every stack you like. So you can do an implementation independently of IEEE 802.15.4.
We put IEEE 802.15.4 there, because our used stack (BLIP) uses it. 
2) The assumed network stack does not show 6lowpan. Was this intentional?
Same as above. You can use the stack you want. So also 6lowpan can be used. It depends n you what you require and what you want to support.
3) You show RPL in the stack and I was wondering whether you assume it
being mandatory to implement for your assumed architecture? It does not
seem to show up elsewhere in the document. It appears to be irrelevant
for your design.
RPL was just mentioned due to our other publications. Currently our plan is to change to RPL (CoAP) in the future.
4) Subscriber identity: You write --
"
   The identity of a default subscriber is usually preconfigured on a
   publisher before it is deployed.
"

Could you explain more what you assume is pre-configured and where it is
preconfigured?
Here pre-configures means that our devices are equipped with the certification during compiling and programming them before deployment.
This is due to the application scenario we support at the moment. Before deploying the device you have to run to steps: First creation of certificate, and second compiling code and play it on the device.
I would also suggest to avoid the term subscriber since it has two other
meanings that might confuse:
 a) The term subscriber is often used in context of telecommunication as
the user who has a contract with a telecommunication operator.
 b) The second use is in context of protocols that use asynchronous
communication (like XMPP).

I believe your notion of subscriber does not relate to those two
existing uses. I guess you are more using the term subscriber to refer
to a device that wants some data from a sensor. Is this correct?
Thanks for the hint. Yes you are right. The subscriber should be a device that wants data from the sensor.
Usually this is one outside of the WSN. Do you have a suggestion for new name?
5) Roles in your architecture.

It seems that you assume that the IoT devices are publishers and that
there are subscribers who talk to these publishers. In some other cases
I have seen architectures where the IoT devices (sensors) upload the
data to some servers without having to act as servers themselves. In
your architecture it feels like the sensor nodes implement the
server-side functionality
That was not our intention.
Our network has push characteristics up to the server. Data publishing runs over server, because it has more resources and, therefore, can handle requests better. It is the gate to the world.
Pull is only performed if you require data (measurements) at a time that is not pre-defined. 
In Section 4.2.2 you write that you recommend an OpenSSL implementation
on the server side but the server-side would be the IoT device. While it
would be inappropriate to recommend a specific implementation in an IETF
draft/RFC it also raises the questions about the expectations on the
server-side.
Thanks for the hint.
We use OpenSSL on the server but not within the WSN. OpenSSL is used especially for managing rights, requests, and certificates.
6. Certificate content

In Section 4.2.2 you describe the content of a certificate and you
indicate that the commonName is set to "localhost". It seems to be
useless to include this in the certificate since a CA would not be able
to verify this identity information nor would any party verifying it be
able to use it in a meaningful way.
Localhost in our case is a special IP address (here: sink). You are right, we should rename it and make clear that it is an IP address. So you can set is like you want.
It also seems to be in violation of what you write in Section 5.2 where
you state that "every publisher in the network MUST have an unique
identity.".

You also indicated more complete information for inclusion in the
certificate but it is not clear to me what purpose it serves. Could you
explain?
Will do it asap.
7. Privacy

In Section 5 you indicate some privacy related aspects and you hint to "
access regulations based on legal and regulative implications". Could
you briefly explain what those requirements are?
This part we put in due to the deployment and project relations we are running at the moment.
Here it means that not every device can be able to access the data, for example, due to legal issues in the region (EU, CH, US rights).
This has to be stored central in the network and it has to be checked before giving access and creating the corresponding access ticket.
Here we refer to the following publications:

Radhika Garg, Corinna Schmitt, Burkhard Stiller: Investigating Regulative Implications for User-generated Content and a Design Proposal; Degruyter, PIK-Praxis der Informationsverarbeitung und Kommunikation, Vol. 36, No. 4, December 2013, ISSN 0930-5157, pp 1–11. doi:10.1515/pik-2013-0042 URL: http://www.degruyter.com/view/j/piko.ahead-of-print/pik-2013-0042/pik-2013-0042.xml

Radhika Garg, Christos Tsiaras, Burkhard Stiller, Corinna Schmitt, Daniel Dönni: Deliverable D7.1 - Basics, Requirements, Scenarios, and Architecture: In FLAMINGO; Radhika Garg (Edt.), Zürich, Switzerland, October 2013
8. Use Cases.

I suggest to omit the use cases from the document since the description
is too brief to be useful. A small remark: From my work in the emergency
services environment I had gotten the impression that there are no plans
to take sensor input directly when initiating alerts. In fact, sensor
alerts do rarely even get directly to the emergency services authorities
but are rather pre-processed by an intermediate organization (by
humans). Maybe you have spoken with other people, who have different
plans. Where did you got your information from?
This section is based on discussion with our project partners within SmartenIT (www.smartenit.eu) and Flamingo ( http://www.fp7-flamingo.eu).

9. Architecture

Figure 3 shows the architecture but it is a bit confusing since it is
not clear what the boxes and the lines mean. The publisher is a box
separate from the sensors and from the earlier description I thought
that the sensors are actually the publishers. Furthermore, the gateway
was not discussed as a role up to that point in the document. The
gateway shows up in Section 5.3 and its role confuses me. You write:

"  A sensor node has published its data, which is transmitted in
   direction to the global sink (cf. Figure 3 where global sink is
   located in the gateway component).
"

Does the sensor publish the data at the gateway? From the earlier
sections I thought that the subscriber talks to the publisher instead.
Is the gateway the subscriber? Why doesn't the sensor uploads the data
to some server instead (which is frequently done in today's IoT
deployments).
Lots of comments.
I will address and clarify them asap.
Furthermore, I will add a legend to the Figure and perhaps modify it based on you aforementioned comments. 
Why do you call the entire document "two-way authentication" when the
the two way authentication is just one small part of the overall
authentication procedure. In fact the two-way authentication is used
between the subscriber and the access control server (as shown in Figure
4), and between the publisher and the gateway. Furthermore, there has to
be some authentication between the subscriber and the publisher as well
(at least I hope so).

What is the purpose of the access ticket? It shows up in Section 5.3 and
I wonder why there is a need for an access ticket when the two parties
(subscriber and publisher) already have a certificate. Why cannot you
use the certificate for authentication with the publisher right away?

Where do you see the access control server being deployed? Is this an
entity in the local network or something you would have on the Internet?

Why does the publisher have to authenticate to the gateway? From Figure
4 it is not clear whether the gateway is just an optional component or
an integral part of the architecture.

The document does not explain what the access token is and how it is
exchanged between the subscriber and the publisher.

Btw, the term CA standards for Certification Authority rather than
Certificate Authority.

Will be addressed soon.
10. Hardware requirements.

Hardware requirements typically are not appropriate for IETF documents.
While you make the argument that an RSA-based public key cryptosystem is
good enough from a performance point of view the currently mandatory
ciphersuites used in CoAP are based on ECC (for those that rely on
asymmetric crypto). While having hardware support for key storage is a
great idea I was wondering how much your architecture actually relies on
it. My impression that it would work fine just without a TPM chip. But
you might have more hardware experience than I have. Could you point me
to some hardware that you have in mind using?
We put this section for completeness and to show that an implementation exists.
Concerning sensor nodes and TPM we are using OPAL from CSIRO. Trusting Computing becomes relevant nowadays when thinking about securing data. Drawback is that if the TPM chip is broken or you change something during booting everything is lost. Advantage is that the storage root key is stored safely and only derivates are used for your applications.

Hope to answer most important questions or comments now. Others will be addressed soon.
You can also talk to me during IETF in London.

Regards,
Corinna

--------------070808020103020504020001-- From nobody Mon Mar 3 03:37:13 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6893C1A0045 for ; Mon, 3 Mar 2014 03:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Fvjcqjfhj_K for ; Mon, 3 Mar 2014 03:37:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id CC9FE1A000E for ; Mon, 3 Mar 2014 03:37:09 -0800 (PST) Received: from [192.168.10.252] ([31.133.156.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MIMUZ-1WMMKE3UmF-004FVr; Mon, 03 Mar 2014 12:37:06 +0100 Message-ID: <5314695E.4040001@gmx.net> Date: Mon, 03 Mar 2014 12:37:02 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sandeep Kumar , =?ISO-8859-1?Q?G=F6ran_Selander?= References: <5300B9E8.9050804@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7TJ0i599Amb2ENJN3ilWv2EKkhUXNxCW6" X-Provags-ID: V03:K0:WommtV+wsruFFs/DdpHYS2V7ownxdThQaNIlEeXvqKaaLe+FJzF 3gtJ/tw4H1mmpNyG/H4Bn06wfNtYBZoMa0fiykrgygo+zSV3j1IBysZYvTDKsN+wLfHogTR ZT7vDVYhuZ4zytaVMjiPwRKE6ayidafwfB31sXkwVQFK4Dr1c8G9zwnsCi6LWAi25saMtrs NwooFx2MYuREZmTW6OTDw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/YwPS2C925ZsjkdDjHLcW4JxmBRA Cc: "ace@ietf.org" Subject: Re: [Ace] draft-tschofenig-ace-overview-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:37:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7TJ0i599Amb2ENJN3ilWv2EKkhUXNxCW6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't understand how MIKEY fits in here. I will have a look at the draft before I say something stupid. Ciao Hannes On 03/02/2014 09:09 AM, Sandeep Kumar wrote: > Agree with G=F6ran that MIKEY is a very promising algorithm for the IoT= > domain. > There has been some work to adapt it to the context of LLN, AMIKEY > http://tools.ietf.org/html/draft-alexander-roll-mikey-lln-key-mgmt-04 > That work seems to have stopped progressing. Good to check how (A)MIKEY= > can be used in the ACE context. >=20 > regards > Sandeep >=20 >=20 > On Fri, Feb 28, 2014 at 2:58 PM, G=F6ran Selander > > wrot= e: >=20 > Hi Hannes, >=20 > I have read your draft and I think it is motivating well the > usefulness of > a three party protocol and the candidate protocols in this context.= I > would like to add to the list of candidate protocols the Multimedia= > Internet KEYing protocol (MIKEY, RFC 3830), or more specifically > MIKEY-TICKET (RFC 6043). >=20 > MIKEY is a lightweight key management protocol designed for > peer-to-peer, > one-to-many and small sized groups. MICKEY-TICKET is specifically > addressing the case of a trusted key management service (=B3Authori= zation > Server=B2) like other three party authentication protocols consider= ed and > reuses the ticket concept from Kerberos, but also adds e.g. public-= key > encryption-based key distribution and, as mentioned, group key > management. > It also has the concept of =B3Ticket Policy=B2 containing certain > authorization information. >=20 > Clearly, Kerberos is more widely deployed, but I think this protoco= l > merits to be considered in the evaluation. >=20 >=20 > G=F6ran >=20 >=20 >=20 > On 16/02/14 14:15, "Hannes Tschofenig" > wrote: >=20 > >Hi all, > > > >last Friday I have submitted a document that informs about availab= le > >three party authentication and authorization protocols developed i= n the > >IETF. > > > >The described security protocols are Kerberos, OAuth, ABFAB (which= > >builds on the AAA/EAP architecture), and the certificate/PKI model= =2E > >With each protocol I provide references to the relevant specificat= ions > >and a discussion about the pros & cons. As you can imagine, there = was a > >lot of standardization work on each of these protocols and quite > >naturally there are many extensions available. Not all of them are= > >relevant for the IoT context. > > > >I have not yet tried to map the features of the protocols against = the > >use cases and requirements since those are obviously still in flux= =2E For > >a future version of the document this is, however, the goal. > > > >In any case, here is the document: > >http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 > > > >I am looking forward to see your reaction to the document. > > > >Ciao > >Hannes > > > > >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --7TJ0i599Amb2ENJN3ilWv2EKkhUXNxCW6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFGlfAAoJEGhJURNOOiAtnGsH/2es1S9gDcf7lsEhnhgnHTFX zlZaDcKs6s1xFHB6TsAh7V+10fIZ5FPRATPYTlJytpLaD8OyOhnaWE8vgbZI9xNP fRR2kx2xb5LpC8b/V6AmzB42QmpbiA65Q51lzVO6LEwPpQ85kVjYBbHyBFwv+9Nc mD6aqdpVl0nRg5rQBgH+TDETVMHfJ/rlk438qfzZzpl8RYYyTpYaBD7J8V5/8iE4 sWbImKOippKHr59H5tQdiyrB33bstxXhIQasXGXqvxi7npQDi0w3kyYodKjHu15W RwQ48TSAqn6rY6+CIKdgdVEjI5gAs3CYbq5bedc3e47k50g/f12osuWhVFOniag= =Y4MO -----END PGP SIGNATURE----- --7TJ0i599Amb2ENJN3ilWv2EKkhUXNxCW6-- From nobody Wed Mar 5 05:38:04 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB61A0137 for ; Wed, 5 Mar 2014 05:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCBHz25mUwmg for ; Wed, 5 Mar 2014 05:38:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DF6771A002A for ; Wed, 5 Mar 2014 05:38:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBT72620; Wed, 05 Mar 2014 13:37:56 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Mar 2014 13:37:17 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Mar 2014 13:37:46 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 5 Mar 2014 21:37:39 +0800 From: Likepeng To: "ace@ietf.org" Thread-Topic: Meeting materials Thread-Index: Ac84eBb5Q8Tb/RjtQdC9L+65HbBEng== Date: Wed, 5 Mar 2014 13:37:39 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AFF9DC@SZXEMA501-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.47.80.100] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFF9DCSZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/n43jTcW4QmYFHfmYMK67-zx3xQ4 Subject: [Ace] Meeting materials X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:38:03 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFF9DCSZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Here is the link for the materials presented during today's ACE BoF session= : https://datatracker.ietf.org/meeting/89/materials.html Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFF9DCSZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Here is the link for the materi= als presented during today’s ACE BoF session:

https://datatracker.ietf.org/meeting/89= /materials.html

 

Kind Regards<= /p>

Kepeng

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFF9DCSZXEMA501MBSchi_-- From nobody Wed Mar 5 06:32:37 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083071A014C for ; Wed, 5 Mar 2014 06:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxhE-BDRPHw2 for ; Wed, 5 Mar 2014 06:32:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 27ADB1A0641 for ; Wed, 5 Mar 2014 06:32:34 -0800 (PST) Received: from [192.168.10.132] ([31.133.156.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lt2BW-1XMdRn1d5W-012be6 for ; Wed, 05 Mar 2014 15:32:29 +0100 Message-ID: <5317357B.6020407@gmx.net> Date: Wed, 05 Mar 2014 15:32:27 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3enjJQCLaV4edW0WTOxJLmLmfiGtHItAR" X-Provags-ID: V03:K0:y1jQaXhu8qh8CWOeikr/3bh7wi0W0Uea6NZtsqzz4tMlpsIjwX1 b4lAXlvidenAAH4IAIiIguFUgTC/L0NtAZ/V6oM5PjexEz9gPNcA0GzKBCV/l4g0bjcoN2h muxhI2VeDUwjbVK5M1Aa78UgmQ6NKf5TMXKD7zwpfKkkR6ha8U4KHVR10qw9RLJYQ7EOorj z3YmcBGiFU7Cw4TDRoTbg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/YnLPogNsdjwsWDHwXTqRISwKkr8 Subject: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:32:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3enjJQCLaV4edW0WTOxJLmLmfiGtHItAR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I would like to thank you all for the great discussion today at the BOF. There was good feedback and the following scoping aspect showed up. In a nutshell there was some disagreement to purely focus on CoAP/DTLS as part of a future working group. There was not enough time to go down to the details during the session due to lack of time. Hence, I will try to clarify this aspect on the mailing list. Let us have a look at the high level architecture: +---------------+ | Authorization | +--------------------------->| Server | | (I) +---------------+ | ^ | | | | | | III | | | | | | v v +-----------+ +-----+-----+ | | II | Resource | | Client | <..................>| Server | +-----------+ +-----------+ I: This is the interaction where keying and authorization information is provided to the client. II: This is the resource access. III: This is a potential exchange necessary for having the resource server interacting with the authorization server for authenticating the client and for authorizing the client. (The exact details of the interaction depend on the specific solution, of course.) As you can see in the figure, there are various places where DTLS and CoAP should or shouldn't be used. A few persons said that they want to use other protocols besides CoAP and DTLS. Please explain me where you would like to other protocols being taken into consideration. What protocols are you considering in which of these interfaces? Ciao Hannes --3enjJQCLaV4edW0WTOxJLmLmfiGtHItAR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFzV7AAoJEGhJURNOOiAtzvoIAJGqTvj3/mXg6OHmNy0g52AJ g/UehBUblnGZmyP7Q/LKgfMXc7pF7pcWNt/tfwsw6LHAfVD5RdhrtxQvD3pvIu7X 8exmCkq+oqbBw1+TI8WnaPlSC9rq9/TKt6vgYWxVaSjJlzTG/1AvO+AG/TMN7rLq OvfGWK0g+lDNQXFPRAYQ7lsirf5CJIx+dfT/eFSkcZs9sVn5HwNbbqV/z0K4eMz6 IJXvUUtwLG+MQTTMXtS9l7h8oCFnnvIeO44iyy2QQm8qJHGERMktEqUMZnlE2eNH FnW1OOvbLkHgfhXUF9rCRnEH4OvrgxACZKOUNGO1//ZT36DgCyoCejLzV7Rw8eM= =cu+M -----END PGP SIGNATURE----- --3enjJQCLaV4edW0WTOxJLmLmfiGtHItAR-- From nobody Wed Mar 5 07:05:50 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DF81A01F2 for ; Wed, 5 Mar 2014 07:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXDiSUGNMLsP for ; Wed, 5 Mar 2014 07:05:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EABB61A0564 for ; Wed, 5 Mar 2014 07:05:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEG54466; Wed, 05 Mar 2014 15:05:26 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Mar 2014 15:02:10 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Mar 2014 15:02:41 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 5 Mar 2014 23:02:36 +0800 From: Likepeng To: "ace@ietf.org" Thread-Topic: Charter discussion Thursday afternoon 15:20 ~ 16:50, at the IETF lounge Thread-Index: Ac84g/UfjKjD87GUTbGRwIhfx7NNhQ== Date: Wed, 5 Mar 2014 15:02:36 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AFFB98@SZXEMA501-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.47.100.255] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFFB98SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/tIET7KjZWLRiTyroDCoTEJC-htc Subject: [Ace] Charter discussion Thursday afternoon 15:20 ~ 16:50, at the IETF lounge X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:05:43 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFFB98SZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Thanks for your interest about ACE BoF. As discussed during our BoF meeting, there are some open issues for the cha= rter, and we plan to have further offline discussion on Thursday afternoon,= 15:20 ~ 16:50, at the IETF lounge. If you don't have meeting conflict, please join us. Thanks, Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFFB98SZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Thanks for your interest about = ACE BoF.

 

As discussed during our BoF mee= ting, there are some open issues for the charter, and we plan to have furth= er offline discussion on Thursday afternoon, 15:20 ~ 16:50, at the IETF lou= nge.

 

If you don’t have meeting= conflict, please join us.

 

Thanks,

 

Kind Regards<= /p>

Kepeng

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AFFB98SZXEMA501MBSchi_-- From nobody Wed Mar 5 08:59:28 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923C11A01EB for ; Wed, 5 Mar 2014 08:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvTvcVroa9pU for ; Wed, 5 Mar 2014 08:59:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A81A00E9 for ; Wed, 5 Mar 2014 08:59:22 -0800 (PST) Received: from [192.168.10.133] ([31.133.156.1]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0ML72n-1WKy2x2Qi1-000Kvu for ; Wed, 05 Mar 2014 17:59:18 +0100 Message-ID: <531757E4.9050408@gmx.net> Date: Wed, 05 Mar 2014 17:59:16 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" References: <5317576C.6090400@gmx.net> In-Reply-To: <5317576C.6090400@gmx.net> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <5317576C.6090400@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="np2udL4hVgo4mQwwMndHBabhlugJ0DlEE" X-Provags-ID: V03:K0:Id1Z23V0uzP6rCpTp2mV0iVSNIsVPB/ULC1pJajKfuoGUMwx1ri RBiUStyzyH5fkQd4VCiOc1J0X5zJc4fuxNLgshAtddULPaZwxXC/fYFBD8GuIQ2VJJpKYTD Z9rUFN2Rsc1YDK4vJqPkGqpakNC9+8aVyqxLnxl4WkbnKTS+OUOW9W5lcGiMwKlYsgHZ0GV CEwIT5mFZhFWNesxNYF8Q== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/r4yP_x_bAJF02a0KtX-FO7soSqk Subject: [Ace] Fwd: [saag] IETF#89 ACE Summary X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:59:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --np2udL4hVgo4mQwwMndHBabhlugJ0DlEE Content-Type: multipart/mixed; boundary="------------080106030604040409010501" This is a multi-part message in MIME format. --------------080106030604040409010501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI: Here my short summary from the BOF (as a write-up for the SAAG). -------- Original Message -------- Subject: [saag] IETF#89 ACE Summary Date: Wed, 05 Mar 2014 17:57:16 +0100 From: Hannes Tschofenig To: saag@ietf.org We held the ACE BOF this morning from 9am to 11:30am. We started with a presentation about what constrained node networks are, explained use cases & requirements and discussed design choices. We concluded with a gap analysis. There was good support for doing the work in the IETF and there was a fair amount of feedback from the audience regarding the charter text. About 30 persons indicated that they are willing to review specifications and 15 persons said that they will be contributing documents. The feedback from the audience included: - Scope of the work Should it be focused on CoAP / DTLS only? In particular, the question about the suitability of the developed solutions for HTTP and SMS transport was raised. - Assumptions What assumptions are being made by the use cases in terms of requirement for a clock, interworking with existing infrastructure, interaction with proxies, and intermittent connectivity of different parties (off-line use cases). - Provisioning of credentials and other configuration parameters Participants suggested to consider looking at the entire life cycle of these IoT devices to prevent problems later with provisioning. While those do not necessarily be standardized in this group there was a desire to avoid later problems. As next steps the charter discussions will have to continue to resolve some of the raised questions. The BOF chairs encouraged the audience to develop strawman proposals to gain further experience about the underlying assumptions. Ciao Hannes --------------080106030604040409010501 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --------------080106030604040409010501-- --np2udL4hVgo4mQwwMndHBabhlugJ0DlEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTF1fkAAoJEGhJURNOOiAtqR4IAI2aOlv5KGPo+2PAWZ6pHctU 9WHi10MRVaf1zkQuRuxPUlunNTR/8+bJI0/HdXEQQl/JWAAeErc3jbUbn0FntlVs 64YVxUA6VR3n4H+cp5aFm7XrNZ3GVJGotaNdYwa/2f6PzEE291QxsGrR8qsCCwMB 5zyhQqEpISOV0V+bGRtQStbW5qBa6BazzCrsKQwWrpQqe7w1NXDGJVnqDy2jBcaH KdefbX6Y21ZXZmI63KoEUNCkmm2x+gyI7W1YyQMkfBxapaKR7CtkDSCtrDTTm6Eb Zi8QgQPDvagNaPArLvl9CeQSsEqD2hvB1euNcn7DQ1XTHhk0Ef+g6xv1y04S3bo= =XPQZ -----END PGP SIGNATURE----- --np2udL4hVgo4mQwwMndHBabhlugJ0DlEE-- From nobody Wed Mar 5 10:24:31 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49101A01A0 for ; Wed, 5 Mar 2014 10:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0hY0qgiMSwC for ; Wed, 5 Mar 2014 10:24:28 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id CC9091A0157 for ; Wed, 5 Mar 2014 10:24:23 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-18-53176bd3f2b6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 27.8E.04853.3DB67135; Wed, 5 Mar 2014 19:24:19 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 19:23:01 +0100 From: =?Windows-1252?Q?G=F6ran_Selander?= To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] Scope of the ACE Charter Thread-Index: AQHPOH/Ac8HmUR+Qg0a24PkLLktiB5rSvh6A Date: Wed, 5 Mar 2014 18:23:00 +0000 Message-ID: References: <5317357B.6020407@gmx.net> In-Reply-To: <5317357B.6020407@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje7lbPFgg31PJC2+f+thtli68x6r A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJVxfs0apoKzIhUXG++yNTAe4+li5OSQEDCR uL3kKBOELSZx4d56ti5GLg4hgROMEvcbTjJCOIsZJebeP8wGUsUm4C7xuGcjC4gtIhAkcbjx NVCcg0NYQFui8Z0eRFhH4tKBlewgYREBI4lL2wJATBYBFYm9DaogFbwC5hKXlx8AaxQSUJNo WegBEuYUUJf40XaUHcRmBLrm+6k1YJcxC4hL3HoyH+pKAYkle84zQ9iiEi8f/2MFsUUF9CTu PZrLAhFXklh7eDsLRK+BxPtz85lBVjELWEsc7AuGCGtLLFv4mhniGkGJkzOfsExgFJ+FZNss JN2zELpnIemehaR7ASPrKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2MwGg7uOW30Q7G k3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDo0Sp4W2BfX5vsOYWl 3mLTfCv9p+0oj5LpqbsY9FS1c+lLN3ter+3Nl8S3TlSxmSbgFLZ/0xHOL9d/5jvYiprx7Dg7 c1ew0MLe3RvS4iacvPFTeZWC20nN5avvfvjzYN/ztRlxQpWl1iv3PcmYnusyYd2/F87fYt74 xa5zSjm7eX+Pm5LVegluJZbijERDLeai4kQAivF8lIQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ILB8XwhbcK_mOExcHBdzXHbONpg Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:24:30 -0000 Hi Hannes, Just looking at interface (I): If the client is not constrained I think HTTP/TLS should be an option to COAP/DTLS. Adding to the discussion about HTTP/COAP proxies in the meeting: If both the authorisation information and the keying information is object secure (JWT, CMS, =8A) there is no need to trust the proxy. G=F6ran On 05/03/14 14:32, "Hannes Tschofenig" wrote: >Hi all, > >I would like to thank you all for the great discussion today at the BOF. >There was good feedback and the following scoping aspect showed up. > >In a nutshell there was some disagreement to purely focus on CoAP/DTLS >as part of a future working group. > >There was not enough time to go down to the details during the session >due to lack of time. Hence, I will try to clarify this aspect on the >mailing list. > >Let us have a look at the high level architecture: > > +---------------+ > | Authorization | > +--------------------------->| Server | > | (I) +---------------+ > | ^ > | | > | | > | | III > | | > | | > | | > v v > +-----------+ +-----+-----+ > | | II | Resource | > | Client | <..................>| Server | > +-----------+ +-----------+ > >I: This is the interaction where keying and authorization information is >provided to the client. > >II: This is the resource access. > >III: This is a potential exchange necessary for having the resource >server interacting with the authorization server for authenticating the >client and for authorizing the client. > >(The exact details of the interaction depend on the specific solution, >of course.) > >As you can see in the figure, there are various places where DTLS and >CoAP should or shouldn't be used. > >A few persons said that they want to use other protocols besides CoAP >and DTLS. > >Please explain me where you would like to other protocols being taken >into consideration. What protocols are you considering in which of these >interfaces? > >Ciao >Hannes > From nobody Wed Mar 5 10:35:21 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A311A0072 for ; Wed, 5 Mar 2014 10:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wssEPPu1NfK for ; Wed, 5 Mar 2014 10:35:15 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03CA61A0128 for ; Wed, 5 Mar 2014 10:35:14 -0800 (PST) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Wed, 05 Mar 2014 18:35:10 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Wed, 5 Mar 2014 10:35:15 -0800 From: Zach Shelby To: =?Windows-1252?Q?G=F6ran_Selander?= Date: Wed, 5 Mar 2014 10:35:08 -0800 Thread-Topic: [Ace] Scope of the ACE Charter Thread-Index: Ac84oaYHispxPOsFQCSl80IkScv6KA== Message-ID: <5C0365A6-995F-4500-8147-DDD35CD43EA0@arm.com> References: <5317357B.6020407@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114030518351002202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ace/IQB9X0KEVnWkteYvQ-1fiZO75fU Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:35:18 -0000 Hi, One of the "other" things mentioned was SMS, but that was just a misunderst= anding. They were looking for DTLS support for SMS, which would be somethin= g for the TLS working group and not ACE. And with such support, of course t= hat is CoAP/DTLS. So no issues on that one. I think that on any one of those interfaces either CoAP/DTLS or HTTP/TLS co= uld be used depending on the node and network. (ii) will typically be CoAP/= DTLS as this is the whole point of the working group. (i) and possibly (iii= ) could be either. Being the one that brought up the "proxy" issue, I probably used a really p= oor choice of words there. What I really meant was this duality of an HTTP/= TLS based solution (OAuth) or a CoAP/DTLS solution on those interfaces, but= choose one and run it end-to-end. Zach On Mar 5, 2014, at 6:23 PM, G=F6ran Selander = wrote: > Hi Hannes, > > > Just looking at interface (I): If the client is not constrained I think > HTTP/TLS should be an option to COAP/DTLS. > > Adding to the discussion about HTTP/COAP proxies in the meeting: If both > the authorisation information and the keying information is object secure > (JWT, CMS, =8A) there is no need to trust the proxy. > > > > G=F6ran > > > > > On 05/03/14 14:32, "Hannes Tschofenig" wrote: > >> Hi all, >> >> I would like to thank you all for the great discussion today at the BOF. >> There was good feedback and the following scoping aspect showed up. >> >> In a nutshell there was some disagreement to purely focus on CoAP/DTLS >> as part of a future working group. >> >> There was not enough time to go down to the details during the session >> due to lack of time. Hence, I will try to clarify this aspect on the >> mailing list. >> >> Let us have a look at the high level architecture: >> >> +---------------+ >> | Authorization | >> +--------------------------->| Server | >> | (I) +---------------+ >> | ^ >> | | >> | | >> | | III >> | | >> | | >> | | >> v v >> +-----------+ +-----+-----+ >> | | II | Resource | >> | Client | <..................>| Server | >> +-----------+ +-----------+ >> >> I: This is the interaction where keying and authorization information is >> provided to the client. >> >> II: This is the resource access. >> >> III: This is a potential exchange necessary for having the resource >> server interacting with the authorization server for authenticating the >> client and for authorizing the client. >> >> (The exact details of the interaction depend on the specific solution, >> of course.) >> >> As you can see in the figure, there are various places where DTLS and >> CoAP should or shouldn't be used. >> >> A few persons said that they want to use other protocols besides CoAP >> and DTLS. >> >> Please explain me where you would like to other protocols being taken >> into consideration. What protocols are you considering in which of these >> interfaces? >> >> Ciao >> Hannes >> > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Thu Mar 6 05:23:00 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3B1A02FA for ; Thu, 6 Mar 2014 05:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8JowtGAYmcb for ; Thu, 6 Mar 2014 05:22:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 540441A02EF for ; Thu, 6 Mar 2014 05:22:47 -0800 (PST) Received: from [192.168.10.136] ([31.133.156.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MFtf4-1WRXjY2ky6-00EstY for ; Thu, 06 Mar 2014 14:22:42 +0100 Message-ID: <531876A0.7030301@gmx.net> Date: Thu, 06 Mar 2014 14:22:40 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gm01QHEfkuLIK0MDrFJKMTBeudo1TE82V" X-Provags-ID: V03:K0:uIfqxa93Op6eR8XMsNN0SVCk0JX7wf3AqFSYOe9gQxBPzGkPFcA j295EjG4U4USvBkpCMjArbWgSQlFSgGG87EIZovnh0qXNqvFLjV61kThAKWgqomRSOmgGoP gEblFpLqH0hY33KQ0m+OA3yA9W4OEl2cTzScjgj58I14Pj2n1VChK27hqE/D/H2XYx7F212 XwZ91uLkWAxDHsIisQfwQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/-u8VVW_A92K-c7OHGweGw1v4-hM Subject: [Ace] IoT Chill-out on Friday, 5pm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:22:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gm01QHEfkuLIK0MDrFJKMTBeudo1TE82V Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I was wondering whether some of you are still around on Friday afternoon. In case there is interest to have a relaxed chat (maybe with a drink) with IoT-minded persons I would suggest to gather in the Hilton hotel bar at 5pm. Feel free to forward the message to other IoT-related groups. Ciao Hannes --gm01QHEfkuLIK0MDrFJKMTBeudo1TE82V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTGHagAAoJEGhJURNOOiAtF9wH/3mEp9vOrWomB069uexreKdh 0r8Wca7JlQYNXPwY8A2FYa+S6EWah94yBmLMwv2dQKZYYzf3VN/qSKCH6LBM6Ii3 R/AbF1o3jjaxYlUcGx6/r59CKDEv8NByirYGMKVeWCzQArM2iUUbB6weIguX25wW oLmJ4RSiHkimqBfI//a5dG6SOfM/veN2IKFJNqSxohWgMe0cG6JzuAFaA4VcWEND pEq/6Z8Q2F12iaS/byY2cskUob+m9D3ZKSzIjmsvXXSclk8sB5tiKBtPxHVElBsQ RVpvrWFxTbhB/rgbpD9Ia8P0ylf9bwpbsLxVUlQEvZAlU5QyAhSjOm87padrAjw= =SFMW -----END PGP SIGNATURE----- --gm01QHEfkuLIK0MDrFJKMTBeudo1TE82V-- From nobody Thu Mar 6 05:48:59 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDDC1A0249 for ; Thu, 6 Mar 2014 05:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvz4PFNkf6IK for ; Thu, 6 Mar 2014 05:48:55 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 085781A023E for ; Thu, 6 Mar 2014 05:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s26Dmig3002251; Thu, 6 Mar 2014 14:48:44 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CE90F87A; Thu, 6 Mar 2014 14:48:43 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <531876A0.7030301@gmx.net> Date: Thu, 6 Mar 2014 13:48:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1B90F0BA-119C-4317-BB1B-675B5FE19096@tzi.org> References: <531876A0.7030301@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/FEt4fHmQT2B8I6SdzSBd6cRyci8 Cc: "ace@ietf.org" Subject: Re: [Ace] IoT Chill-out on Friday, 5pm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:48:57 -0000 On 06 Mar 2014, at 13:22, Hannes Tschofenig = wrote: > Hi all, >=20 > I was wondering whether some of you are still around on Friday > afternoon. In case there is interest to have a relaxed chat (maybe = with > a drink) with IoT-minded persons I would suggest to gather in the = Hilton > hotel bar at 5pm. At that time, some of us are over at the Marriott hotel plugtesting away = at CoAP, DTLS, OMA LWM2M, and 6LoWPAN. http://www.etsi.org/news-events/events/741-plugtests-2014-coap4 (JFYI in case you wonder whether implementers don=92t socialize :-) Gr=FC=DFe, Carsten From nobody Thu Mar 6 05:51:10 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87B1A0129 for ; Thu, 6 Mar 2014 05:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJRiHz_pmfoQ for ; Thu, 6 Mar 2014 05:51:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4C12D1A027C for ; Thu, 6 Mar 2014 05:51:03 -0800 (PST) Received: from [192.168.10.136] ([31.133.156.1]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0McEI3-1Wf0h31PSZ-00Ja80; Thu, 06 Mar 2014 14:50:58 +0100 Message-ID: <53187D40.7060206@gmx.net> Date: Thu, 06 Mar 2014 14:50:56 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carsten Bormann References: <531876A0.7030301@gmx.net> <1B90F0BA-119C-4317-BB1B-675B5FE19096@tzi.org> In-Reply-To: <1B90F0BA-119C-4317-BB1B-675B5FE19096@tzi.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XKUBLmM9UFANSpM4b2aIMcSLhNTS9qt4b" X-Provags-ID: V03:K0:jZxxDK2GVJOhTGzGLIjx+17kPGUbtlJlf+VsigxmxidS0ARHu78 3FUr5Cr5QUxT0jqikLGaWUCxRpmrY3s5HQdrc3NhqVXP8YtICzaeJRjPv3OGaRCtRGzx3w7 vRoNtMbLGjCFkmDX6M3EFpoUSP6zSfwQZv6bK9gaHvgwxX/7oqqbBk0qoCmxUiiyYHrioCx z5kn3Ocz79zbKjJGAMyag== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/4veNZdtyeJmd0FVgM4F6dQTzZE8 Cc: "ace@ietf.org" Subject: Re: [Ace] IoT Chill-out on Friday, 5pm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:51:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XKUBLmM9UFANSpM4b2aIMcSLhNTS9qt4b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Carsten. I hope that the plugtesting event will finish at some point in time. The webpage does not indicate when it finishes on the Friday. It would be great if implementers could join. On 03/06/2014 02:48 PM, Carsten Bormann wrote: > On 06 Mar 2014, at 13:22, Hannes Tschofenig = wrote: >=20 >> Hi all, >> >> I was wondering whether some of you are still around on Friday >> afternoon. In case there is interest to have a relaxed chat (maybe wit= h >> a drink) with IoT-minded persons I would suggest to gather in the Hilt= on >> hotel bar at 5pm. >=20 > At that time, some of us are over at the Marriott hotel plugtesting awa= y at CoAP, DTLS, OMA LWM2M, and 6LoWPAN. >=20 > http://www.etsi.org/news-events/events/741-plugtests-2014-coap4 >=20 > (JFYI in case you wonder whether implementers don=92t socialize :-) >=20 > Gr=FC=DFe, Carsten >=20 --XKUBLmM9UFANSpM4b2aIMcSLhNTS9qt4b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTGH1AAAoJEGhJURNOOiAtLtwH/0hi5G0axZQlX3sWEdgb4gUd m9HIRvZ6Gr0E2vLsSS1CGqYHh1tWII5iTVhdy/3A8loED/CBvCsL/XlJJ5m1blIJ E5H+fPE+5oOSJPRIp1Jo+MhuAOAJ3bWjN95v+zmPNK/h+48H0GRosXzzrKSthdWi UdqKr3Uo9GiIqoNMuuT6QxmFqiWQRqotJLiQYsGqZcNiF4KJbfamBcDtOjLcs7+q KNUjps2beNvJ/u0lskBnzSDVanzUUs03XQ/JFJAoaQ33OhMPiFCZieVbbjPbnwbM F5+BwOvXFWgE4mSHFNKIqZYD3Zzt9CeoeXo2r8FG8P44rQdQ/CaxBojiXP6SJIY= =00xe -----END PGP SIGNATURE----- --XKUBLmM9UFANSpM4b2aIMcSLhNTS9qt4b-- From nobody Thu Mar 6 05:52:37 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127091A02FE for ; Thu, 6 Mar 2014 05:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G82I8WpEJXGw for ; Thu, 6 Mar 2014 05:52:27 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CE4021A02CD for ; Thu, 6 Mar 2014 05:52:18 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id t60so3145108wes.33 for ; Thu, 06 Mar 2014 05:52:14 -0800 (PST) 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; bh=gVXfy4xbJdUVJcM5Tc8B80P5PGkV/eFKh1h5HgxYM18=; b=q37iBt/I32KiUrQezuGFGhCSxIA37xOp8NdNFzLwxJzNIyCJzKkq/vHym2R7lKmqlY AwzDoZfmlfWJMU4Va3Iex754Nk/68GP1MGlNXuwivRMwyNfKaNuyMls3ORidwW8ktkZ+ pXOKjFJXx42EO2T4ZJ2jLUquNJJ12SmkbURl+GEN7cPoXDbynvFOe1DAyUFWhACG/Xgk YJz32z3viuotGNbpci4XFgDVUbMbCjBFgBl58Kft04gWz0d0RRnB4R2pTnAiom2mpQ+4 zpQ+T5WsC8iGUAE4CQe6Y3ghuqPs44ZPQtr2sDi+Jb2pK367ciJWL80KKGpV35r5b4is dh/A== X-Received: by 10.194.57.77 with SMTP id g13mr10418772wjq.42.1394113934499; Thu, 06 Mar 2014 05:52:14 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:4125:cd84:aadb:6635? ([2001:67c:370:160:4125:cd84:aadb:6635]) by mx.google.com with ESMTPSA id ux5sm17262112wjc.6.2014.03.06.05.52.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 05:52:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPad Mail (11B651) In-Reply-To: <531876A0.7030301@gmx.net> Date: Thu, 6 Mar 2014 13:52:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <531876A0.7030301@gmx.net> To: Hannes Tschofenig Archived-At: http://mailarchive.ietf.org/arch/msg/ace/R0oSLkiwV_qQqhHTOJ4lCayAqPI Cc: "ace@ietf.org" Subject: Re: [Ace] IoT Chill-out on Friday, 5pm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:52:33 -0000 Thanks for the invitation Hannes ... I'll be on my way out of London then, s= o I won't b able to join you. - Ralph > On Mar 6, 2014, at 1:22 PM, Hannes Tschofenig w= rote: >=20 > Hi all, >=20 > I was wondering whether some of you are still around on Friday > afternoon. In case there is interest to have a relaxed chat (maybe with > a drink) with IoT-minded persons I would suggest to gather in the Hilton > hotel bar at 5pm. >=20 > Feel free to forward the message to other IoT-related groups. >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Mar 6 06:55:21 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA21A000D for ; Thu, 6 Mar 2014 06:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCqxLrZ414cB for ; Thu, 6 Mar 2014 06:55:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5DCC1A0002 for ; Thu, 6 Mar 2014 06:55:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEH53433; Thu, 06 Mar 2014 14:55:11 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 14:51:41 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 14:52:12 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 22:52:02 +0800 From: Likepeng To: Likepeng , "ace@ietf.org" Thread-Topic: Charter discussion Thursday afternoon 15:20 ~ 16:50, at the IETF lounge Thread-Index: Ac84g/UfjKjD87GUTbGRwIhfx7NNhQAx5OUA Date: Thu, 6 Mar 2014 14:52:01 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B00E57@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AFFB98@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252AFFB98@SZXEMA501-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.47.84.239] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B00E57SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/O7nkMc3xuvFdR6fwfVGRrvhfxNA Subject: Re: [Ace] Charter discussion Thursday afternoon 15:20 ~ 16:50, at the IETF lounge X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:55:18 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B00E57SZXEMA501MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UmVtaW5kZXIuDQoNClNlZSB5b3Ugc29vbiENCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0Kt6K8 /sjLOiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMaWtlcGVuZw0Kt6LL zcqxvOQ6IDIwMTTE6jPUwjXI1SAxNTowMw0KytW8/sjLOiBhY2VAaWV0Zi5vcmcNCtb3zOI6IFtB Y2VdIENoYXJ0ZXIgZGlzY3Vzc2lvbiBUaHVyc2RheSBhZnRlcm5vb24gMTU6MjAgfiAxNjo1MCwg YXQgdGhlIElFVEYgbG91bmdlDQoNCkhlbGxvIGFsbCwNCg0KVGhhbmtzIGZvciB5b3VyIGludGVy ZXN0IGFib3V0IEFDRSBCb0YuDQoNCkFzIGRpc2N1c3NlZCBkdXJpbmcgb3VyIEJvRiBtZWV0aW5n LCB0aGVyZSBhcmUgc29tZSBvcGVuIGlzc3VlcyBmb3IgdGhlIGNoYXJ0ZXIsIGFuZCB3ZSBwbGFu IHRvIGhhdmUgZnVydGhlciBvZmZsaW5lIGRpc2N1c3Npb24gb24gVGh1cnNkYXkgYWZ0ZXJub29u LCAxNToyMCB+IDE2OjUwLCBhdCB0aGUgSUVURiBsb3VuZ2UuDQoNCklmIHlvdSBkb26hr3QgaGF2 ZSBtZWV0aW5nIGNvbmZsaWN0LCBwbGVhc2Ugam9pbiB1cy4NCg0KVGhhbmtzLA0KDQpLaW5kIFJl Z2FyZHMNCktlcGVuZw0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B00E57SZXEMA501MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Reminde= r.

&n= bsp;

See you= soon!

&n= bsp;

Kind Re= gards

Kepeng<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: Ace [mailto:ace-bounces@ietf.org] =B4=FA=B1=ED = Likepeng
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA3=D4=C2<= span lang=3D"EN-US">5=C8=D5 15:03
=CA=D5=BC=FE=C8=CB: ace@ietf.org
=D6=F7=CC=E2: [Ace] Charter discussion Thursday afternoon 15:20 ~ 16:50, at the IETF lo= unge

 

Hello all,

 

Thanks for your interest about = ACE BoF.

 

As discussed during our BoF mee= ting, there are some open issues for the charter, and we plan to have furth= er offline discussion on Thursday afternoon, 15:20 ~ 16:50, at the IETF lou= nge.

 

If you don=A1=AFt have meeting = conflict, please join us.

 

Thanks,

 

Kind Regards<= /p>

Kepeng

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B00E57SZXEMA501MBSchi_-- From nobody Thu Mar 6 07:43:35 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8281A0165 for ; Thu, 6 Mar 2014 07:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxG3L_p65886 for ; Thu, 6 Mar 2014 07:43:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0601A0064 for ; Thu, 6 Mar 2014 07:43:26 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s26FhImG017801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Mar 2014 15:43:19 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s26FhHAe022658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2014 15:43:18 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s26FhHqE003603; Thu, 6 Mar 2014 15:43:17 GMT Received: from [31.133.163.210] (/31.133.163.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Mar 2014 07:43:17 -0800 References: <531876A0.7030301@gmx.net> <1B90F0BA-119C-4317-BB1B-675B5FE19096@tzi.org> <53187D40.7060206@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <53187D40.7060206@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Phil Hunt Date: Thu, 6 Mar 2014 15:43:10 +0000 To: Hannes Tschofenig X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/ace/4B9o098T0fEx_hXsB9T_WgGE_yY Cc: Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] IoT Chill-out on Friday, 5pm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:43:32 -0000 Is the meeting in the lounge happening today? Phil > On Mar 6, 2014, at 13:50, Hannes Tschofenig wr= ote: >=20 > Thanks, Carsten. >=20 > I hope that the plugtesting event will finish at some point in time. > The webpage does not indicate when it finishes on the Friday. >=20 > It would be great if implementers could join. >=20 >> On 03/06/2014 02:48 PM, Carsten Bormann wrote: >>> On 06 Mar 2014, at 13:22, Hannes Tschofenig w= rote: >>>=20 >>> Hi all, >>>=20 >>> I was wondering whether some of you are still around on Friday >>> afternoon. In case there is interest to have a relaxed chat (maybe with >>> a drink) with IoT-minded persons I would suggest to gather in the Hilton= >>> hotel bar at 5pm. >>=20 >> At that time, some of us are over at the Marriott hotel plugtesting away a= t CoAP, DTLS, OMA LWM2M, and 6LoWPAN. >>=20 >> http://www.etsi.org/news-events/events/741-plugtests-2014-coap4 >>=20 >> (JFYI in case you wonder whether implementers don=E2=80=99t socialize :-)= >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Mar 6 07:50:24 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817461A0111 for ; Thu, 6 Mar 2014 07:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvnpkbpHTCza for ; Thu, 6 Mar 2014 07:50:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F91A0048 for ; Thu, 6 Mar 2014 07:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s26FoCk6005682; Thu, 6 Mar 2014 16:50:12 +0100 (CET) Received: from aung.tzi.org (dhcp-9b50.meeting.ietf.org [31.133.155.80]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40D26951; Thu, 6 Mar 2014 16:50:12 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <531876A0.7030301@gmx.net> <1B90F0BA-119C-4317-BB1B-675B5FE19096@tzi.org> <53187D40.7060206@gmx.net> Date: Thu, 06 Mar 2014 15:50:11 +0000 In-Reply-To: <53187D40.7060206@gmx.net> (Hannes Tschofenig's message of "Thu, 06 Mar 2014 14:50:56 +0100") Message-ID: <87fvmvqqbw.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/ace/JhRXOUEN2Ox5NRhyTN6O7l_k65s Cc: Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] IoT Chill-out on Friday, 5pm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:50:19 -0000 Hannes Tschofenig writes: > Thanks, Carsten. > > I hope that the plugtesting event will finish at some point in time. > The webpage does not indicate when it finishes on the Friday. The updated schedule from today has set the end of the last test slot to 7:30pm. Gruesse Olaf From nobody Thu Mar 6 11:12:28 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0FD1A010A for ; Thu, 6 Mar 2014 11:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKhLQSCb-Dv4 for ; Thu, 6 Mar 2014 11:12:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62D1A0088 for ; Thu, 6 Mar 2014 11:12:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBU92865; Thu, 06 Mar 2014 19:12:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 19:11:42 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 19:12:16 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 7 Mar 2014 03:12:10 +0800 From: Likepeng To: Phil Hunt , Hannes Tschofenig Thread-Topic: [Ace] Charter discussion Thursday afternoon 15:20 ~ 16:50, at the IETF lounge Thread-Index: AQHPOW/4mpdZAETcO0q9Tap0qE+YjA== Date: Thu, 6 Mar 2014 19:12:09 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B01092@SZXEMA501-MBS.china.huawei.com> References: <531876A0.7030301@gmx.net> <1B90F0BA-119C-4317-BB1B-675B5FE19096@tzi.org> <53187D40.7060206@gmx.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.125.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/F9tBTSd1Ti8Aqkr7XMpECIIFmms Cc: Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] Charter discussion Thursday afternoon 15:20 ~ 16:50, at the IETF lounge X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:12:26 -0000 SGkgUGhpbCwNCg0KWWVzLCBpdCB3YXMgZmluaXNoZWQgYXQgNTowMCB0b2RheS4gDQoNCkJhc2lj YWxseSB3ZSBkaXNjdXNzZWQgdGhlIGZlZWRiYWNrcyByZWNlaXZlZCBmcm9tIHllc3RlcmRheSdz IEJvRiBtZWV0aW5nLCBtYWlubHkgYWJvdXQgY2hhcnRlciBpc3N1ZSBhbmQgc2NvcGUgaXNzdWUu DQoNCldlIGFzc2lnbmVkIHNvbWUgYWN0aW9ucyB0byByZXdvcmQgdGhlIGNoYXJ0ZXIgdGV4dHMs IGFuZCBob3BlIG5ldyBwcm9wb3NlZCB0ZXh0cyBjYW4gYmUgc2VudCBvdXQgdG8gdGhlIGxpc3Qg Zm9yIGRpc2N1c3Npb24gc29vbi4NCg0KVGhhbmtzLA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0K DQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEFjZSBbbWFpbHRvOmFjZS1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggUGhpbCBIdW50DQrlj5HpgIHml7bpl7Q6IDIwMTTlubQz5pyI NuaXpSAxNTo0Mw0K5pS25Lu25Lq6OiBIYW5uZXMgVHNjaG9mZW5pZw0K5oqE6YCBOiBDYXJzdGVu IEJvcm1hbm47IGFjZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW0FjZV0gSW9UIENoaWxsLW91dCBv biBGcmlkYXksIDVwbQ0KDQpJcyB0aGUgbWVldGluZyBpbiB0aGUgbG91bmdlIGhhcHBlbmluZyB0 b2RheT8NCg0KUGhpbA0KDQo+IE9uIE1hciA2LCAyMDE0LCBhdCAxMzo1MCwgSGFubmVzIFRzY2hv ZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPiANCj4gVGhhbmtzLCBD YXJzdGVuLg0KPiANCj4gSSBob3BlIHRoYXQgdGhlIHBsdWd0ZXN0aW5nIGV2ZW50IHdpbGwgZmlu aXNoIGF0IHNvbWUgcG9pbnQgaW4gdGltZS4NCj4gVGhlIHdlYnBhZ2UgZG9lcyBub3QgaW5kaWNh dGUgd2hlbiBpdCBmaW5pc2hlcyBvbiB0aGUgRnJpZGF5Lg0KPiANCj4gSXQgd291bGQgYmUgZ3Jl YXQgaWYgaW1wbGVtZW50ZXJzIGNvdWxkIGpvaW4uDQo+IA0KPj4gT24gMDMvMDYvMjAxNCAwMjo0 OCBQTSwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KPj4+IE9uIDA2IE1hciAyMDE0LCBhdCAxMzoy MiwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0K Pj4+IA0KPj4+IEhpIGFsbCwNCj4+PiANCj4+PiBJIHdhcyB3b25kZXJpbmcgd2hldGhlciBzb21l IG9mIHlvdSBhcmUgc3RpbGwgYXJvdW5kIG9uIEZyaWRheSANCj4+PiBhZnRlcm5vb24uIEluIGNh c2UgdGhlcmUgaXMgaW50ZXJlc3QgdG8gaGF2ZSBhIHJlbGF4ZWQgY2hhdCAobWF5YmUgDQo+Pj4g d2l0aCBhIGRyaW5rKSB3aXRoIElvVC1taW5kZWQgcGVyc29ucyBJIHdvdWxkIHN1Z2dlc3QgdG8g Z2F0aGVyIGluIA0KPj4+IHRoZSBIaWx0b24gaG90ZWwgYmFyIGF0IDVwbS4NCj4+IA0KPj4gQXQg dGhhdCB0aW1lLCBzb21lIG9mIHVzIGFyZSBvdmVyIGF0IHRoZSBNYXJyaW90dCBob3RlbCBwbHVn dGVzdGluZyBhd2F5IGF0IENvQVAsIERUTFMsIE9NQSBMV00yTSwgYW5kIDZMb1dQQU4uDQo+PiAN Cj4+IGh0dHA6Ly93d3cuZXRzaS5vcmcvbmV3cy1ldmVudHMvZXZlbnRzLzc0MS1wbHVndGVzdHMt MjAxNC1jb2FwNA0KPj4gDQo+PiAoSkZZSSBpbiBjYXNlIHlvdSB3b25kZXIgd2hldGhlciBpbXBs ZW1lbnRlcnMgZG9u4oCZdCBzb2NpYWxpemUgOi0pDQo+PiANCj4+IEdyw7zDn2UsIENhcnN0ZW4N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEFjZSBtYWlsaW5nIGxpc3QNCj4gQWNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWNlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo= From nobody Thu Mar 6 11:19:57 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF101A01AE for ; Thu, 6 Mar 2014 11:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTEg5jo9pX-y for ; Thu, 6 Mar 2014 11:19:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 844FB1A0160 for ; Thu, 6 Mar 2014 11:19:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBU93177; Thu, 06 Mar 2014 19:19:45 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 19:19:12 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 19:19:43 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 7 Mar 2014 03:19:40 +0800 From: Likepeng To: "ace@ietf.org" Thread-Topic: ACE BoF summary for CoRE session Thread-Index: Ac85cQJbnl4tQzrrTDebdx+nx1pHCw== Date: Thu, 6 Mar 2014 19:19:40 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.125.83] Content-Type: multipart/mixed; boundary="_004_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/97qHhanPams8mOcBQ2kXWSgJUZo Subject: [Ace] ACE BoF summary for CoRE session X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:19:53 -0000 --_004_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_ Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_" --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Hannes and I made ACE BoF summary slides and it will be presented in CoRE s= ession tomorrow. Welcome to join CoRE session tomorrow. Thanks, Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Hannes and I made ACE BoF summa= ry slides and it will be presented in CoRE session tomorrow.

 

Welcome to join CoRE session to= morrow.

 

Thanks,

 

Kind Regards<= /p>

Kepeng

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_-- --_004_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_ Content-Type: application/vnd.ms-powerpoint; name="ACE BoF Summary_CoRE.ppt" Content-Description: ACE BoF Summary_CoRE.ppt Content-Disposition: attachment; filename="ACE BoF Summary_CoRE.ppt"; size=184832; creation-date="Thu, 06 Mar 2014 10:41:45 GMT"; modification-date="Thu, 06 Mar 2014 10:41:45 GMT" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAZgEAAAAAAAAA EAAA/v///wAAAAD+////AAAAAGMBAABkAQAAZQEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////+g Rh3wYmoAAHD45sFqdeMkgsKP6GeqtTH//9j/4AAQSkZJRgABAgEASABIAAD/4QORRXhpZgAATU0A KgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAEx AAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRv YmUgUGhvdG9zaG9wIENTMiBNYWNpbnRvc2gAMjAwODoxMDoyMCAxMzoyNjozOAAAA6ABAAMAAAAB //8AAKACAAQAAAABAAAEAKADAAQAAAABAAAAFQAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEA AAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAJbAAAAAAAA AEgAAAABAAAASAAAAAH/2P/gABBKRklGAAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2Jl AGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAAwCgAwEiAAIRAQMRAf/dAAQACv/EAT8A AAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoL EAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT 8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2 xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFC I8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE 1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A8+SWWkoWi6iSy0kl OokstJJTqJLLSSU6iSy0klOokstJJTqJLLSSU6iSy0klOokstJJTqJLLSSU//9n/7SawUGhvdG9z aG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAAAAAAAAAAAAAAOEJJTQPqAAAAAB2mPD94bWwgdmVy c2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHBsaXN0IFBVQkxJQyAiLS8v QXBwbGUgQ29tcHV0ZXIvL0RURCBQTElTVCAxLjAvL0VOIiAiaHR0cDovL3d3dy5hcHBsZS5jb20v RFREcy9Qcm9wZXJ0eUxpc3QtMS4wLmR0ZCI+CjxwbGlzdCB2ZXJzaW9uPSIxLjAiPgo8ZGljdD4K CTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1Ib3Jpem9udGFsUmVzPC9rZXk+Cgk8 ZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCTxzdHJp bmc+Y29tLmFwcGxlLnByaW50aW5nbWFuYWdlcjwvc3RyaW5nPgoJCTxrZXk+Y29tLmFwcGxlLnBy aW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQk8YXJyYXk+CgkJCTxkaWN0PgoJCQkJPGtleT5j b20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTUhvcml6b250YWxSZXM8L2tleT4KCQkJCTxyZWFs PjcyPC9yZWFsPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNsaWVudDwva2V5PgoJ CQkJPHN0cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJCQk8a2V5PmNv bS5hcHBsZS5wcmludC50aWNrZXQubW9kRGF0ZTwva2V5PgoJCQkJPGRhdGU+MjAwOC0xMC0yMFQx MDoyNjoxNlo8L2RhdGU+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFn PC9rZXk+CgkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQk8L2RpY3Q+CgkJPC9hcnJheT4KCTwv ZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1PcmllbnRhdGlvbjwva2V5 PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQk8 c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1PcmllbnRhdGlvbjwva2V5PgoJCQkJPGlu dGVnZXI+MTwvaW50ZWdlcj4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jbGllbnQ8 L2tleT4KCQkJCTxzdHJpbmc+Y29tLmFwcGxlLnByaW50aW5nbWFuYWdlcjwvc3RyaW5nPgoJCQkJ PGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lm1vZERhdGU8L2tleT4KCQkJCTxkYXRlPjIwMDgt MTAtMjBUMTA6MjY6MTZaPC9kYXRlPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0 YXRlRmxhZzwva2V5PgoJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJy YXk+Cgk8L2RpY3Q+Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNU2NhbGluZzwv a2V5PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4K CQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQk8a2V5PmNvbS5h cHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJ CTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1TY2FsaW5nPC9rZXk+CgkJCQk8cmVh bD4xPC9yZWFsPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNsaWVudDwva2V5PgoJ CQkJPHN0cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJCQk8a2V5PmNv bS5hcHBsZS5wcmludC50aWNrZXQubW9kRGF0ZTwva2V5PgoJCQkJPGRhdGU+MjAwOC0xMC0yMFQx MDoyNjoxNlo8L2RhdGU+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFn PC9rZXk+CgkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQk8L2RpY3Q+CgkJPC9hcnJheT4KCTwv ZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1WZXJ0aWNhbFJlczwva2V5 PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQk8 c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1WZXJ0aWNhbFJlczwva2V5PgoJCQkJPHJl YWw+NzI8L3JlYWw+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY2xpZW50PC9rZXk+ CgkJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQkJCTxrZXk+ Y29tLmFwcGxlLnByaW50LnRpY2tldC5tb2REYXRlPC9rZXk+CgkJCQk8ZGF0ZT4yMDA4LTEwLTIw VDEwOjI2OjE2WjwvZGF0ZT4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZs YWc8L2tleT4KCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCTwvZGljdD4KCQk8L2FycmF5PgoJ PC9kaWN0PgoJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTVZlcnRpY2FsU2NhbGlu Zzwva2V5PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tl eT4KCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQk8a2V5PmNv bS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4K CQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1WZXJ0aWNhbFNjYWxpbmc8L2tl eT4KCQkJCTxyZWFsPjE8L3JlYWw+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY2xp ZW50PC9rZXk+CgkJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4K CQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5tb2REYXRlPC9rZXk+CgkJCQk8ZGF0ZT4y MDA4LTEwLTIwVDEwOjI2OjE2WjwvZGF0ZT4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tl dC5zdGF0ZUZsYWc8L2tleT4KCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCTwvZGljdD4KCQk8 L2FycmF5PgoJPC9kaWN0PgoJPGtleT5jb20uYXBwbGUucHJpbnQuc3ViVGlja2V0LnBhcGVyX2lu Zm9fdGlja2V0PC9rZXk+Cgk8ZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0 LlBNQWRqdXN0ZWRQYWdlUmVjdDwva2V5PgoJCTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmlu dC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFn ZXI8L3N0cmluZz4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5 PgoJCQk8YXJyYXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9y bWF0LlBNQWRqdXN0ZWRQYWdlUmVjdDwva2V5PgoJCQkJCTxhcnJheT4KCQkJCQkJPHJlYWw+MC4w PC9yZWFsPgoJCQkJCQk8cmVhbD4wLjA8L3JlYWw+CgkJCQkJCTxyZWFsPjc4MzwvcmVhbD4KCQkJ CQkJPHJlYWw+NTU5PC9yZWFsPgoJCQkJCTwvYXJyYXk+CgkJCQkJPGtleT5jb20uYXBwbGUucHJp bnQudGlja2V0LmNsaWVudDwva2V5PgoJCQkJCTxzdHJpbmc+Y29tLmFwcGxlLnByaW50aW5nbWFu YWdlcjwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5tb2REYXRlPC9r ZXk+CgkJCQkJPGRhdGU+MjAwOC0xMC0yMFQxMDoyNjoxNlo8L2RhdGU+CgkJCQkJPGtleT5jb20u YXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5PgoJCQkJCTxpbnRlZ2VyPjA8L2ludGVn ZXI+CgkJCQk8L2RpY3Q+CgkJCTwvYXJyYXk+CgkJPC9kaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnBy aW50LlBhZ2VGb3JtYXQuUE1BZGp1c3RlZFBhcGVyUmVjdDwva2V5PgoJCTxkaWN0PgoJCQk8a2V5 PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCQk8c3RyaW5nPmNvbS5hcHBs ZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0 Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJyYXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBs ZS5wcmludC5QYWdlRm9ybWF0LlBNQWRqdXN0ZWRQYXBlclJlY3Q8L2tleT4KCQkJCQk8YXJyYXk+ CgkJCQkJCTxyZWFsPi0xODwvcmVhbD4KCQkJCQkJPHJlYWw+LTE4PC9yZWFsPgoJCQkJCQk8cmVh bD44MjQ8L3JlYWw+CgkJCQkJCTxyZWFsPjU3NzwvcmVhbD4KCQkJCQk8L2FycmF5PgoJCQkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jbGllbnQ8L2tleT4KCQkJCQk8c3RyaW5nPmNvbS5h cHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50 aWNrZXQubW9kRGF0ZTwva2V5PgoJCQkJCTxkYXRlPjIwMDgtMTAtMjBUMTA6MjY6MTZaPC9kYXRl PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8 aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8 a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1QYXBlck5hbWU8L2tleT4KCQk8ZGljdD4K CQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5j b20uYXBwbGUucHJpbnQucG0uUG9zdFNjcmlwdDwvc3RyaW5nPgoJCQk8a2V5PmNvbS5hcHBsZS5w cmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJCTxhcnJheT4KCQkJCTxkaWN0PgoJCQkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mby5QTVBhcGVyTmFtZTwva2V5PgoJCQkJCTxzdHJp bmc+aXNvLWE0PC9zdHJpbmc+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNsaWVu dDwva2V5PgoJCQkJCTxzdHJpbmc+Y29tLmFwcGxlLnByaW50LnBtLlBvc3RTY3JpcHQ8L3N0cmlu Zz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQubW9kRGF0ZTwva2V5PgoJCQkJCTxk YXRlPjIwMDMtMDctMDFUMTc6NDk6MzZaPC9kYXRlPgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50 LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4xPC9pbnRlZ2VyPgoJCQkJPC9k aWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlcklu Zm8uUE1VbmFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUu cHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUucHJpbnQucG0u UG9zdFNjcmlwdDwvc3RyaW5nPgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFy cmF5PC9rZXk+CgkJCTxhcnJheT4KCQkJCTxkaWN0PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50 LlBhcGVySW5mby5QTVVuYWRqdXN0ZWRQYWdlUmVjdDwva2V5PgoJCQkJCTxhcnJheT4KCQkJCQkJ PHJlYWw+MC4wPC9yZWFsPgoJCQkJCQk8cmVhbD4wLjA8L3JlYWw+CgkJCQkJCTxyZWFsPjc4Mzwv cmVhbD4KCQkJCQkJPHJlYWw+NTU5PC9yZWFsPgoJCQkJCTwvYXJyYXk+CgkJCQkJPGtleT5jb20u YXBwbGUucHJpbnQudGlja2V0LmNsaWVudDwva2V5PgoJCQkJCTxzdHJpbmc+Y29tLmFwcGxlLnBy aW50aW5nbWFuYWdlcjwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5t b2REYXRlPC9rZXk+CgkJCQkJPGRhdGU+MjAwOC0xMC0yMFQxMDoyNjoxNlo8L2RhdGU+CgkJCQkJ PGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5PgoJCQkJCTxpbnRlZ2Vy PjA8L2ludGVnZXI+CgkJCQk8L2RpY3Q+CgkJCTwvYXJyYXk+CgkJPC9kaWN0PgoJCTxrZXk+Y29t LmFwcGxlLnByaW50LlBhcGVySW5mby5QTVVuYWRqdXN0ZWRQYXBlclJlY3Q8L2tleT4KCQk8ZGlj dD4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmlu Zz5jb20uYXBwbGUucHJpbnQucG0uUG9zdFNjcmlwdDwvc3RyaW5nPgoJCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJCTxhcnJheT4KCQkJCTxkaWN0PgoJCQkJ CTxrZXk+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mby5QTVVuYWRqdXN0ZWRQYXBlclJlY3Q8L2tl eT4KCQkJCQk8YXJyYXk+CgkJCQkJCTxyZWFsPi0xODwvcmVhbD4KCQkJCQkJPHJlYWw+LTE4PC9y ZWFsPgoJCQkJCQk8cmVhbD44MjQ8L3JlYWw+CgkJCQkJCTxyZWFsPjU3NzwvcmVhbD4KCQkJCQk8 L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jbGllbnQ8L2tleT4KCQkJ CQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQkJCQk8a2V5PmNv bS5hcHBsZS5wcmludC50aWNrZXQubW9kRGF0ZTwva2V5PgoJCQkJCTxkYXRlPjIwMDgtMTAtMjBU MTA6MjY6MTZaPC9kYXRlPgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZs YWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5 PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8ucHBkLlBNUGFwZXJO YW1lPC9rZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9y PC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLnByaW50LnBtLlBvc3RTY3JpcHQ8L3N0cmluZz4K CQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJyYXk+ CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8ucHBkLlBNUGFw ZXJOYW1lPC9rZXk+CgkJCQkJPHN0cmluZz5BNDwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFwcGxl LnByaW50LnRpY2tldC5jbGllbnQ8L2tleT4KCQkJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludC5w bS5Qb3N0U2NyaXB0PC9zdHJpbmc+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lm1v ZERhdGU8L2tleT4KCQkJCQk8ZGF0ZT4yMDAzLTA3LTAxVDE3OjQ5OjM2WjwvZGF0ZT4KCQkJCQk8 a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVnZXI+ MTwvaW50ZWdlcj4KCQkJCTwvZGljdD4KCQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5jb20u YXBwbGUucHJpbnQudGlja2V0LkFQSVZlcnNpb248L2tleT4KCQk8c3RyaW5nPjAwLjIwPC9zdHJp bmc+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnByaXZhdGVMb2NrPC9rZXk+CgkJPGZh bHNlLz4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQudHlwZTwva2V5PgoJCTxzdHJpbmc+ Y29tLmFwcGxlLnByaW50LlBhcGVySW5mb1RpY2tldDwvc3RyaW5nPgoJPC9kaWN0PgoJPGtleT5j b20uYXBwbGUucHJpbnQudGlja2V0LkFQSVZlcnNpb248L2tleT4KCTxzdHJpbmc+MDAuMjA8L3N0 cmluZz4KCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5wcml2YXRlTG9jazwva2V5PgoJPGZh bHNlLz4KCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC50eXBlPC9rZXk+Cgk8c3RyaW5nPmNv bS5hcHBsZS5wcmludC5QYWdlRm9ybWF0VGlja2V0PC9zdHJpbmc+CjwvZGljdD4KPC9wbGlzdD4K OEJJTQPpAAAAAAB4AAMAAABIAEgAAAAAAw8CL//u/+4DOAJBA2cFewPgAAIAAABIAEgAAAAAAtgC KAABAAAAZAAAAAEAAwMDAAAAAX//AAEAAQAAAAAAAAAAAAAAAGgIABkBkAAAAAAAIAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAA DgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAA AAkAAAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAA AABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAAB ADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gA AAAA/////////////////////////////wPoAAAAAP////////////////////////////8D6AAA AAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4 QklNBDAAAAAAAAEBADhCSU0ELQAAAAAABgABAAAAAjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAA AAA4QklNBB4AAAAAAAQAAAAAOEJJTQQaAAAAAANJAAAABgAAAAAAAAAAAAAAFQAABAAAAAAKAFUA bgB0AGkAdABsAGUAZAAtADMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAABAAAAAAV AAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAA AAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9u ZwAAAAAAAAAAQnRvbWxvbmcAAAAVAAAAAFJnaHRsb25nAAAEAAAAAAZzbGljZXNWbExzAAAAAU9i amMAAAABAAAAAAAFc2xpY2UAAAASAAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAA AAAAAAAGb3JpZ2luZW51bQAAAAxFU2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBl ZW51bQAAAApFU2xpY2VUeXBlAAAAAEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAA BAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAFQAAAABSZ2h0 bG9uZwAABAAAAAADdXJsVEVYVAAAAAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAA AAEAAAAAAAZhbHRUYWdURVhUAAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRl eHRURVhUAAAAAQAAAAAACWhvcnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1 bHQAAAAJdmVydEFsaWduZW51bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0Nv bG9yVHlwZWVudW0AAAARRVNsaWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25n AAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmln aHRPdXRzZXRsb25nAAAAAAA4QklNBCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhC SU0EFAAAAAAABAAAAAI4QklNBAwAAAAAAncAAAABAAAAoAAAAAMAAAHgAAAFoAAAAlsAGAAB/9j/ 4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJ CAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDP/AABEIAAMAoAMBIgACEQEDEQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAAD AAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwz AQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXC o3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3 EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNz NPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APPkllpKFouokstJJTqJLLSSU6iSy0klOokstJJT qJLLSSU6iSy0klOokstJJTqJLLSSU6iSy0klP//ZADhCSU0EIQAAAAAAVQAAAAEBAAAADwBBAGQA bwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAAABMAQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABv AHAAIABDAFMAMgAAAAEAOEJJTQQGAAAAAAAHAAYAAAABAQD/4TqzaHR0cDovL25zLmFkb2JlLmNv bS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEu MS0xMTIiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIv MjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgog ICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgog ICAgICAgICA8ZGM6Zm9ybWF0PmltYWdlL2pwZWc8L2RjOmZvcm1hdD4KICAgICAgPC9yZGY6RGVz Y3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAg IHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4YXA6 Q3JlYXRvclRvb2w+QWRvYmUgUGhvdG9zaG9wIENTMiBNYWNpbnRvc2g8L3hhcDpDcmVhdG9yVG9v bD4KICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDgtMTAtMjBUMTM6MjY6MzgrMDM6MDA8L3hh cDpDcmVhdGVEYXRlPgogICAgICAgICA8eGFwOk1vZGlmeURhdGU+MjAwOC0xMC0yMFQxMzoyNjoz OCswMzowMDwveGFwOk1vZGlmeURhdGU+CiAgICAgICAgIDx4YXA6TWV0YWRhdGFEYXRlPjIwMDgt MTAtMjBUMTM6MjY6MzgrMDM6MDA8L3hhcDpNZXRhZGF0YURhdGU+CiAgICAgIDwvcmRmOkRlc2Ny aXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4 bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIKICAgICAgICAgICAg eG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJl ZiMiPgogICAgICAgICA8eGFwTU06RG9jdW1lbnRJRD51dWlkOjY4N0JCNjZCQTAzQzExRERCREND RjA0OURGOUI3RTlFPC94YXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eGFwTU06SW5zdGFuY2VJ RD51dWlkOjY4N0JCNjZDQTAzQzExRERCRENDRjA0OURGOUI3RTlFPC94YXBNTTpJbnN0YW5jZUlE PgogICAgICAgICA8eGFwTU06RGVyaXZlZEZyb20gcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgog ICAgICAgICAgICA8c3RSZWY6aW5zdGFuY2VJRD51dWlkOjY4N0JCNjZBQTAzQzExRERCRENDRjA0 OURGOUI3RTlFPC9zdFJlZjppbnN0YW5jZUlEPgogICAgICAgICAgICA8c3RSZWY6ZG9jdW1lbnRJ RD51dWlkOjY4N0JCNjZBQTAzQzExRERCRENDRjA0OURGOUI3RTlFPC9zdFJlZjpkb2N1bWVudElE PgogICAgICAgICA8L3hhcE1NOkRlcml2ZWRGcm9tPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4K ICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6dGlm Zj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iPgogICAgICAgICA8dGlmZjpPcmllbnRh dGlvbj4xPC90aWZmOk9yaWVudGF0aW9uPgogICAgICAgICA8dGlmZjpYUmVzb2x1dGlvbj43MjAw MDAvMTAwMDA8L3RpZmY6WFJlc29sdXRpb24+CiAgICAgICAgIDx0aWZmOllSZXNvbHV0aW9uPjcy MDAwMC8xMDAwMDwvdGlmZjpZUmVzb2x1dGlvbj4KICAgICAgICAgPHRpZmY6UmVzb2x1dGlvblVu aXQ+MjwvdGlmZjpSZXNvbHV0aW9uVW5pdD4KICAgICAgICAgPHRpZmY6TmF0aXZlRGlnZXN0PjI1 NiwyNTcsMjU4LDI1OSwyNjIsMjc0LDI3NywyODQsNTMwLDUzMSwyODIsMjgzLDI5NiwzMDEsMzE4 LDMxOSw1MjksNTMyLDMwNiwyNzAsMjcxLDI3MiwzMDUsMzE1LDMzNDMyOzA2NDEzRDA1MzA4RTUy RUNFRTYxQUUwQTQ4Mjg4M0IyPC90aWZmOk5hdGl2ZURpZ2VzdD4KICAgICAgPC9yZGY6RGVzY3Jp cHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHht bG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6 UGl4ZWxYRGltZW5zaW9uPjEwMjQ8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAgICA8ZXhp ZjpQaXhlbFlEaW1lbnNpb24+MjE8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICAgICA8ZXhp ZjpDb2xvclNwYWNlPi0xPC9leGlmOkNvbG9yU3BhY2U+CiAgICAgICAgIDxleGlmOk5hdGl2ZURp Z2VzdD4zNjg2NCw0MDk2MCw0MDk2MSwzNzEyMSwzNzEyMiw0MDk2Miw0MDk2MywzNzUxMCw0MDk2 NCwzNjg2NywzNjg2OCwzMzQzNCwzMzQzNywzNDg1MCwzNDg1MiwzNDg1NSwzNDg1NiwzNzM3Nywz NzM3OCwzNzM3OSwzNzM4MCwzNzM4MSwzNzM4MiwzNzM4MywzNzM4NCwzNzM4NSwzNzM4NiwzNzM5 Niw0MTQ4Myw0MTQ4NCw0MTQ4Niw0MTQ4Nyw0MTQ4OCw0MTQ5Miw0MTQ5Myw0MTQ5NSw0MTcyOCw0 MTcyOSw0MTczMCw0MTk4NSw0MTk4Niw0MTk4Nyw0MTk4OCw0MTk4OSw0MTk5MCw0MTk5MSw0MTk5 Miw0MTk5Myw0MTk5NCw0MTk5NSw0MTk5Niw0MjAxNiwwLDIsNCw1LDYsNyw4LDksMTAsMTEsMTIs MTMsMTQsMTUsMTYsMTcsMTgsMjAsMjIsMjMsMjQsMjUsMjYsMjcsMjgsMzA7QTdFQkM4NEE3MzFG NzY2QjgwODhBNDI1MUE0NUQwQjM8L2V4aWY6TmF0aXZlRGlnZXN0PgogICAgICA8L3JkZjpEZXNj cmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAg eG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIj4KICAg ICAgICAgPHBob3Rvc2hvcDpIaXN0b3J5Lz4KICAgICAgICAgPHBob3Rvc2hvcDpDb2xvck1vZGU+ MzwvcGhvdG9zaG9wOkNvbG9yTW9kZT4KICAgICAgICAgPHBob3Rvc2hvcDpJQ0NQcm9maWxlPkFk b2JlIFJHQiAoMTk5OCk8L3Bob3Rvc2hvcDpJQ0NQcm9maWxlPgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94 cGFja2V0IGVuZD0idyI/Pv/uAA5BZG9iZQBkQAAAAAH/2wCEAAICAgICAgICAgIDAgICAwQDAgID BAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwMDAwBAwMDBQQFCQYGCQ0K CQoNDw4ODg4PDwwMDAwMDw8MDAwMDAwPDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEI ABUEAAMBEQACEQEDEQH/3QAEAID/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAIC AwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNh InGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSU RUaktFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJio uMjY6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQh EjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2 RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn 9zhIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APkN mvfP3Yq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXY q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq 7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7 FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7F XYq7FXYq7FXYq7FXYq//0PkNmvfP3Yq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq 7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7 FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7F XYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX Yq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq//0fkNmvfP3Yq7FXYq7FXYq7FXYq7FXYq7 FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7F XYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX Yq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXY q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq//2QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAPAOgDWiEAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAEAAAACAAAAAgAAAAAAAAABAAAAAAEA AQ8ACQQADAAAAAAKBAQAAAAmAAAADwDXD7wAAAAAANMPBAAAAA4AAAAAALoPJAAAAEgAaQBnAGgA IABsAGUAdgBlAGwAIABzAHUAbQBtAGEAcgB5ABAAug98AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu AGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBhAGMA ZQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAMwAwADkALgBoAHQAbQBsAA8A1w8QAQAAAADT DwQAAAAQAAAAAAC6D3oAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8A cAByAG8AYwBlAGUAZABpAG4AZwBzAC8AOAA5AC8AcwBsAGkAZABlAHMALwBzAGwAaQBkAGUAcwAt ADgAOQAtAGEAYwBlAC0AMgAuAHAAZABmABAAug96AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkA ZQB0AGYALgBvAHIAZwAvAHAAcgBvAGMAZQBlAGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBz AC8AcwBsAGkAZABlAHMALQA4ADkALQBhAGMAZQAtADIALgBwAGQAZgAPANcPEAEAAAAA0w8EAAAA EgAAAAAAug96AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAHAAcgBv AGMAZQBlAGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkAZABlAHMALQA4ADkA LQBhAGMAZQAtADMALgBwAGQAZgAQALoPegAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABm AC4AbwByAGcALwBwAHIAbwBjAGUAZQBkAGkAbgBnAHMALwA4ADkALwBzAGwAaQBkAGUAcwAvAHMA bABpAGQAZQBzAC0AOAA5AC0AYQBjAGUALQAzAC4AcABkAGYADwDXDxQBAAAAANMPBAAAABQAAAAA ALoPfAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBwAHIAbwBjAGUA ZQBkAGkAbgBnAHMALwA4ADkALwBzAGwAaQBkAGUAcwAvAHMAbABpAGQAZQBzAC0AOAA5AC0AYQBj AGUALQA0AC4AcABwAHQAeAAQALoPfAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4A bwByAGcALwBwAHIAbwBjAGUAZQBkAGkAbgBnAHMALwA4ADkALwBzAGwAaQBkAGUAcwAvAHMAbABp AGQAZQBzAC0AOAA5AC0AYQBjAGUALQA0AC4AcABwAHQAeAAPANcPFAEAAAAA0w8EAAAAFgAAAAAA ug98AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAHAAcgBvAGMAZQBl AGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkAZABlAHMALQA4ADkALQBhAGMA ZQAtADUALgBwAHAAdAB4ABAAug98AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBv AHIAZwAvAHAAcgBvAGMAZQBlAGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkA ZABlAHMALQA4ADkALQBhAGMAZQAtADUALgBwAHAAdAB4AA8A1w/GAAAAAADTDwQAAAAYAAAAAAC6 Dy4AAABtAGEAaQBsAGkAbgBnACAAbABpAHMAdAAgAGQAaQBzAGMAdQBzAHMAaQBvAG4AEAC6D3wA AABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBj AGgAaQB2AGUALwB3AGUAYgAvAGEAYwBlAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAAzADAA NwAuAGgAdABtAGwADwDXD7wAAAAAANMPBAAAABsAAAAAALoPJAAAAEgAaQBnAGgAIABsAGUAdgBl AGwAIABzAHUAbQBtAGEAcgB5ABAAug98AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYA LgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBhAGMAZQAvAGMAdQBy AHIAZQBuAHQALwBtAHMAZwAwADAAMwAwADkALgBoAHQAbQBsAA8A1w8QAQAAAADTDwQAAAAeAAAA AAC6D3oAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AcAByAG8AYwBl AGUAZABpAG4AZwBzAC8AOAA5AC8AcwBsAGkAZABlAHMALwBzAGwAaQBkAGUAcwAtADgAOQAtAGEA YwBlAC0AMgAuAHAAZABmABAAug96AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBv AHIAZwAvAHAAcgBvAGMAZQBlAGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkA ZABlAHMALQA4ADkALQBhAGMAZQAtADIALgBwAGQAZgAPANcPEAEAAAAA0w8EAAAAHwAAAAAAug96 AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAHAAcgBvAGMAZQBlAGQA aQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkAZABlAHMALQA4ADkALQBhAGMAZQAt ADMALgBwAGQAZgAQALoPegAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcA LwBwAHIAbwBjAGUAZQBkAGkAbgBnAHMALwA4ADkALwBzAGwAaQBkAGUAcwAvAHMAbABpAGQAZQBz AC0AOAA5AC0AYQBjAGUALQAzAC4AcABkAGYADwDXDxQBAAAAANMPBAAAACIAAAAAALoPfAAAAGgA dAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBwAHIAbwBjAGUAZQBkAGkAbgBn AHMALwA4ADkALwBzAGwAaQBkAGUAcwAvAHMAbABpAGQAZQBzAC0AOAA5AC0AYQBjAGUALQA0AC4A cABwAHQAeAAQALoPfAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBw AHIAbwBjAGUAZQBkAGkAbgBnAHMALwA4ADkALwBzAGwAaQBkAGUAcwAvAHMAbABpAGQAZQBzAC0A OAA5AC0AYQBjAGUALQA0AC4AcABwAHQAeAAPANcPFAEAAAAA0w8EAAAAJQAAAAAAug98AAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAHAAcgBvAGMAZQBlAGQAaQBuAGcA cwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkAZABlAHMALQA4ADkALQBhAGMAZQAtADUALgBw AHAAdAB4ABAAug98AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAHAA cgBvAGMAZQBlAGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkAZABlAHMALQA4 ADkALQBhAGMAZQAtADUALgBwAHAAdAB4AA8A1w/GAAAAAADTDwQAAAAmAAAAAAC6Dy4AAABtAGEA aQBsAGkAbgBnACAAbABpAHMAdAAgAGQAaQBzAGMAdQBzAHMAaQBvAG4AEAC6D3wAAABoAHQAdABw ADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUA LwB3AGUAYgAvAGEAYwBlAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAAzADAANwAuAGgAdABt AGwADwDyA6wBAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QfkAAAAAAC3D0QAAABBAHIAaQBhAGwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE ABAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAABCIgALcPRAAAAEMAYQBsAGkAYgByAGkAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQiAACkDwgAAACAAEAAAAAAAAAA pQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgALBAAAQACjD24AAAAFAP/9PwAAACIgAABk AAAAAP8AAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASAB AAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwREAQAADwAA8DwBAAAA AAbwmAAAAAFEAAASAAAASQAAABEAAAABAAAABAAAABAAAAAGAAAAEQAAAAcAAAAFAAAABQAAAAcA AAAEAAAACAAAAAQAAAAJAAAABAAAAAoAAAAEAAAACwAAAAQAAAAMAAAABAAAAA0AAAAEAAAADgAA ABMAAAAPAAAABAAAAAQAAAAIAAAABgAAAAUAAAADAAAAAQAAAAIAAAABAAAAHwAB8CwAAABSAAfw JAAAAAUFcPjmwWp14ySCwo/oZ6q1Mf8AamoAAAIAAAAAAAAAAAAAAIMAC/AwAAAAgQEEAAAIgwEA AAAIhsEAAAAAvwEQABAAwAEBAAAIxcEAAAAA/wEIAAgAAQICAAAIQAAa8RAAAABNTU0AMzMzABc0 FwD/MwAAQAAe8RAAAAACAAAIAQAACAIAAAj3AAAQHwDwD1QAAAAAAPMDFAAAAAMAAAAAAAAAAAAA AA0AAIAAAAAAAADzAxQAAAAEAAAABAAAAAAAAACnAACAAAAAAAAA8wMUAAAABQAAAAAAAAAAAAAA qAAAgAAAAAAPANAHdgIAAB8AFAQcAAAAAAAVBBQAAAC6k7D2AMqaO60HlMcAypo7AQEAAB8AEwQ8 AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAA3/b+LQTBMQC0nTEACAAAAPydMQAIsTEAAAAAAAAA AAAAARIuDwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAPAAAAGQAAAA8AAAAZAAAAFCxMQCMnTEA CAAAAAixMQAcsTEAAwAAABj9///wAAAAAAAxAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABA CwAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAADf9v4tt7ExALSdMQAIAAAA9J0xAAix MQAAAAAAAAAAAAABEi4fAAgEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAN/2/i37sTEAtJ0x AAgAAAD0nTEACLExAAAAAAAAAAAAAAASLg8AiBMPAQAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAA UABUADEAMgAAAIsTCQAAAAAAJQQBAAAAAQ8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA AACLExAAAAAAAA0ECAAAAHC1AABwtQAADwCKE54AAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACL E4AAAAAPAOQPGAAAAAAA0w8EAAAADgAAAAAAGBAEAAAAAQAAAA8A5A8YAAAAAADTDwQAAAAYAAAA AAAYEAQAAAABAAAADwDkDxgAAAAAANMPBAAAABsAAAAAABgQBAAAAAEAAAAPAOQPGAAAAAAA0w8E AAAAJgAAAAAAGBAEAAAAAQAAAD8A2Q8MAAAAAADaDwQAAAAAAAIATwDZDwwAAAAAANoPBAAAAA0A AgAPAPAPGAEAAAAA8wMUAAAABgAAAAQAAAAAAAAAEgIAAAAAAAAAAPMDFAAAAAcAAAAEAAAAAAAA AD0CAAAAAAAAAADzAxQAAAAIAAAABAAAAAAAAABAAgAAAAAAAAAA8wMUAAAACQAAAAQAAAAAAAAA QgIAAAAAAAAAAPMDFAAAAAoAAAAEAAAAAAAAAEMCAAAAAAAAAADzAxQAAAALAAAABAAAAAAAAABE AgAAAAAAAAAA8wMUAAAADAAAAAQAAAAAAAAAPwIAAAAAAAAAAPMDFAAAAA0AAAAEAAAAAAAAAD4C AAAAAAAAAADzAxQAAAAOAAAABAAAAAAAAABBAgAAAAAAAAAA8wMUAAAADwAAAAQAAAAAAAAARQIA AAAAAAAvAPAPHAAAAAAA8wMUAAAAEAAAAAQAAAAAAAAAAAEAAAAAAAABAAEEUAAAAP8AAP7///9/ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABBDEAAAAoBMIHAABQSwMEFAAGAAgAAAAhAFauB8P3AAAAqQEAABMACAJbQ29u dGVudF9UeXBlc10ueG1sIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHyQzU7DMBCE70i8g+Urih04IISa9MDPEZAoD7A4m8Sq/+Td Vs3b46RFQqhwsta7M/NpVuuDd2KPmWwMjbxWtRQYTOxsGBr5sXmu7qQghtCBiwEbOSHJdXt5sdpM CUkUdaBGjszpXmsyI3ogFROGsulj9sBlzINOYLYwoL6p61ttYmAMXPHsIdvVI/awcyyeDuX7SJLR kRQPx8M5q5GQkrMGuJDqfeh+pVSnBFWUyw2NNtFVwZD6bMK8+TvgpHst1WTboXiDzC/gC4Zm+HT4 zpNDUv+bnKGMfW8NdtHsfGlApYxU3gXYO/XD+ptcL0W3XwAAAP//AwBQSwMEFAAGAAgAAAAhAO3k DEu7AAAAJgEAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEj80KwjAQhO+C7xD2blM9iEjTXkTwqvUB 1nT7g2kSklXs25tjC4LH2WG+2Smqz2jEm0IcnFWwzXIQZLVrBtspuNfnzQFEZLQNGmdJwUQRqnK9 Kq5kkFMo9oOPIlFsVNAz+6OUUfc0YsycJ5uc1oUROcnQSY/6iR3JXZ7vZZgzoFwwxaVREC7NFkQ9 +dT8n+3adtB0cvo1kuUfFZLxYejGk0krRI2hI1YwO2bpW5BlIRfryi8AAAD//wMAUEsDBBQABgAI AAAAIQDY/Y2PrAAAALYAAAAPAAAAdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTC ICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m2 36U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3 qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAQItABQABgAIAAAAIQBWrgfD 9wAAAKkBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAO3kDEu7AAAAJgEAAAsAAAAAAAAAAAAAAAAAMAMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhANj9jY+sAAAAtgAAAA8AAAAAAAAAAAAAAAAAHAYAAHRhYmxlU3R5bGVzLnhtbFBLBQYAAAAA AwADALcAAAD1BgAAAAAAAOoDAAAAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAA AAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAA AQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAD AAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkA cABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAA AQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAED AAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAABAkA AAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5 AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEA AAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAI AAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAA AAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEAcgBp AGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIA YQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAI DAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAA AAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAA AAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAA CAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAA AAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPAIgXPAAAAAAAiRc0 AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAAAQEBAAEAAAAAAAAAGMYAAAAAAAAAAAAAgAIB4A8A +AOYHgAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAIAMQBgAPAHIAAAAP///wAAAAAAgICA AAAAAAC74OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAA mWYAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAA AAAAlpaWAAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPM zAD/UFAA/5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAA AIAAAAD///8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8A M2bMAACwAABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABg APAHIAAAAGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+ XAD///8AYFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQA AIyeoAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8A AAAAAAEAAAD//yQAFzQX/gAAEACjD3wAAAAFAP/9PwAFACIgAABkAJvBHP4AAGQAFAAAANgAAABA AgAAAAACAAAA///vAAAAAAABAAAA//8eAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkAC AAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABk AAAAAP8AAGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8MAAAAAAEAAAAFAAAgASAB AAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAEAAow9uAAAABQD//T8AAAAi IAAAZAAAAAD/AABkAAAAAAAAAAAAIAEAAAAABwAAAP//7wAAAAAA////////EgAAAAABAAAABQAA IAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAAB CQAABAABAAAAAAAAAAEAAQkAAAQAAQAgAQAAAAACAAEJAAAEAAEAQAIAAAAAAwABCQAABAABAGAD AAAAAAQAAQkAAAQAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAA AAIAGgABAAAAAAAAAAIAGAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMP PgAAAAUAAAAAAAAAAAACABUAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAA AAAAAAACABAAAAAjBPwGAABQSwMEFAAGAAgAAAAhAJHvzfL7AAAAuwEAABMAAABbQ29udGVudF9U eXBlc10ueG1sfJDJTsMwEIbvSLyD5SuKnXJACCXpgeXGcigPMHImiYU3edyqfXsmaZEqVDiNZv3+ +Zv13juxw0w2hlauVC0FBhN7G8ZWfm5eqnspqEDowcWArTwgyXV3fdVsDglJ8HagVk6lpAetyUzo gVRMGLgzxOyhcJpHncB8wYj6tq7vtImhYChVmW/IrnnCAbauiOc9l49KMjqS4vE4OLNaCSk5a6Cw Ur0L/S9KdSIo3lxmaLKJbliG1BcJc+dvwGnvna3JtkfxAbm8gWcZus+kyXHxFaiwc+fJSv1/9oLu OAzWYB/N1rMnKmUkjssL3qkz0M8verG++wYAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEA AAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSP wzBvZur2NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwp HKRkPdKMXPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8V kidr6IycKGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAEneT5vLAwAA sCYAACEAAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWt1u2jAYvZ+0d4h8OzFw CCSghqrt1N10EhrtA5hgIKrjRI7blV3tHfYGe43d7VH2JPvsGEgg6dDUCZXkLsW/Ocf5vnP89ez8 KWLWIxVpGHMf4fcdZFEexLOQL3x0d3vd8pCVSsJnhMWc+mhFU3Q+evvmLBnKp4lcMZpaMAVPh8RH SymTYbudBksakfR9nFAObfNYRETCn2LRngnyBaaOWNvudPrtiIQcmfHikPHxfB4G9EMcPESUy2wS QRmRsP10GSbperbkkNkSQVOYRo8ubGmkXi+UjOo3HJ2RIXtkOBkLi7AF4BRIgSwhmY8UXuSGX4p7 /TyPubzQXaYkpchaEr6A9x0/8ECqDmqqNAku6dw8jQNpPRI9UXt01t5pvZjLZ/qZ1hmdf4adpV99 1O13zBoxC2fXIWN6uFhMr5jI1sFu18EuMovluykUuSVXCZ2TAKi+ECFhyAqWRKRU7x4GkSEluT6f Jtb4YyyXYYCsJJTB8ppEIVvBTpzcyBa2PbUiGQZpxeDiKoBD9lYaEoO9Gg+PdkPD0WhQ2Bsaug0N R6NBYW9ocBoajkaDwt7Q0GtoOBoNCntDQ1/REBFx4yOn54LEQGUJeydJq7GvOifvZUsFg0HE3SIy wI5TV0QUDAYRb4sI7rpYKaZaHhKFg4FkkIPEsz2vrpAoHEBxFrV/MpzGs9WeEciiTNexBwqtkM/A SPiotf4h8wkgn1/WJUBIg+X+1SlMH8AG6HCXdwSDyyuMr8ykmy7wAMJfq38f/f72I9Pvea+hdqIn y5sI7f3oxm3IJ7zebb7Xa7IaGdEuEN3LE217PVf9cGpEf98j2lbx4ASJ3jUzGdEYO111sreftG17 uSRxyp+0rfTBCTK965cM08Cqloib4H2qTJd80ycavHctWca03em5WvqeONO/fu4H7xMlutz02T3s 6Fj9d6IPNoFHklz/mct3EW8xabRZ8a613D3aAxdrY9BAC9cFz4nZZ6Att6GZZzhIcjSnturUltvZ ruf1D8zxDbRV0G5scc4IJ0Oo+lCxscUQQsbZfYKxiAwqXz6ivHU32UYZ02VdTMuyc95EweBbMp1A KWt9f7fnnzGytH3cFt2KRTasFazZhSqKZWHrngpV4FSH4YUU7vY73ymKqQZKslRcKHiphiDdwgFl u6oCVwbNGoSNyawtPuVmrXilCdastvhUWJziBWedASp3Brh43VlngCoUtb78aEI0pKwKXew6Xa0w mhhdoW4BnVzdqc6fWIVG7ffc4gVjbbPYRmnmxaWqx5h/NRv9AQAA//8DAFBLAQItABQABgAIAAAA IQCR783y+wAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAEneT5vLAwAAsCYAACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZU1hc3RlcnMv c2xpZGVNYXN0ZXIxLnhtbFBLBQYAAAAAAwADAMkAAAAdBgAAAAAPAAwExAIAAA8AAvC8AgAAEAAI 8AgAAAADAAAAAwQAAA8AA/BgAgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArw CAAAAAAEAAAFAAAADwAE8O4AAAASAArwCAAAAAIEAAAACgAAkwAL8E4AAAB/AAEA7wGAAEC7TwWH AAEAAAC/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwA ZQAgADcAAAAAABDwCAAAAKoAJwFnFdACDwAR8BAAAAAAAMMLCAAAAAAAAAABABIuDwAN8FgAAAAA AJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYA AAAhAAAAAAAAAKoPDgAAACEAAAAHAAAAAAALBAQIDwAE8DIBAAASAArwCAAAAAMEAAAACgAAgwAL 8EgAAAB/AAEA7wGAAKC7TwW/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUA YwB0AGEAbgBnAGwAZQAgADgAAAAAABDwCAAAADADIAFgFWAPDwAR8BAAAAAAAMMLCAAAAAEAAAAC ABIuDwAN8KIAAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQg c3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwA AKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8OAAAAUwAAAAcAAAAAAAsE BAgPAATwPAAAABIACvAIAAAAAQQAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8BEAAQAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgT MQAAAA8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAAACQEAQAAAAsAAA4E Ow4AAFBLAwQUAAYACAAAACEA6d4Pv/8AAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctO wzAQRfdI/IPlLUqcskAIJemCx47HonzAyJkkFsnYsqdV+/dM0lRCqCAWbCzZM/eeO+NyvR8HtcOY nKdKr/JCKyTrG0ddpd83T9mtVomBGhg8YaUPmPS6vrwoN4eASYmaUqV75nBnTLI9jpByH5Ck0vo4 Ass1diaA/YAOzXVR3BjriZE448lD1+UDtrAdWD3u5fmYJOKQtLo/Nk6sSkMIg7PAktTsqPlGyRZC Lsq5J/UupCuJoc1ZwlT5GbDoXmU10TWo3iDyC4wSw7AMiV/PZyAZLea/O56J7NvWWWy83Y6yjnw2 XsxOwf8UYPU/6BPTzH9bfwIAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVs cy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9 /q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlP vFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RM aeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAA AHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOc GkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchz UX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAA ACEA8MNbCsMIAACXNwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0YQfo+U/4B4T4bD YBitN+JUHhIl2tkoj1GPjY8sBgvY69+nqi/TZqbBGbSbaG1LY9wuqqur6quqrmZe/fTpWBofiqY9 1NXKtH+0TKOo1vXmUO1W5h9v8x8C02g7Um1IWVfFyvxctOZPr7//7hW57/bFsTDg/qq9Jytz33Wn +7u7dg3DpP2xPhUV/LatmyPp4Guzu9s05CPwPZZ3jmX5d0dyqEyjIkdg6/z1W1l079uGvCuqqjBf C/5ZCZNUXYsD67J5QO4Fv0m5xbDpTZt3NpK2ze4xKRvjAylXpkVf5t3rV3fknhOU3ZAupy9Oxwk2 75wxfpSg7IZ0gYVvyY8SkPUaljOcO44zK3M5bY+IXQ55u/AKQ4W+x98dyKysjTGlROxyMaBXdNYj YpfegD6NsjTLFXkoEaP3B/RO6qRBpNBTon15qN4NqC0rhBenliTbuvz5SfIwTBJLKP5MBdaXLoRT bOuqUxzqKS88kr/rJgdKvKMk3aEyus+nYkvW4LYoEbkvyGBo3V4MwdwKp+OhmovtmRNMcl4TXeFR XeBv2+1hzdC1PZTlQ/e5LH5p6dLaujxschjE+yiICwmg0x4uufYVul1D6D1GU3d/Hrr9w56cQC0M iruWs961xqluAYfms7zxB1BtxwDrofcx3bak+7XesGG3j2MpIkX1jgYIMZGLDKZO5i5fNpnNpJq4 NJuKRt1GWZpcMthwuDQYlNoEjzcIRmfbhzCKshvtmpTFBvXOYpwwC8okrmcxUbsnm4LbCNc9tJFN jSR8hUZr8J0nbBRQ0bVa680WItsXzDbFSP3pFs9MJ6z3EiuJwCQsQ5VzCcey6oOzrIyPKzP0HM80 1uS0MrcQieDyeAKrt9XONEi5g/y97hrm9qNgpoo/WzMUCwPv6yHOtsT4YMFKHDg1bZeSds9cg/7E XaCscCYmv+OBWudaAPP0fyGFG4AzfDUpQI+qaYvttlh3fWP3RlB37CsPpfX7rmge9puPxmP5vnlD wPzoqrCezaHtoI4SX5qVidqmP6nBmQfGJwoknI2Upz3h4RYhKpDMyKmrShnot554sLYnZaeLu34p FPKwrjmW0nfjb2wpmE+KqnA3aIE1VNsNMRCvK7Nuun0NUei0P6zzBkocGjvAWwyILpiuDaj56WdT fMBPhjnGA7mVh92+e3PYGc0B8lG3b4ridwhL1GQjzGyeuxhLwYh6VE/c9sTEfiw+FOVbjIE+5nbT 2IOr02jCwwClu/Q/9TtH0OMOi5w+3pQYInMvw8CXrnwYmGFRahymBY3QvxSRakutfNj99HaRe/sL wR/OZdZCoAIm66WCkMP+X4pwZaplEWuwYscTwoEVhyuGQVkQnUi3N/AP5L9Dsy7P9e3b+g3EVgO2 gMgM3Aa8+gdWeBgYVdjgIxRObJA5E7JiquXVLWpNJOtZyqizCeS8F8pGyabY+0ply+JMnU7B4pzK 5hpWdM3GnlU1WPYSojC0FRsZahjaeeh3BurHv8HQKezK3pddS52p+NQ1BErPB4oDDn51EO26FhS3 noJ56yng/vllPQXwp1/JyXjc2SsTWkgQcj7BFTSdTBhzcMzBMbiCzhKU7awdtDL5hRiB39mIpHHF iCtoFmJkIUY8MQLbBN54ESM+5EzslUCfDj9MQywU9hJ8yTy9DzEyHNGjxqF1xH+pExf6+BZbEtaq 4xqnubJfDOdxmntXdOLyPAx9wZsbDZmyyy/ficvTLIlV+bWduGwZRF7CdcO9BuWXbTall5okLiQR Ti1JhAsNlImqkeRnKojo0oXwnhtqCsP9z6Hmmv41tlxztf9Lm9w9QFz40YDe+ZqoSaLMuZBfi5o4 jMNsORU1mFkTgbFx1ES5v5TC3FCjO/VZvBg1cGzh56JzOsOpz1W5pn/ixKCiRU2QJr50jB602OUw 12RJHuWql8566vPEqZIWNcs8dqejBg4J/StQY1kRbKc4JG+o0aHGezFq0PKpOJGbATVL+uLG44ep PUAouYN6nerVWtRg7JV+NAE1yD8Ta+tBi12+/KyUyq+efWpR46SYbabmmjz3oGvPqcdzDZavN9TA QwW8DmX9gie7Ab4GNV7kBVznszxh0HtygD+C8NQTBuhJ8lx8BDUQTRe+o3iRFjV+6ueJijJthRZF iZUIv5uAmjTCtyIPhRa7lQJCQX0UxUGsyqNFje/4i3ih8Nc+YYC65NTjqLGsPL8SNXS/T7sBtC9A uwG0L0C7AbQvwJYO/QJ+IXbx/+tuwPJZ1HiJfVbiDKihzVThgRrUpHnqhGKHPIIaZb/LzXLep1BA KF4aZ8vQFzIwei1qEiuCl+Kl2grtWtRkDoBM5a9FTZT4qad2MzSoUeLPOGpSN3JskcimVWjfKmqC Z1FjWa4r+00zoAZPGmQO0aAG9+syQo6gBiW8qLi0ucay4vN5xwTUIGYS1atnRU2UxkGm5kotakCD 50jG5NegBnUjNTmOGihGl5bNQ8QNNbp9TfgsatAje15OvZFvW5T4jT4ubTPDviZzs7jXXejlAiqC MjciW8o4Idcs/CBaxEru6PEfdgMQNRe5YF7URFF6gUotatx8mS5EHp4dNVYGJ4031BTj+xqbPRLE c4niksq2fIZk4wd+7KXcKppkk9qpnQjXHkk2oRVagRqstckmsMIsEpu1CckGNt9RrJZEs8Im8eEt 4juTRwubpRvkoSq/JtnkeZLIcmE82WRhmshewy3Z6JKN/fx/HLgQ9uWZ2hyw8ZXsRaM8R4UC14vs 1csGw2zjW164FBCbkG1ABF9mximwCeLgIhvMCpsYIkksduwTYOMlXjK996ycZ43DBhUvU/cNNlrY PP94APxTiGV7Mju8uEjzHDdzROTWZZs8sQKRlUayTZAs46WoKybAJsi93FHdtAfLYZEWu1EeiaNC xn9W2CQAmliFvTbbBLbnOepWS5NtkiSGRxC5BcdhEySQigX5twQbeABCfaqGPqAGo/TRttf/AAAA //8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1l TWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6H Yb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIO J0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFB c9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAOneD7//AAAAHAIAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AA AAA2AQAACwAAAAAAAAAAAAAAAAAwAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMA AACKAAAAHAAAAAAAAAAAAAAAAAAZAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQIt ABQABgAIAAAAIQDww1sKwwgAAJc3AAAWAAAAAAAAAAAAAAAAANYCAAB0aGVtZS90aGVtZS90aGVt ZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAAzQsAAHRoZW1l L3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0BAADIDAAAAAAA AA8EOgEAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFsb25lPSJ5 ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5v cmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgy PSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2VudDM9ImFjY2Vu dDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9ImFjY2VudDYi IGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+AAAcBAQAAAABAAAAIAC6Dx4AAAAy AF8ATwBsAGUAdAB1AHMAcgBhAGsAZQBuAG4AZQAPAPgDkCQAAAIA7wMYAAAAAQAAAAECBwkIAAAA AAAAAAAAAAACADEAYADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAGAA8Acg AAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAAAP///wAAAAAAgICAAAAA AACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA////AI3G/wAAZswAAKgA AGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABgAPAHIAAAAACAgAD///8A AFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA////AFwfAADf0pMAzDMAAL55YAD/ /5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/AP/nAQBgAPAHIAAAAAAA AAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABoa10A////AHd3dwDR0csAkJCC AICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZewBmZv8Amcz/AP//mQBgAPAH IAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4AAAABAP/9PwAAACIgAABk AAAAAP8BAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8kABc0F/4AABAAow98AAAA BQD//T8ABQAiIAAAZACbwRz+AABkABQAAADYAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//HgAA AAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIAFACABQAA uwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAB4AAAAAAAAAQAIAAAAAAgAA AP//7wAAAAAAAQAAAP//DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAA AAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAACABAAAA AAcAAAD//+8AAAAAAP///////xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD YAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAQAAQAAAAAAAAABAAEJAAAEAAEAIAEA AAAAAgABCQAABAABAEACAAAAAAMAAQkAAAQAAQBgAwAAAAAEAAEJAAAEAAEAgAQAAAAAYACjDwwA AAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABoAAQAAAAAAAAACABgAAgAAAAAAAAAC ABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgAVAAEAAAAAAAAA AgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAAAAIwT8BgAAUEsDBBQABgAI AAAAIQCR783y+wAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQyU7DMBCG70i8g+Urip1y QAgl6YHlxnIoDzByJomFN3ncqn17JmmRKlQ4jWb9/vmb9d47scNMNoZWrlQtBQYTexvGVn5uXqp7 KahA6MHFgK08IMl1d33VbA4JSfB2oFZOpaQHrclM6IFUTBi4M8TsoXCaR53AfMGI+rau77SJoWAo VZlvyK55wgG2rojnPZePSjI6kuLxODizWgkpOWugsFK9C/0vSnUiKN5cZmiyiW5YhtQXCXPnb8Bp 752tybZH8QG5vIFnGbrPpMlx8RWosHPnyUr9f/aC7jgM1mAfzdazJyplJI7LC96pM9DPL3qxvvsG AAD//wMAUEsDBBQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C /xD2btN6EJGmvYjQgxfRD1iSbRtsk5CNon9vjhYEj8Mwb2bq9jVP4kmRrXcKqqIEQU57Y92g4HY9 bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgDi0xxrGBMKRykZD3SjFz4QC47vY8zpizjIAPqOw4kt2W5 k/GbAc2CKTqjIHamAnF9h9z8n+373mo6ev2YyaUfFZIna+iMnChmLMaBkgIT+dtYiKrI+0E2tVz8 bT4AAAD//wMAUEsDBBQABgAIAAAAIQBJ3k+bywMAALAmAAAhAAAAZHJzL3NsaWRlTWFzdGVycy9z bGlkZU1hc3RlcjEueG1s7FrdbtowGL2ftHeIfDsxcAgkoIaq7dTddBIa7QOYYCCq40SO25Vd7R32 BnuN3e1R9iT77BhIIOnQ1AmV5C7FvznH+b5z/PXs/Cli1iMVaRhzH+H3HWRRHsSzkC98dHd73fKQ lUrCZ4TFnPpoRVN0Pnr75iwZyqeJXDGaWjAFT4fER0spk2G7nQZLGpH0fZxQDm3zWEREwp9i0Z4J 8gWmjljb7nT67YiEHJnx4pDx8XweBvRDHDxElMtsEkEZkbD9dBkm6Xq25JDZEkFTmEaPLmxppF4v lIzqNxydkSF7ZDgZC4uwBeAUSIEsIZmPFF7khl+Ke/08j7m80F2mJKXIWhK+gPcdP/BAqg5qqjQJ LuncPI0DaT0SPVF7dNbeab2Yy2f6mdYZnX+GnaVffdTtd8waMQtn1yFjerhYTK+YyNbBbtfBLjKL 5bspFLklVwmdkwCovhAhYcgKlkSkVO8eBpEhJbk+nybW+GMsl2GArCSUwfKaRCFbwU6c3MgWtj21 IhkGacXg4iqAQ/ZWGhKDvRoPj3ZDw9FoUNgbGroNDUejQWFvaHAaGo5Gg8Le0NBraDgaDQp7Q0Nf 0RARceMjp+eCxEBlCXsnSauxrzon72VLBYNBxN0iMsCOU1dEFAwGEW+LCO66WCmmWh4ShYOBZJCD xLM9r66QKBxAcRa1fzKcxrPVnhHIokzXsQcKrZDPwEj4qLX+IfMJIJ9f1iVASIPl/tUpTB/ABuhw l3cEg8srjK/MpJsu8ADCX6t/H/3+9iPT73mvoXaiJ8ubCO396MZtyCe83m2+12uyGhnRLhDdyxNt ez1X/XBqRH/fI9pW8eAEid41MxnRGDtddbK3n7Rte7kkccqftK30wQkyveuXDNPAqpaIm+B9qkyX fNMnGrx3LVnGtN3puVr6njjTv37uB+8TJbrc9Nk97OhY/XeiDzaBR5Jc/5nLdxFvMWm0WfGutdw9 2gMXa2PQQAvXBc+J2WegLbehmWc4SHI0p7bq1Jbb2a7n9Q/M8Q20VdBubHHOCCdDqPpQsbHFEELG 2X2CsYgMKl8+orx1N9lGGdNlXUzLsnPeRMHgWzKdQClrfX+3558xsrR93BbdikU2rBWs2YUqimVh 654KVeBUh+GFFO72O98piqkGSrJUXCh4qYYg3cIBZbuqAlcGzRqEjcmsLT7lZq14pQnWrLb4VFic 4gVnnQEqdwa4eN1ZZ4AqFLW+/GhCNKSsCl3sOl2tMJoYXaFuAZ1c3anOn1iFRu333OIFY22z2EZp 5sWlqseYfzUb/QEAAP//AwBQSwECLQAUAAYACAAAACEAke/N8vsAAAC7AQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAA AAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBJ3k+bywMAALAmAAAhAAAA AAAAAAAAAAAAABMCAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwUGAAAAAAMA AwDJAAAAHQYAAAAADwAMBDoEAAAPAALwMgQAAAABCPAIAAAABQAAAAUIAAAPAAPw1gMAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPCyAAAAsgQK8AgA AAACCAAAAAoAAKMAC/B8AAAAfwCAAPsBBEEBAAAABcEWAAAAPwEAAAYAvwEAABAA/wEAABgAPwMQ ABgAgMMUAAAAgcMWAAAAvwMAAAIAcABwAHQAXwBwAGEAbABrAGsAaQAAAFAAaQBjAHQAdQByAGUA IAA5AAAAcABwAHQAXwBwAGEAbABrAGsAaQAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAABsEAAAgBbi EA8ABPC0AAAAsgQK8AgAAAADCAAAAAoAAKMAC/B+AAAAfwCAAPsBBEEBAAAABcEWAAAAPwEAAAYA vwEAABAA/wEAABgAPwMQABgAgMMWAAAAgcMWAAAAvwMAAAIAcABwAHQAXwBwAGEAbABrAGsAaQAA AFAAaQBjAHQAdQByAGUAIAAxADAAAABwAHAAdABfAHAAYQBsAGsAawBpAAAAEwAi8QYAAAC/AwAE AAQAABDwCAAAAAAAAACAFnYADwAE8O4AAAASAArwCAAAAAQIAAAACgAAkwAL8E4AAAB/AAEA7wGA AIC9TwWHAAEAAAC/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEA bgBnAGwAZQAgADcAAAAAABDwCAAAAKoAJwFnFdACDwAR8BAAAAAAAMMLCAAAAAAAAAABABIuDwAN 8FgAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxl AACiDwYAAAAhAAAAAAAAAKoPDgAAACEAAAAHAAAAAAALBAQIDwAE8DIBAAASAArwCAAAAAUIAAAA CgAAgwAL8EgAAAB/AAEA7wGAAMC8TwW/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAA AgBSAGUAYwB0AGEAbgBnAGwAZQAgADgAAAAAABDwCAAAADADIAFgFWAPDwAR8BAAAAAAAMMLCAAA AAEAAAACABIuDwAN8KIAAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVy IHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGgg bGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8OAAAAUwAAAAcA AAAAAAsEBAgPAATwPAAAABIACvAIAAAAAQgAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8BEAAQ AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM AAAPAIgTMQAAAA8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAAACQEAQAA AAsAAA4EPA4AAFBLAwQUAAYACAAAACEA6d4Pv/8AAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54 bWyskctOwzAQRfdI/IPlLUqcskAIJemCx47HonzAyJkkFsnYsqdV+/dM0lRCqCAWbCzZM/eeO+Ny vR8HtcOYnKdKr/JCKyTrG0ddpd83T9mtVomBGhg8YaUPmPS6vrwoN4eASYmaUqV75nBnTLI9jpBy H5Ck0vo4Ass1diaA/YAOzXVR3BjriZE448lD1+UDtrAdWD3u5fmYJOKQtLo/Nk6sSkMIg7PAktTs qPlGyRZCLsq5J/UupCuJoc1ZwlT5GbDoXmU10TWo3iDyC4wSw7AMiV/PZyAZLea/O56J7NvWWWy8 3Y6yjnw2XsxOwf8UYPU/6BPTzH9bfwIAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsA AABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsI hKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYw lRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzl RQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACK AAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLL rrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0 jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQU AAYACAAAACEAxFEtPcQIAACXNwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0YQfo+U /4B4T4bDYBitN+JUHhIl2tkoj1GPjY8sBgvY69+nqi/TZqbBGbSbaG1LY9wuqqur6quqrmZe/fTp WBofiqY91NXKtH+0TKOo1vXmUO1W5h9v8x8C02g7Um1IWVfFyvxctOZPr7//7hW57/bFsTDg/qq9 Jytz33Wn+7u7dg3DpP2xPhUV/LatmyPp4Guzu9s05CPwPZZ3jmX5d0dyqEyjIkdg6/71W1l079uG vCuqqjBfC/5ZCZNUXYsD67J5QO4Fv0m5xbDpTZt3NpK2ze4xKRvjAylXpkVf5t3rV3fknhOU3ZAu py9Oxwk275wxfpSg7IZ0gYVvyY8SkPUaljOcO44zK3M5bY+IXQ55u/AKQ4W+x98dyKysjTGlROxy MaBXdNYjYpfegD6NsjTLFXkoEaP3B/RO6qRBpNBTon15qN4NqC0rhBenliTbuvz5SfIwTBJLKP5M BdaXLoRTbOuqUxzKecILj+TvusmBEu8oSXeojO7zqdiSNbgtSkTuCzIYWrcXQzC3wul4qOZie+YE k5zXRFd4VBf423Z7WDN0bQ9l+dB9LotfWrq0ti4PmxwG8T4K4kIC6LSHS659hW7XEHqP0dTdn4du /7AnJ1ALg+Ku5ax3rXGqW8Ch+Sxv/AFU2zHAeuh9TLct6X6tN2zY7eNYikhRvaMBQkzkIoOpk7nL l01mM6kmLs2molG3UZYmlww2HC4NBqU2weMNgtHZ9iGMouxGuyZlsUG9sxgnzIIyietZTNTuyabg NsJ1D21kUyMJX6HRGnznCRsFVHSt1nqzhcj2BbNNMVJ/usUz0wnrvcRKIjAJy1DlXMKxrPrgLCvj 48oMPcczjTU5rcwtRCK4PJ7A6m21Mw1S7iB/r7uGuf0omKniz9YMxcLA+3qIsy0xPliwEgdOTdul pN0z16A/cRcoK5yJye94oNa5FsA8/V9I4QbgDF9NCtCjatpiuy3WXd/YvRHUHfvKQ2n9viuah/3m o/FYvm/eEDA/uiqsZ3Nou5VJIwJ+aVYmapv+pAZnHhifKJBwNlKe9oSHW4SoQDIjp64qZaDfeuLB 2p6UnS7u+qVQyM+0lL4bf2NLwXxSVIW7QQusodpuiIF4XZl10+1riEKn/WGdN1Di0NgB3mJAdMF0 bUDNTz+b4gN+MswxHsitPOz23ZvDzmgOkI+6fVMUv0NYot43wszmuYuxFIyoR/XEbU9M7MfiQ1G+ xRjoY243jT24Oo0mPAxQukv/U79zBD3usMjp402JITL3Mgx86cqHgRkWpcZhWtAI/UsRqbbUyofd T28Xube/EPzhXGYtBCpgsl4qCDns/6UIV6ZaFrEGK3Y8IRxYcbhiGJQF0Yl0ewP/QP47NOvyXN++ rd9AbDVgC4jMwG3Aq39ghYeBAZINPkLhxAaZMyErplpe3aLWRLKepYw6m0DOe6FslGyKva9UtizO 1OkULM6pbK5hRdds7FlVg2UvIQpDW7GRoYahnYd+Z6B+/BsMncKu7H3ZtdSZik9dQ6D0fKA44OBX B9Gua0Fx6ymYt54C7p9f1lMAf/qVnIzHnb0yoYUEIecTXEHTyYQxB8ccHIMr6CxB2c7aQSuTX4gR +J2NSBpXjLiCZiFGFmLEEyOwTeCNFzHiQ87EXgn06fDDNMRCYS/Bl8zT+xAjwxE9ahxaR/yXOnGh j2+xJWGtOq5xmiv7xXAep7l3RScuz8PQF7y50ZApu/zynbg8zZJYlV/bicuWQeQlXDfca1B+2WZT eqlJ4kIS4dSSRLjQQJmoGkl+poKILl0I77mhpjDc/xxqrulfY8s1V/u/tMndA8SFHw3ona+JmiTK nAv5taiJwzjMllNRg5k1ERgbR02U+0spzA01ulOfxYtRA8cWfi46pzOc+lyVa/onTgwqWtQEaeJL x+hBi10Oc02W5FGueumspz5PnCppUbPMY3c6auCQ0L8CNZYVwXaKQ/KGGh1qvBejBi2fihO5GVCz pC9uPH6Y2gOEkjuo16lerUUNxl7pRxNQg/wzsbYetNjly89Kqfzq2acWNU6K2WZqrslzD7r2nHo8 12D5ekMNPFTA61DWL3iyG+BrUONFXsB1PssTBr0nB/gjCE89YYCeJM/FR1AD0XThO4oXaVHjp36e qCjTVmhRlFiJ8LsJqEkjfCvyUGixWykgFNRHURzEqjxa1PiOv4gXCn/tEwaoS049jhrLyvMrUUP3 +7QbQPsCtBtA+wK0G0D7Amzp0C/gF2IX/7/uBiyfRY2X2GclzoAa2kwVHqhBTZqnTih2yCOoUfa7 3CznfQoFhOKlcbYMfSEDo9eiJrEieCleqq3QrkVN5gDIVP5a1ESJn3pqN0ODGiX+jKMmdSPHFols WoX2raImeBY1luW6st80A2rwpEHmEA1qcL8uI+QIalDCi4pLm2ssKz6fd0xADWImUb16VtREaRxk aq7UogY0eI5kTH4NalA3UpPjqIFidGnZPETcUKPb14TPogY9sufl1Bv5tkWJ3+jj0jYz7GsyN4t7 3YVeLqAiKHMjsqWME3LNwg+iRazkjh7/YTcAUXORC+ZFTRSlF6jUosbNl+lC5OHZUWNlcNJ4Q00x vq+x2SNBPJcoLqlsy2dINn7gx17KraJJNqmd2olw7ZFkE1qhFajBWptsAivMIrFZm5BsYPMdxWpJ NCtsEh/eIr4zebSwWbpBHqrya5JNnieJLBfGk00WponsNdySjS7Z2M//x4ELYV+eqc0BG1/JXjTK c1QocL3IXr1sMMw2vuWFSwGxCdkGRPBlZpwCmyAOLrLBrLCJIZLEYsc+ATZe4iXTe8/KedY4bFDx MnXfYKOFzfOPB8A/hVi2J7PDi4s0z3EzR0RuXbbJEysQWWkk2wTJMl6KumICbILcyx3VTXuwHBZp sRvlkTgqZPxnhU0CoIlV2GuzTWB7nqNutTTZJklieASRW3AcNkECqViQf0uwgQcg1Kdq6ANqMEof bXv9DwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVs cy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs 7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYk UiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04Goln Lx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQDp3g+//wAA ABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh AKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAAMAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAGQIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54 bWxQSwECLQAUAAYACAAAACEAxFEtPcQIAACXNwAAFgAAAAAAAAAAAAAAAADWAgAAdGhlbWUvdGhl bWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAAM4L AAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAA yQwAAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRh bG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJs dDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQz PSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJh Y2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPhAAHgR5BAAAUEsDBBQA BgAIAAAAIQBNjvP8/QAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5Qt atJhgRBqOwseKwQshg+wEreNyEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vf d0/VLWeUwWuwwWPLZyS+7S4vmt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xup gs/oc5WXHbxrHrCHyWb2eCjlo5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl 8zfgpHstr0lGI3uDlF/AFRtSJ5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI 9fXdJwAAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrC MBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s 6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5g T3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLv B9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAJA175VGAQAAdgIAACEAAABkcnMvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0MS54bWyMUstugzAQvFfqP1i+NyY9VBUK5NDXpW0iJf0AyyzBkl9aOxT+ vguBRq1yyAWtZ2fGO15W684a1gJG7V3Bl4uMM3DKV9odCv61f7175Cwm6SppvIOC9xD5ury9WYU8 mupd9v6YGHm4mMuCNymFXIioGrAyLnwAR73ao5WJjngQFcpv8rZG3GfZg7BSOz7p8Rq9r2ut4Nmr owWXTiYIRiaaPzY6xNktXOMWECLZjOq/I6U+UNqkkwHORhq2BCx5ScnVzlTMSUvAfmCwndEVjK0Y 9ggwkFz7hmEXtjgqPtstMl0NDpOSi6kx0cajIxoV4p/8MDvJvKvRliuZ00OwruC0r374kkjm0CWm TqA6o6rZXOCq5uUCW8wX0AS/l1I9x6JyCD9ObvBDhk1L+WRO206ATyMUaL+nDOpMGTzm/6X8AQAA //8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEA AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAJA175VGAQAAdgIAACEAAAAAAAAAAAAAAAAAFQIA AGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAACaAwAAAAAA AB0EBAAAAAEAAAAgALoPHgAAADMAXwBPAGwAZQB0AHUAcwByAGEAawBlAG4AbgBlAA8A+ANTPwAA AgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAIAMQBgAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA 8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaW AAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA /5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD/ //8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACw AABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAA AGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8A YFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAA AKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEA AAD//yQAFzQX/gAAEACjD3wAAAAFAP/9PwAFACIgAABkAJvBHP4AAGQAFAAAANgAAABAAgAAAAAC AAAA///vAAAAAAABAAAA//8eAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgA gAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8A AGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8MAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAEAAow9uAAAABQD//T8AAAAiIAAAZAAA AAD/AABkAAAAAAAAAAAAIAEAAAAABwAAAP//7wAAAAAA////////EgAAAAABAAAABQAAIAEgAQAA AAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAABAAB AAAAAAAAAAEAAQkAAAQAAQAgAQAAAAACAAEJAAAEAAEAQAIAAAAAAwABCQAABAABAGADAAAAAAQA AQkAAAQAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAGgAB AAAAAAAAAAIAGAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUA AAAAAAAAAAACABUAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAAC ABAAAAAjBPwGAABQSwMEFAAGAAgAAAAhAJHvzfL7AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10u eG1sfJDJTsMwEIbvSLyD5SuKnXJACCXpgeXGcigPMHImiYU3edyqfXsmaZEqVDiNZv3++Zv13jux w0w2hlauVC0FBhN7G8ZWfm5eqnspqEDowcWArTwgyXV3fdVsDglJ8HagVk6lpAetyUzogVRMGLgz xOyhcJpHncB8wYj6tq7vtImhYChVmW/IrnnCAbauiOc9l49KMjqS4vE4OLNaCSk5a6CwUr0L/S9K dSIo3lxmaLKJbliG1BcJc+dvwGnvna3JtkfxAbm8gWcZus+kyXHxFaiwc+fJSv1/9oLuOAzWYB/N 1rMnKmUkjssL3qkz0M8verG++wYAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABf cmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2 NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKM XPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6Iyc KGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAEneT5vLAwAAsCYAACEA AABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWt1u2jAYvZ+0d4h8OzFwCCSghqrt 1N10EhrtA5hgIKrjRI7blV3tHfYGe43d7VH2JPvsGEgg6dDUCZXkLsW/Ocf5vnP89ez8KWLWIxVp GHMf4fcdZFEexLOQL3x0d3vd8pCVSsJnhMWc+mhFU3Q+evvmLBnKp4lcMZpaMAVPh8RHSymTYbud BksakfR9nFAObfNYRETCn2LRngnyBaaOWNvudPrtiIQcmfHikPHxfB4G9EMcPESUy2wSQRmRsP10 GSbperbkkNkSQVOYRo8ubGmkXi+UjOo3HJ2RIXtkOBkLi7AF4BRIgSwhmY8UXuSGX4p7/TyPubzQ XaYkpchaEr6A9x0/8ECqDmqqNAku6dw8jQNpPRI9UXt01t5pvZjLZ/qZ1hmdf4adpV991O13zBox C2fXIWN6uFhMr5jI1sFu18EuMovluykUuSVXCZ2TAKi+ECFhyAqWRKRU7x4GkSEluT6fJtb4YyyX YYCsJJTB8ppEIVvBTpzcyBa2PbUiGQZpxeDiKoBD9lYaEoO9Gg+PdkPD0WhQ2Bsaug0NR6NBYW9o cBoajkaDwt7Q0GtoOBoNCntDQ1/REBFx4yOn54LEQGUJeydJq7GvOifvZUsFg0HE3SIywI5TV0QU DAYRb4sI7rpYKaZaHhKFg4FkkIPEsz2vrpAoHEBxFrV/MpzGs9WeEciiTNexBwqtkM/ASPiotf4h 8wkgn1/WJUBIg+X+1SlMH8AG6HCXdwSDyyuMr8ykmy7wAMJfq38f/f72I9Pvea+hdqIny5sI7f3o xm3IJ7zebb7Xa7IaGdEuEN3LE217PVf9cGpEf98j2lbx4ASJ3jUzGdEYO111sreftG17uSRxyp+0 rfTBCTK965cM08Cqloib4H2qTJd80ycavHctWca03em5WvqeONO/fu4H7xMlutz02T3s6Fj9d6IP NoFHklz/mct3EW8xabRZ8a613D3aAxdrY9BAC9cFz4nZZ6Att6GZZzhIcjSnturUltvZruf1D8zx DbRV0G5scc4IJ0Oo+lCxscUQQsbZfYKxiAwqXz6ivHU32UYZ02VdTMuyc95EweBbMp1AKWt9f7fn nzGytH3cFt2KRTasFazZhSqKZWHrngpV4FSH4YUU7vY73ymKqQZKslRcKHiphiDdwgFlu6oCVwbN GoSNyawtPuVmrXilCdastvhUWJziBWedASp3Brh43VlngCoUtb78aEI0pKwKXew6Xa0wmhhdoW4B nVzdqc6fWIVG7ffc4gVjbbPYRmnmxaWqx5h/NRv9AQAA//8DAFBLAQItABQABgAIAAAAIQCR783y +wAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAI7qKvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAEneT5vLAwAAsCYAACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVN YXN0ZXIxLnhtbFBLBQYAAAAAAwADAMkAAAAdBgAAAAAPAAwE+h0AAA8AAvDyHQAAEAEI8AgAAAAG AAAABgwAAA8AA/CWHQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAM AAAFAAAADwAE8O4AAAASAArwCAAAAAIMAAAACgAAkwAL8E4AAAB/AAEA7wGAAGC8TwWHAAEAAAC/ AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADcA AAAAABDwCAAAAKoAJwFnFdACDwAR8BAAAAAAAMMLCAAAAAAAAAABABIuDwAN8FgAAAAAAJ8PBAAA AAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAA AAAAAKoPDgAAACEAAAAHAAAAAAALBAQIDwAE8DIBAAASAArwCAAAAAMMAAAACgAAgwAL8EgAAAB/ AAEA7wGAAIC6TwW/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEA bgBnAGwAZQAgADgAAAAAABDwCAAAADADIAFgFWAPDwAR8BAAAAAAAMMLCAAAAAEAAAACABIuDwAN 8KIAAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVz DVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAA ACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8OAAAAUwAAAAcAAAAAAAsEBAgPAATw JQkAABIACvAIAAAABAwAAAAKAACDAAvwVgAAAH8AAQDvAYAA4L1PBb8AAAAGAL8BAQARAP8BEQAZ AD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0AGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAA EwAi8RcIAACpwxEIAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBl c10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX 22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0g ly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezM j5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+ X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZv O+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIY GEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ 3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsD BBQABgAIAAAAIQDmC7aSqwMAAMoKAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxW34/iNhB+r9T/wfJr xUGAZXfRhtPCim0lukIXTn0eHGeT4tip7XDAqf97Z+ywS0+nqureQx8OIRjH88vfNzPO3ftDrdhe WlcZnfLk3YAzqYXJK/2c8o+bZe+GM+dB56CMlik/Ssffz3784a6ZuoahsXbTJuWl982033eilDW4 d6aRGvcKY2vwuLTP/cZKJ7UHj4Fq1R8OBpN+DZXmM3Sl91mztiSJp/3asipP+ZgzDTWGfAAv2VqB kKVRubRsxPudarQCTGVlxM51+cC/ySe38AkP+bdUmDaPFk+TUIB+SOacl8a0KGhTMn9sMKvcIzAn jASq4JjwIeXDzizqov3rsVw4HkwPha3fmuXsDqamKBhGHF9dI5CcHVM+GV3hd0ApwFQePBOUUTIa TUhBoMZocpUMr0KOMRHSbKzzj9K8OSlGjlJupfDIKExhv3KeUHwNESCNQDRTf5ib/EiaW/xHymMp /XfqsIYxfmnsibNPFpBF90cLVnKmftEu5bfJeIxA+LAIuHFmL3e2lzu6rRdGUSUw0AK9phz5juLC 44owNXUDfqWzRpDiGc3N4TewTYeHRyaeTFZCI78GS9QNKEUYyIlyPvNHJd8KSfC1V0lXerksPqxt pESdHyM953Ah/28RE+OxGuwqgITChyBgyPBf6RzHQBBBPePMUZxhahvYZthNgSXE1vqoLWGl53YX iCiM9vfBZAuOeMVZorttNClBP2NDr1st0H3kQxE5dDDXiLXwbA/E6YA+XR9casxl8aXuWQ3tX3fv C/8Pet3utl0ouzmEdty22elFXOIxXhZPOFSDiodtbBiYXhLVcVeoPMzEz/PkZnw/mSx68/HDsDe+ Xia9+eBh3JtPJrfz5eD6dnCd/IlVHkZUWdDo3FR1rD2LvOzauqrN71WkBBFLudS9jxnWtvKrsD6V vcVTnG3JDc2ObeQt/LYp15gy3Qm22uEY1CYLEmc7aekGCfNIUP91itQd6EXTXaCqk/w5LIlCVdGN EvbW1pgiyK72CyUBXQ1CxyhNWGuzrJTqijc8cUZVOT0MVNC9IxHwyLA/xAmOvF9qyaLA8XSGuV3p joaW3HRyKKqAX4EXTsrvbQVYoaIE62Qo20CXhAudXzO2fjS+rARnTeVFuYS6UjRx8Q57sewlw5s4 nYW7MP6p1j3humpEiug43zuIUPimHeRnjO4ibFz8xXaiAFLna7CAU/F7X/y/++KVqfhGEV4lzq8Q +KLlmtlfAAAA//8DAFBLAwQUAAYACAAAACEAyDoqyNcAAAD5AAAADwAAAGRycy9kb3ducmV2Lnht bESP3UrDQBCF7wXfYRnBG7Gb1vrT2G0pgigUL1r7AGN2mgSzu+nuJE3e3sELvTycw3f4luvBNaqn mOrgDUwnGSjyRbC1Lw0cPl9vn0AlRm+xCZ4MjJRgvbq8WGJuw9nvqN9zqQTiU44GKuY21zoVFTlM k9CSl+4YokOWGEttI54F7ho9y7IH7bD28lBhSy8VFd/7zsnJVHf9dtjcneb3H4fxtFjoMrIx11fD 5hkU08D/4xmN3ePNX/mLercG5qCOb+NXrO0OE1M0IG5iKpagVz8AAAD//wMAUEsBAi0AFAAGAAgA AAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEA5gu2kqsDAADKCgAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnht bFBLAQItABQABgAIAAAAIQDIOirI1wAAAPkAAAAPAAAAAAAAAAAAAAAAAAIGAABkcnMvZG93bnJl di54bWxQSwUGAAAAAAQABAD1AAAABgcAAAAAAAAQ8AgAAACkDyABYAaKEA8AEfAQAAAAAADDCwgA AAACAAAABwESLg8ADfBoAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAK AAcAAgAAAAAAAAAAAPgPBAAAAAAAAAAAAKoPDgAAAAIAAAAHAAAAAAAJBAQIAACmDwwAAADwAAAA 1AHQAvADEAUPAATwvAgAABIACvAIAAAABQwAAAAKAACDAAvwWgAAAH8AAQDvAYAAAKBgBb8AAAAG AL8BAQARAP8BEQAZAD8DAAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBlAGgA bwBsAGQAZQByACAANAAAABMAIvHABwAAqcO6BwAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlY d9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvE IrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlk EA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8Y KGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgA AAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7 CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg 372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9u A+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1 x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAuGvCDlQDAAB7BwAAEAAAAGRycy9zaGFwZXhtbC54 bWysVdtu2zgQfV+g/0DwtXB9iZ2mQpQiMeDsAm4gRCn2eUxRkWqK5JKUa/vrO0PKjVsUi8WmhmAN xcOZ4TnD4fXHfafYTjrfGp3z6bsJZ1ILU7X6Oeefn1ajK858AF2BMlrm/CA9/3jz5o9rm3nLcLH2 mc15E4LNxmMvGtmBf2es1DhXG9dBwKF7HlsnvdQBAgbq1Hg2mVyOO2g1v0FXelfawpElHnaFY22V 8wVnGjoMuTImSMcKBUI2RlVoz/l4AKd1gMmsjdj6ISP4LxlVDr7iNn9Ihmlz73A/UwowjumcMtOY GAW1DQsHi3nVwSE3x5z/04PDDDmmvc/5xbA04dHHy+Z83CRk+9p1r8305hoyU9eMIk5nc+STs0PO Ly8W+EwoB8jkPjCBgNnVh8UlAQQiLi4X09kiJpkyIaR1PtxL8+qsGDnKuZMioLCQwW7tA1H5EiLy mpiwWdjfmepAyA2+UflUUf9fPyxljN8Yd+TsqwOU0pM8kjP1l/Y5/zCdz5GIEAfzxfsZDtz5zOZ8 Rvfd0igqBwZaoNech5O5DDgiTk1nIax1aQUBT2w+7f8GZwc+AirxYMoGrPwVLQkbWUo0kBPlQxkO Sr6Wkuhrp6ZD7VWyfixckkSdPqM8p3Ax/98RE+OxDtw6koTGYzQwZHy3usJuEE1Qz9h6FGeY2hNs SjxRUSVSJiS0hLW+c9soRG10uI1LNuBJV2wpepjGJQ3oZzzVRa8Fuk96KBKHNuatKERgOyBNJ/Qb zsE54k7WP2NPMFz/Mntbh3/BDbObfqnc0z4ex01fHr+bK9zG98ED9tYICbBJBwayc6EG7aSuCnCA +rFt37Wd+dImUnHPOZd69LnE6lRhHcfHZrR8SB1qekWnf5OYj/99zjUGpebu2i12M23KaHG2lY6u gthRBJ2gAUj1jV40NXXVHuWfcUgiqJauhjhXOGPqaPsuLJUEdDWJNa80saXNqlVqKL/4xRvVVvQx kkkXiETKkkZhnxoxKneOknWNDeZEVL/WA5E9uRnsWBaxU9d4b+T81rWANSYacF7GwouESzjDfCpZ cW9C0wrObBtEs4KuVdQz52crR9PZVeqvwp8tftvpkfBDPb0olXpfbHqnZod3grc33wAAAP//AwBQ SwMEFAAGAAgAAAAhAF5WmbXXAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8FOwkAURfcm/sPk mbiTKShEKgNpTIwmyqLIAnbPzqNt6MyUmaG0f++LC1ne3Jtzcxar3jSiIx9qZxWMRwkIsoXTtS0V bL/fHp5BhIhWY+MsKRgowGp5e7PAVLuLzanbxFIwxIYUFVQxtqmUoajIYBi5lix3B+cNRo6+lNrj heGmkZMkmUmDteWHClt6rag4bs6GT8by3H322ePpabreDqf5XJY+KnV/12cvICL18Tre5dnXPv8v /1AfWsEUxOF9+PG1zjFE8grYjU3ZEuTyFwAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHd X2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALhr wg5UAwAAewcAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAA ACEAXlaZtdcAAAD5AAAADwAAAAAAAAAAAAAAAACrBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAE AAQA9QAAAK8GAAAAAAAAEPAIAAAApA+wB9AOihAPABHwEAAAAAAAwwsIAAAAAwAAAAkCEi4PAA3w UgAAAAAAnw8EAAAABAAAAAAAoQ8UAAAAAQAAAAAAAAAKAAcAAQAAAAAAAAAAAKoPDgAAAAEAAAAH AAAAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwPQkAABIACvAIAAAABgwAAAAKAACDAAvw ZgAAAH8AAQDvAYAAYL9PBb8AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABp AGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANQAAABMAIvEfCAAA qcMZCAAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR zUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4p uC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzG XgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZude w4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/ uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVs cy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2 tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0p oDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfX eKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAA ACEA8WDZg7QDAADYCgAAEAAAAGRycy9zaGFwZXhtbC54bWzsVt2PGjcQf6/U/8Hya0Rg+QqHbomA wrUSRSh7UZ8Hr/d2i9fe2l4CVP3fM+NdcqSqqiiXhzwEIRiv58u/38x479+eSsWO0rrC6JhHr3uc SS1MWuinmL9/XHcmnDkPOgVltIz5WTr+dvbzT/fV1FUMjbWbVjHPva+m3a4TuSzBvTaV1LiXGVuC x6V96lZWOqk9eAxUqm6/1xt3Syg0n6ErfUyqnSVJbI87y4o05mPONJQYMlFFKtm2LvfSsp0CIXOj UpRHvNuaNNaAKW2MOLg2L/iSvFILH/Cwn6XEtHmweKqIAnRDUtf8NKZHQauc+XOF2TmVYmoI0iXm f9VgvbQc8z/FfNhaNybo5vmULpwWpqfMli9NdnYPU5NlDCOOR6MBAsvZGeXBCL89ygGm8uSZQIV+ NBiMSUGgxmA8ivoBw26TCWlW1vkHaV6cFSNHMbdSeGQYpnDcOE9oPocI0DZIVFN/Wpj0TJp7/McS aErr6ynEmsb4ubEXzj5YQDYd0SM5U79pF/O7aDhEIHxYDEdv+riwtzv72x1dl0ujqCIYaIFeY+6v 4tLjijA1ZQV+o5NKkOIVzcfTH2CrFg+PTGxNkkMl/wuWRjeg1MBATpTziT8r+VJIgq+jitraS2X2 bmcbStT1MdJzDRfy/xYxMR4rwW4CSCi8CwKGDP+FTnEsBBHUE84gxRmm9gj7BDsqsETM+EZbwkYv 7CEQkRnt58FkD454xdmi2200yUE/YWPvai3QfcOHInLoYK4SO+HZEYjTHn1Cs+LpbzQWMvu37lUN 7Z9355n/H712d18vlX08hXbc18nlk7jGY3xabHHIBhUP+6ZhYHpLVMtdptIwI/+eRPNFf9yfdFaD N3ed4Wq96ixWy0Vn8svdMhrczUej1egfrPJ2VOEgxUoOlWeRlUNdFqX5s2gIQbxiLnXnfYKVrfwm rC95Z7ltpls0ocmxb1gLv3XMNSZMN4QtDjgMtUmCxNlBWrpPwjQS1H2tIvUGetF0M6jiIn8NSyJQ FXS/hL2dNSYLsiv9UklAV72QtdKEtDbrQqm2dMMTZ/CSoIeBCLqFJMLd8OtPzRxH1m+1ZJbhcLqC XG90S0JNblo5lFRAL8NrJ+ZzWwDWp8jBOhmKNpAl4Ubn94TtHozPC8FZVXiRr6EsFM3b4Y1lJ+pP mtks3I3xq1J3hGtrESmi4/zoH0Lhm/aPnzG6ibBt8RebiQJIne7AAs7EH33xfffFM1PN+0R4kbi+ QOB7lqtmHwEAAP//AwBQSwMEFAAGAAgAAAAhACe0aXPWAAAA+QAAAA8AAABkcnMvZG93bnJldi54 bWxEj0FLw0AQhe+C/2EZwZvd1GixsdtSBVERD60Fr2N2mgSzs+nuNE3+vYsHPT7e43t8i9XgWtVT iI1nA9NJBoq49LbhysDu4+nqDlQUZIutZzIwUoTV8vxsgYX1J95Qv5VKJQjHAg3UIl2hdSxrchgn viNO3d4Hh5JiqLQNeEpw1+rrLJtphw2nhxo7eqyp/N4eXTqZ6mP/Nqzzw83t+248zOe6CmLM5cWw vgclNMj/+DN/zR/4r/xFvVgDM1D75/ErNHaDUSgYSG7JNFmCXv4AAAD//wMAUEsBAi0AFAAGAAgA AAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEA8WDZg7QDAADYCgAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnht bFBLAQItABQABgAIAAAAIQAntGlz1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAsGAABkcnMvZG93bnJl di54bWxQSwUGAAAAAAQABAD1AAAADgcAAAAAAAAQ8AgAAACkDyAQYBWKEA8AEfAQAAAAAADDCwgA AAAEAAAACAISLg8ADfBoAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAK AAcAAgAAAAAAAAAAANgPBAAAAAAAAAAAAKoPDgAAAAIAAAAHAAAAAAAJBAQIAACmDwwAAADwAAAA 1AHQAvADEAUPAATwPAAAABIACvAIAAAAAQwAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8BEAAQ AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM AAAPAIgTMQAAAA8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAAACQEAQAA AAsAAA4EPA4AAFBLAwQUAAYACAAAACEA6d4Pv/8AAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54 bWyskctOwzAQRfdI/IPlLUqcskAIJemCx47HonzAyJkkFsnYsqdV+/dM0lRCqCAWbCzZM/eeO+Ny vR8HtcOYnKdKr/JCKyTrG0ddpd83T9mtVomBGhg8YaUPmPS6vrwoN4eASYmaUqV75nBnTLI9jpBy H5Ck0vo4Ass1diaA/YAOzXVR3BjriZE448lD1+UDtrAdWD3u5fmYJOKQtLo/Nk6sSkMIg7PAktTs qPlGyRZCLsq5J/UupCuJoc1ZwlT5GbDoXmU10TWo3iDyC4wSw7AMiV/PZyAZLea/O56J7NvWWWy8 3Y6yjnw2XsxOwf8UYPU/6BPTzH9bfwIAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsA AABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsI hKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYw lRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzl RQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACK AAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLL rrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0 jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQU AAYACAAAACEASK9sucQIAACXNwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0YQfo+U /4B4T4bDYBitN+JUHhIl2tkoj1GPjY8sBgvY69+nqi/TZqbBGbSbaG1LY9wuqqur6quqrmZe/fTp WBofiqY91NXKtH+0TKOo1vXmUO1W5h9v8x8C02g7Um1IWVfFyvxctOZPr7//7hW57/bFsTDg/qq9 Jytz33Wn+7u7dg3DpP2xPhUV/LatmyPp4Guzu9s05CPwPZZ3jmX5d0dyqEyjIkdgu/jrt7Lo3rcN eVdUVWG+FvyzEiapuhYH1mXzgNwLfpNyi2HTmzbvbCRtm91jUjbGB1KuTIu+zLvXr+7IPScouyFd Tl+cjhNs3jlj/ChB2Q3pAgvfkh8lIOs1LGc4dxxnVuZy2h4RuxzyduEVhgp9j787kFlZG2NKidjl YkCv6KxHxC69AX0aZWmWK/JQIkbvD+id1EmDSKGnRPvyUL0bUFtWCC9OLUm2dfnzk+RhmCSWUPyZ CqwvXQin2NZVpziU84QXHsnfdZMDJd5Rku5QGd3nU7Ela3BblIjcF2QwtG4vhmBuhdPxUM3F9swJ Jjmvia7wqC7wt+32sGbo2h7K8qH7XBa/tHRpbV0eNjkM4n0UxIUE0GkPl1z7Ct2uIfQeo6m7Pw/d /mFPTqAWBsVdy1nvWuNUt4BD81ne+AOotmOA9dD7mG5b0v1ab9iw28exFJGiekcDhJjIRQZTJ3OX L5vMZlJNXJpNRaNuoyxNLhlsOFwaDEptgscbBKOz7UMYRdmNdk3KYoN6ZzFOmAVlEtezmKjdk03B bYTrHtrIpkYSvkKjNfjOEzYKqOharfVmC5HtC2abYqT+dItnphPWe4mVRGASlqHKuYRjWfXBWVbG x5UZeo5nGmtyWplbiERweTyB1dtqZxqk3EH+XncNc/tRMFPFn60ZioWB9/UQZ1tifLBgJQ6cmrZL SbtnrkF/4i5QVjgTk9/xQK1zLYB5+r+Qwg3AGb6aFKBH1bTFdlusu76xeyOoO/aVh9L6fVc0D/vN R+OxfN+8IWB+dFVYz+bQdiuTRgT80qxM1Db9SQ3OPDA+USDhbKQ87QkPtwhRgWRGTl1VykC/9cSD tT0pO13c9UuhkJ9pKX03/saWgvmkqAp3gxZYQ7XdEAPxujLrptvXEIVO+8M6b6DEobEDvMWA6ILp 2oCan342xQf8ZJhjPJBbedjtuzeHndEcIB91+6YofoewRL1vhJnNcxdjKRhRj+qJ256Y2I/Fh6J8 izHQx9xuGntwdRpNeBigdJf+p37nCHrcYZHTx5sSQ2TuZRj40pUPAzMsSo3DtKAR+pciUm2plQ+7 n94ucm9/IfjDucxaCFTAZL1UEHLY/0sRrky1LGINVux4Qjiw4nDFMCgLohPp9gb+gfx3aNblub59 W7+B2GrAFhCZgduAV//ACg8DAyQbfITCiQ0yZ0JWTLW8ukWtiWQ9Sxl1NoGc90LZKNkUe1+pbFmc qdMpWJxT2VzDiq7Z2LOqBsteQhSGtmIjQw1DOw/9zkD9+DcYOoVd2fuya6kzFZ+6hkDp+UBxwMGv DqJd14Li1lMwbz0F3D+/rKcA/vQrORmPO3tlQgsJQs4nuIKmkwljDo45OAZX0FmCsp21g1YmvxAj 8DsbkTSuGHEFzUKMLMSIJ0Zgm8AbL2LEh5yJvRLo0+GHaYiFwl6CL5mn9yFGhiN61Di0jvgvdeJC H99iS8JadVzjNFf2i+E8TnPvik5cnoehL3hzoyFTdvnlO3F5miWxKr+2E5ctg8hLuG6416D8ss2m 9FKTxIUkwqkliXChgTJRNZL8TAURXboQ3nNDTWG4/znUXNO/xpZrrvZ/aZO7B4gLPxrQO18TNUmU ORfya1ETh3GYLaeiBjNrIjA2jpoo95dSmBtqdKc+ixejBo4t/Fx0Tmc49bkq1/RPnBhUtKgJ0sSX jtGDFrsc5posyaNc9dJZT32eOFXSomaZx+501MAhoX8Faiwrgu0Uh+QNNTrUeC9GDVo+FSdyM6Bm SV/cePwwtQcIJXdQr1O9WosajL3SjyagBvlnYm09aLHLl5+VUvnVs08tapwUs83UXJPnHnTtOfV4 rsHy9YYaeKiA16GsX/BkN8DXoMaLvIDrfJYnDHpPDvBHEJ56wgA9SZ6Lj6AGounCdxQv0qLGT/08 UVGmrdCiKLES4XcTUJNG+FbkodBit1JAKKiPojiIVXm0qPEdfxEvFP7aJwxQl5x6HDWWledXoobu 92k3gPYFaDeA9gVoN4D2BdjSoV/AL8Qu/n/dDVg+ixovsc9KnAE1tJkqPFCDmjRPnVDskEdQo+x3 uVnO+xQKCMVL42wZ+kIGRq9FTWJF8FK8VFuhXYuazAGQqfy1qIkSP/XUboYGNUr8GUdN6kaOLRLZ tArtW0VN8CxqLMt1Zb9pBtTgSYPMIRrU4H5dRsgR1KCEFxWXNtdYVnw+75iAGsRMonr1rKiJ0jjI 1FypRQ1o8BzJmPwa1KBupCbHUQPF6NKyeYi4oUa3rwmfRQ16ZM/LqTfybYsSv9HHpW1m2Ndkbhb3 ugu9XEBFUOZGZEsZJ+SahR9Ei1jJHT3+w24AouYiF8yLmihKL1CpRY2bL9OFyMOzo8bK4KTxhppi fF9js0eCeC5RXFLZls+QbPzAj72UW0WTbFI7tRPh2iPJJrRCK1CDtTbZBFaYRWKzNiHZwOY7itWS aFbYJD68RXxn8mhhs3SDPFTl1ySbPE8SWS6MJ5ssTBPZa7glG12ysZ//jwMXwr48U5sDNr6SvWiU 56hQ4HqRvXrZYJhtfMsLlwJiE7INiODLzDgFNkEcXGSDWWETQySJxY59Amy8xEum956V86xx2KDi Zeq+wUYLm+cfD4B/CrFsT2aHFxdpnuNmjojcumyTJ1YgstJItgmSZbwUdcUE2AS5lzuqm/ZgOSzS YjfKI3FUyPjPCpsEQBOrsNdmm8D2PEfdammyTZLE8Agit+A4bIIEUrEg/5ZgAw9AqE/V0AfUYJQ+ 2vb6HwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVs cy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs 7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYk UiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04Goln Lx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQDp3g+//wAA ABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh AKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAAMAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAGQIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54 bWxQSwECLQAUAAYACAAAACEASK9sucQIAACXNwAAFgAAAAAAAAAAAAAAAADWAgAAdGhlbWUvdGhl bWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAAM4L AAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAA yQwAAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRh bG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJs dDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQz PSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJh Y2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPiAAHgR8BQAAUEsDBBQA BgAIAAAAIQBNjvP8/QAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5Qt atJhgRBqOwseKwQshg+wEreNyEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vf d0/VLWeUwWuwwWPLZyS+7S4vmt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xup gs/oc5WXHbxrHrCHyWb2eCjlo5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl 8zfgpHstr0lGI3uDlF/AFRtSJ5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI 9fXdJwAAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrC MBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s 6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5g T3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLv B9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAPBVrZ9JAgAAkgYAACEAAABkcnMvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0MS54bWyslV1v2yAUhu8n7T8g7lun6TRNVpJKy9bd9CNa0h9wiknMigEB 9ZJ/vxdsp2qXSYm6G3/gc17O+3DAk6tto1krfVDWTPnF+YgzaYStlNlM+cPq+uwLZyGSqUhbI6d8 JwO/mn38MHFl0NUN7exzZNAwoaQpr2N0ZVEEUcuGwrl10uDb2vqGIl79pqg8/YZ2o4vxaPS5aEgZ 3uf7Y/Lteq2E/GbFcyNN7ES81BRRf6iVC4OaO0bNeRkgk7NflxR3Dm7t4y8+g1Wx1BUz1GBopaKW DEDY3JqI5BwQ3MpLmUJN+8O7pVv4nHfXLjxTFcjyPp8X/Yc+LL8ahOGheJO+GZSo3K59M5tQCf9s O+VYpl26IolKuY1MdIPiZVTU9wdiRf39QHQxTIAK9pNihV3n6G8748FOh+Ni76oLJaTeWPEUmLHw mex39sRdO4glz0ne1ayDHRPZPq77mHkM8QFMM6y4/WqrXTL+iHsepFKHuIw7LTMQlE0lxHEBfk2p l6U5e1iil5s415LQ6z28OJtrJZ5YtExWKrJbClF6lotB50NyAjoRi9NLSlMtyNPPN8rJH5WYGUUP FeKxQ/hvkJcDyL6b2EKTkLXVFYoYvw+rqtAUA/n/QBQLwHSr9+jeSTi1bQYcXhHuKGaUuAxTZhsn LOpSCos9qmUr9RHymfQJ8qta+ePVL9M6nqB+bZ99rI8u/tOp8mp9UB0nycm9nVu8O/vwmM7JfLxp f0vuvs0dgj8BdtQ8Dzmc/WmnIPQlJGkM/5LZHwAAAP//AwBQSwECLQAUAAYACAAAACEATY7z/P0A AAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA IQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA IQDwVa2fSQIAAJIGAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAnQQAAAAAAAAdBAQAAAABAAAAIAC6Dx4AAAA0AF8ATwBs AGUAdAB1AHMAcgBhAGsAZQBuAG4AZQAPAPADdUIAAAEA8QMIAAAADQAAgAIA+C0PAAwETS8AAA8A AvBFLwAAQAAI8AgAAAAHAAAABzgAAA8AA/DpLgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAAA4AAAFAAAADwAE8PEIAAASAArwCAAAAAI4AAAACgAAgwAL8EgAAAB/AAEA 7wGAAGCvYAW/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBn AGwAZQAgADIAAAATACLxBQgAAKnD/wcAAFBLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/ LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsY Ugr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HS pQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9T FsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx 3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxj y1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1O NGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V /IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2 DwAAAP//AwBQSwMEFAAGAAgAAAAhAFdb87yZAwAAuQgAABAAAABkcnMvc2hhcGV4bWwueG1srFXb bhs3EH0vkH8g+BooulR2bCHrwBZqt4BiCF4HeeZyuV5WXHJLcnX7+s4MV5cWRVBE0YM0FOc+Zw4/ fd42hq2VD9rZjI8/jDhTVrpS27eMf319HNxwFqKwpTDOqozvVOCf79798qmdhZaBsQ2zNuN1jO1s OAyyVo0IH1yrLNxVzjciwtG/DVuvgrJRRAjUmOFkNLoeNkJbfgeu7Dpvlx4l+bxeeqbLjF+Pp9ec WdFA1BclIYc3o9iED3u1ZCEgjYWTq9DnIv5PLqUXGyjwH2kw6548VDKGmG5eQzR1773b1EqUAf+G uEPK75CqhUwxl7ZmcddClnXpoVn7jP/VCR+V702SHtieqgxQLSs2X1wJZqKLDrogZtvKN5eWgX5c VbFtxmGUO/yGxMVMbSOT8Ofk9uP4ZgRXEu6mVx9hDpRmio6arQ/xSbmLM2HoKOMeRkfVifUiRGzi KQSGs+5RG3Np2VSjsZe6YZuM315NrijhlBl5bjSMkxndZByaB5/UVMTGb7YklSi0STIUaCz1vKqg eKj60rSwa7hvCW9x++DKHQYo4BeAlLbwx5EP6w+Dqp3fc7bxApYgIIIVZ+YPC9i/HU+ngJhIB8IM Z/78pji/sV0zd4YWSVgJXjMeOUviPMIJweeaVsSFzVuJigfYvW6/Cd/2wIkA2WeX16JV/4WfpEtw Sm1AJybEPO6AJi5sCflamzF1XMxKVb1An3G1x6eFMQcFHHgfmCr5GdGRIBrhF9QuEF5IgJD0q20J XEqiMG9A3IYzSPJVFDnkSPOCLvuYtJVY2Ae/opFUzsZ7MilEwAkDIdv+GkyQ94AZl52V4D5NxuCY sLDQyqWMbC1wusc1ILifNB5U9W/dA8OA/en2vorf0etvi25u/OuWFqzo8v1RfIQyjodneJn6HSxg 20hMI8PFAbrBvQEKtOVSeIGTXHWNbtyfOjUVas64soOvOeDUxAWd9/Vg/pzonGbOitR5+u4ybiEo Po1er4DDrctJ4mylPD6kCBMmcZd6RUQ6/GXxSTR6r36nIw7BaHxY6W7pnatIDk2cGyXA1YjQnxjl SElHjgnO6BIZlJqJz6+ClqUZxW16tWBy51rqQEvUqG5h+0Z26KaXCRb0rFVCQnb3XgvAmKyFD4qA R8ZKnOl8ydnyycVaS85aHWX9KBpt4Jn5dXpmORhPbhJ7ynBm/L6xAxn6p+g0qTQ/or8D7RET3v0N AAD//wMAUEsDBBQABgAIAAAAIQAnxHWs1wAAAPwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Ra8Iw FIXfB/6HcIW9jJlWRhmdUXQg7nGtBV/vmmsbbZIuyWz77xf2MB8P5/AdvtVm1B27kfPKGgHpIgFG prZSmUZAddw/vwLzAY3EzhoSMJGHzXr2sMJc2sEUdCtDwyLE+BwFtCH0Oee+bkmjX9ieTOzO1mkM MbqGS4dDhOuOL5Mk4xqViQ8t9vTeUn0tf7SAp2WXHffp8HmpUBXlVJGfRhLicT5u34AFGsN9vDv0 36fTf/mH+pACsvQlA3Y+TF9OyQJ9ICcg6kXZKAp8/QsAAP//AwBQSwECLQAUAAYACAAAACEA8PeK u/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAI AAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAI AAAAIQBXW/O8mQMAALkIAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0A FAAGAAgAAAAhACfEdazXAAAA/AAAAA8AAAAAAAAAAAAAAAAA8AUAAGRycy9kb3ducmV2LnhtbFBL BQYAAAAABAAEAPUAAAD0BgAAAAAAABDwCAAAAAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAK AhIuDwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPFgAAAAEAAAAAAAAACgAHAAEAAAAAAAIADAAAAKoP DgAAAAEAAAAHAAAAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATw9AgAABIACvAIAAAAAzgA AAAKAACDAAvwSAAAAH8AAQDvAYAAwGBgCL8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAABMAIvEGCAAAqcMACAAAUEsDBBQABgAIAAAAIQDw 94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tH FV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7e kYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVL HX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUk XjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP// AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9 cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xY fYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23 Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/ 6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAaevrHpkDAADCCAAAEAAAAGRy cy9zaGFwZXhtbC54bWysVVlv4zYQfi/Q/0DwtfDaTpzEMVZZJEaTFvAGRpRFnymKilhTpEpSvn79 zgzlo0VRFHX9YA891zf35y/bxrC18kE7m/HxpxFnykpXavuR8W/vz4MpZyEKWwrjrMr4TgX+5eHH Hz63s9AyULZh1ma8jrGdDYdB1qoR4ZNrlQVe5XwjIjz9x7D1KigbRQRHjRlejUa3w0Zoyx/AlF3n 7dIjJV/XS890mfHb8eSOMysa8PqmJGD4MIpd82EvljQEwFg4uQo9FvFvsJRebCDAP8Fg1r14iGQM Pt28Bm/q0Xu3qZUoA/4NfoeE7wDVAlLE0tYs7lpAWUYOyLcn4SQBWqf4AsTJis1XV4KC6KKD+MVs W/nm0gDQjqsqBv6vp9NbSDBnu4yPELiYqW1kElhX93fjKbIk8CY3dyiGkSUMKNn6EF+UuxgPQ0MZ 91A6ilGsFyEmVwcX6M66Z23MpcFTjMZeaoZtMn5/c3VDgBMystzoqDwzusk4JA8+KanYGz/bkkSi 0CbRkEtjKedVBcFD1JfCwqzhvKV+i9snV+7QQQG/0E5pCv9758P4Q6Fq5/ecbbyAIQh/dMIrzsyv Fnr/fjyZQMdEelDPcObPOcU5x3bN3BkaJGElWM04zEUi5xFe2HyuaUVc2LyVKHhou/ftb8K3feNE aNlXl9eiVX/XP0mWOjelAY2YEPO4gzVxYUrI1tqMcViF+YDN6AlDqao3+CvsAfVpckySJCwHBBTS /wEDITTCLyhvQLwRAS7pV9sSliqRB5wMQL6LIgeMVDhIt49JWomFffIrqk3lbHyk0AoRsNSwmW3P BhVcgLAil52VYD6VyGC9MLDQyqWMbC2wzMd5oL4/STyp6q+yh1UD+ifuYxX/Qa7nFt3c+PctTVrR 5fsj+QxhHB+vcKL6YSxg7IhMJcMJgtWGAwS70JZL4QVWctU1unG/65RUiDnjyg6+5dCwJi7ova8H 81c4goeasyJlnr67jFtwijfS6xWsdOtyojhbKY8XlfawxKHqBbHlIcEWb6PRe/ULPbEIRuOFJd7S O1cRHZo4N0qAqRG1YFotx910XDbBGV3iKqVk4h1WkLJUo7hN5wsqdy6lDvuJEtUtbJ/IDs30NLUF 3bdKSED36LUwMMC18EFR45GyEmcyX3O2fHGx1pKzVkdZP4tGG7g315MzzcH4aprWqAxnyj81diBD f5NOlUr1g+92dth/tBIfvgMAAP//AwBQSwMEFAAGAAgAAAAhABYs/qDYAAAA/AAAAA8AAABkcnMv ZG93bnJldi54bWxEj1FLwzAUhd+F/Ydwhb2ISzuklm7ZGMKYoA+26w+4NndtZpOUJK7tvzf4oI+H c/gO33Y/6Z7dyHlljYB0lQAj01ipTCugPh8fc2A+oJHYW0MCZvKw3y3utlhIO5qSblVoWYQYX6CA LoSh4Nw3HWn0KzuQid3FOo0hRtdy6XCMcN3zdZJkXKMy8aHDgV46ar6qby3gYd1n52M6flxrVGU1 1+TniYRY3k+HDbBAU/gf5++8ecv/yl/UqxSQpU/PwC6n+dMpWaIP5AREvSgbRYHvfgAAAP//AwBQ SwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQBp6+semQMAAMIIAAAQAAAAAAAAAAAAAAAAACkCAABkcnMv c2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhABYs/qDYAAAA/AAAAA8AAAAAAAAAAAAAAAAA8AUA AGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAAD1BgAAAAAAABDwCAAAAAAAkAngECABDwAR 8BAAAAAAAMMLCAAAAAEAAAAHABIuDwAN8FYAAAAAAJ8PBAAAAAQAAAAAAKEPGAAAAAEAAAAAAAAI CgACAAcAAQAAAAAAAgAMAAAAqg8OAAAAAQAAAAcAAAAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQ BQ8ABPCCAAAAEgAK8AgAAAAEOAAAAAoAAHMAC/BCAAAAfwCFAe8BvwAAAAYAvwEBABEA/wEJABkA PwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA0AAAAAAAQ8AgAAACwAdACEA4g Cg8AEfAQAAAAAADDCwgAAAACAAAABQASLg8ABPCnCQAAEgAK8AgAAAAFOAAAAAoAAIMAC/BIAAAA fwABAO8BgABgYGAIvwAAAAYAvwEBABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABh AG4AZwBsAGUAIAA1AAAAEwAi8W0IAACpw2cIAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMA AABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh3 3950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qi ux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQ Dwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgo a8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAA ACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sK W0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDf vb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D 6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XH rBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQDQ8tXXAQQAAE0WAAAQAAAAZHJzL3NoYXBleG1sLnht bOxY227jNhB9L9B/IPieteVL1jFWWSRBkxbwBkacRR8DSqJi1RSpUpQv+fqeIeXYDrZAsS7yENgB 5FE45MycmTMj68vXdanYUtq6MDrm0acuZ1KnJiv0c8y/P96ejTirndCZUEbLmG9kzb9e/vrLl2pc VwybdT2uYj53rhp3OnU6l6WoP5lKaqzlxpbC4dY+dyora6mdcDBUqk6v2z3vlKLQ/BJH6eWsmlqS 0vvl1LIii/l5NLjgTIsSVh9kCh+elWRD3mnVwg4BNyYmXdStL+K/+JJZsUKAB24wbe4sIolg09zM YU1eWWtWcymymv4Nux3v39ZVDU/Jl2rO3KaCl4nJNkDrJeZ/N8I6aTkCWce83+4NG3DILtwaYbNk 9c1k2C8aZwCHGK9zWx4bD51j8pzB/kU0GHSR2E3MB338QUYwYizXjqVYH3Z7F8gHZylpRNFgFDQ6 wRNSrWzt7qQ52itGB8XcIp8+UrGc1I6Q3Zkgc9rcFkodC4EPUuljj2ErQDjsDb3DwTN/clkgxUwV ZcwBGD4BVSqY33TmVZwoVJARoNIe9DxH8Ij6WLcINSJhKEK3vkb1kQGqQhRVoObP0wE9AYmaG/vC 2coKMKOmqpacqT80COGLijPnbwbDzz3Uj91fSfZXdFPeGOXZJXSKU2PuOAvijcMdVZ8pK+Emelal pLgtu8f1n8JWbeE41Oy9mc1FJX9UP0HXl1OAgQ5RtZu5DXrHkZD4jG573k8D68NCfkphJz5sCA9e UEsABBwKnaFRelGoZ3RlxVkm80eRzNBatmS2LmhLMdHXduHVc6Pdld+SiJoyhW6rd8vU1ND2po1O /fEeHIKbhLpKp6ljS0FZei1nX7Y7jWuZv9Xtbysfqjhjp3GVu7e6niFBr11NmhtlH9ce2qSZvbyK twjl9eYeo6flUxL6hRgDkYepJRKgdRAHxDhcgO2iKYvS/FUEWBF1zKU++z4LzTnyvS4JWPtrE3MN EzTpbLFAJ9Zm5iXOFtLSXAztkVjQKlKNIleaJpwqXuTv/pZgVwXNSb82tcbkJJN3gf6v/cMj6wEy qsio3fkbGqASmIREuHWYO4B2X0tue4gHpZnoFqmGjmlln3s/mHKRwqErWwgUUjoXtpY+/X6zFHs6 32ZsemfcvEg5qwqXzm9FWSgMhf5gb+dZ1BuFVpfW/7L50ApCtSFD7pI94YNL+PbXVqaFpydKJ+qG toTUEir/M+l8t0KCDpmHwX9i3jhpTsyjFvhBmRe49i4s2w6qQ5b1TixDQzux7KPPt3caZVH/c3RO P90OWdY/sezEso/+FPmOsywa9Ub0UuQNzfBUfHpkPA2zD/9j7cfDDG+ftm+d/Iuoy38AAAD//wMA UEsDBBQABgAIAAAAIQCzwnT81wAAAPwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LasMwFET3hf6D uIVuSiM7FJO4UUIohHRZPz7gxrq21VqSI6mx/fcVXbTLYYYznN1h1gO7kfPKGgHpKgFGprFSmU5A XZ2eN8B8QCNxsIYELOThsL+/22Eu7WQKupWhYxFifI4C+hDGnHPf9KTRr+xIJnatdRpDjK7j0uEU 4Xrg6yTJuEZl4kOPI7311HyV31rA03rIqlM6fXzWqIpyqckvMwnx+DAfX4EFmsP/uMbq3F7/yl/U uxSQpS9bYO15uTglC/SBnICoF2WjKPD9DwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADi AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx 3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDQ 8tXXAQQAAE0WAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgA AAAhALPCdPzXAAAA/AAAAA8AAAAAAAAAAAAAAAAAWAYAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA BAAEAPUAAABcBwAAAAAAABDwCAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAMAAAAGAhIuDwAN 8KIAAAAAAJ8PBAAAAAIAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVz DVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAA ACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8OAAAAUwAAAAcAAAAAAAkEAAAPAATw AQkAABIACvAIAAAABjgAAAAKAACTAAvwTgAAAH8AAQDvAYAAwGNgCIcAAgAAAL8AAAAGAL8BAQAR AP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANgAAABMAIvEPCAAA qcMJCAAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR zUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4p uC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzG XgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZude w4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/ uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVs cy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2 tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0p oDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfX eKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAA ACEAAHu4M6MDAADHCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVdtu4zYQfS/QfyD4Wnhtp042MVZZ JEaTFvAGRpzFPo8kKmJNkSpJ+fb1nRnKlxbFoqgbA/HQHM6cuZ359HnbGLFWPmhnMzn+MJJC2cKV 2r5n8uvb0+BWihDBlmCcVZncqSA/3//4w6d2GlqBj22YtpmsY2ynw2EoatVA+OBaZfGucr6BiEf/ Pmy9CspGiOioMcOr0ehm2IC28h5N2fWyXXiSipf1wgtdZvJmfI1gLDTo9VUViOHdKHEjh71aegEI Y+6KVeixwL/BUnrYYIB/gSGse/YYyRh9ulmN3tSD925TKygD/Yx+h4zvANUiUsLS1iLuWkRZRY/J 2mfyjw58VHjQ5TaTk/5p0kcbp2gDRi3yzRdX4nPoosNswHRb+ebScMiOqyqB/jGLu0ze3uBnNCIs MFXbKAq8urr7OKYfRYEak+uPWBUGmzCQZutDfFbuYjyCDGXSYyE5RljPQ6SUnlyQO+uetDGXBs8x GnupGbHJ5N311TUDTsjYcqOxuMLoBrM6or+UVOqUX2zJKhG0STIGaCznvKoweIz6UliUNZq+1H1x ++jKHTnI8RvbKc3kf58DJAMsVO38XoqNBxyJQP2spDC/WZyEu/Fkgh0T+cA9I4U/v8nPb2zXzJzh sQJboNVM5lIkcRbxRM3nmhbi3C7bghQPbfe2/Qa+7RsnYsu+uGUNrfqn/km63E4pDWTEhLiMOySN C1PCttZmzBmHaamqV8wzDfr4NDDmoEAF7x1zJP+Hd6KJBvyc04XCKwvokr+1LZFZWQTzjjRupECQ b5AvESPXC7PsY9JWMLePfsUlqZyND/wkh0AVRnq2/TU+IRZEnlx0tkDzqTKGykSBhbZYFFGsgap7 HANu95PGo6r+rntgGHx/un2o4nf0+tu8mxn/tuUBy7vl/ig+YRjHwwvuqX4Gc5w2FlPJaHCQbmhu kAJtuQAPVMlV1+jG/a5TUjHmTCo7+LrEPjVxzud9PZi9JHLnmos8ZZ7/d5m06JQWpdcrZHLrlixJ sVKe1iq1iSholnpF6nT8ydKCNHqvfuUjFcFoWrN8t/DOVSyHJs6MAjQ14u5PjHKkpCPHBGd0SQzK yaRlrDBlqUZxm3YYVu5cSx1oiRPVzW2fyI7M9DK3BS+5CgpE9+A1YI8VNfiguPH4sYIznS9LsXh2 sdaFFK2ORf0EjTa4Zn6enL0cjK9uE3sW4ezxT40dFKFfRadKpfox/R1oj5nw/k8AAAD//wMAUEsD BBQABgAIAAAAIQAjTTqP1wAAAPwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BTwIxEIXvJv6HZky8 SXdNQLMyEDEqGk8gCddxO2w3bKdLW2H59zYe9PjmTb6XbzofXKeOHGLrBaEcFaBYam9aaRA2ny83 96BiIjHUeWGEM0eYzy4vplQZf5IVH9epURkisSIEm1JfaR1ry47iyPcsudv54CjlGBptAp0y3HX6 tigm2lErecFSz0+W6/362yG8Rrs4eB324cMMvkzPY3e3eUe8vhoeH0AlHtL/82LZH7bbv/IX9WYQ JuU4y+yW56/QmhXFxAEhX7JsFgU9+wEAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h 0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAAe7gz owMAAMcIAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAh ACNNOo/XAAAA/AAAAA8AAAAAAAAAAAAAAAAA+gUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAE APUAAAD+BgAAAAAAABDwCAAAAGAVAABQB4AWDwAR8BAAAAAAAMMLCAAAAAQAAAAJAhIuDwAN8FQA AAAAAJ8PBAAAAAQAAAAAAKEPFgAAAAEAAAAAAAAACgAHAAEAAAAAAAIADAAAAKoPDgAAAAEAAAAH AAAAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwegkAABIACvAIAAAABzgAAAAKAACTAAvw TgAAAH8AAQDvAYAAgGRgCIcAAgAAAL8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAAC AFIAZQBjAHQAYQBuAGcAbABlACAANwAAABMAIvFwCAAAqcNqCAAAUEsDBBQABgAIAAAAIQDw94q7 /QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0f YEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYId Mayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6O STxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGm Z5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQ SwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpD GaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCS gtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9m QLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZUR E31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEARc5ncgUEAAAtDAAAEAAAAGRycy9z aGFwZXhtbC54bWzsVt2P4jYQf6/U/8Hya8VB+AZd9sTSY3sSh9Cypz6bxNmkOHZqOyxQ9X/vzDh8 tKqqqtxDH25Xgkk8nvnNx2+G9x8OpWJ7aV1hdMyjdx3OpE5MWujXmH95WbTGnDkvdCqU0TLmR+n4 h4fvv3tfTV3F4LJ20yrmuffVtN12SS5L4d6ZSmo4y4wthYdH+9qurHRSe+HBUana3U5n2C5FofkD mNL7TbW2KCWr/dqyIo35MBpEnGlRgtdnmQCGVyXZiLcbtXBDAIylSXauwSL+DZbUijcI8E8wmDZP FiJBn2aegzc5s9a85VKkDl+D3zbhO0PVgBSxVDnzxwpQOpWu6hLydYr5r7WwXloOoRxiPmhuhytg 5hqwg8DZ9u2zScGCqL2BhIjpIbPlvRGhHZNlDPz3xuMhZJyzY8zHQ/gHGeIRU3nwLAGF7mQU4UuW gEZ/MEJlDDggQc3KOv8kzd2oGBqKuYWKUqRiv3Q+uDq7QHfaLAql7k0Bxaj0vWbYW8wng+6AAAdk ZLksoMRMFSVktYN/IanYMh91SipeFCrIkEulKedZBsFD1PfCwqwhDUMb+sOjSY/oYAvf0FSBnP+d EDAVoFC5sSfO3qwAbjjsasmZ+qSBEpOo34eO8fRAPcOZvT3Z3p7oupwbRfwSOgGrMd9yFsS5hyds PlNWwi/1pkpQ8dx2L4efha2axvHQsiuzyUUl/65/gi51bkgDGlHOb/wRpsedKSFbexUhZYV6hYFp CUMqs2d4hbyPrsxRQZOwnBFQSF8DBkIohV1S3kB4JgFc0nehU5i1JJ5xMgD5IrYbwEiFg3RbH7Sl WOpHu6PaZEb7GYW2FQ5LDQNbN8dwBeciTM51rRMwH0qksF4YmKuSdeLZXmCZL3ygvr9qPMrsr7rn UQP3r6ezzP+DXnO6refKvhyIadt6c7qICwjj8rCCzdWQcQu0IzGUDBkEow0JJKaZSmnx/DbvLnrR 43jRGs1/7LT6HyfD1mQx6bUms9ls3I9Gi05v9js0fjP0C8g1jH00YaEqu7osSvNLEQoC+Yq51K0v G2h25Zf0fMpb81XYE9QvbBuqRp91zDUAxrVrix0sBW02JHG2kxaXNE3yBAnZKCJdoDga160qTvIn esQCqgKXNp2trTEZya70cyUFmOoQ6jCWLnPtMqicUUWKY5gKgatdQrpDff0hbESo+q2WPM82SnK9 1E0RajTTyNRSlL1MJIBuZguhgPy5sE5S09JlKW50Pm/Y+sn4vEg4qwqf5AtRFgp2Va9/c7MVdcdh BCfu5vIPpW4lrtlnUCIM5xt/MAtflT/+gSGbgLbwCWRCB1Kna2EFTsdvvMCd/7/lxbVSYSbCZzU9 /6agnxkPfwAAAP//AwBQSwMEFAAGAAgAAAAhABz0GzLWAAAA/AAAAA8AAABkcnMvZG93bnJldi54 bWxMj81uwjAQhO+V+g7WVuqtOKkEVAGD+k8RJygPsMRLnBKvU9uF5O1rcUAcRzP6Rt903tlGHMmH 2rGCfJCBIC6drrlSsP3+eHgCESKyxsYxKegpwHx2ezPFQrsTr+m4iZVIEA4FKjAxtoWUoTRkMQxc S5y6vfMWY4q+ktrjKcFtIx+zbCQt1pweDLb0aqg8bP6sgs9gXn6d9Ae/0p3L4/vQjrdLpe7vuucJ iEhdvBq/rfrxz6U8o760glE+zEHsF/3O13qNIZJXkPSSbBIFOfsHAAD//wMAUEsBAi0AFAAGAAgA AAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEARc5ncgUEAAAtDAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnht bFBLAQItABQABgAIAAAAIQAc9Bsy1gAAAPwAAAAPAAAAAAAAAAAAAAAAAFwGAABkcnMvZG93bnJl di54bWxQSwUGAAAAAAQABAD1AAAAXwcAAAAAAAAQ8AgAAABgFZAJ4BCAFg8AEfAQAAAAAADDCwgA AAAFAAAACAISLg8ADfBsAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8YAAAAAgAAAAAAAAgK AAIABwACAAAAAAACAAwAAADYDwQAAAAAAAAAAACqDw4AAAACAAAABwAAAAAACQQECAAApg8MAAAA 8AAAANQB0ALwAxAFDwAE8DwAAAASAArwCAAAAAE4AAAADAAAYwAL8CQAAACBAQAAAAiDAQUAAAi/ ARAAEAD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADr LggAAAB2y8oBkAfHzgAADgTYCwAAUEsDBBQABgAIAAAAIQDp3g+//wAAABwCAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbKyRy07DMBBF90j8g+UtSpyyQAgl6YLHjseifMDImSQWydiyp1X790zSVEKo IBZsLNkz954743K9Hwe1w5icp0qv8kIrJOsbR12l3zdP2a1WiYEaGDxhpQ+Y9Lq+vCg3h4BJiZpS pXvmcGdMsj2OkHIfkKTS+jgCyzV2JoD9gA7NdVHcGOuJkTjjyUPX5QO2sB1YPe7l+Zgk4pC0uj82 TqxKQwiDs8CS1Oyo+UbJFkIuyrkn9S6kK4mhzVnCVPkZsOheZTXRNajeIPILjBLDsAyJX89nIBkt 5r87nons29ZZbLzdjrKOfDZezE7B/xRg9T/oE9PMf1t/AgAA//8DAFBLAwQUAAYACAAAACEApdan 58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2gi G9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8 UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/ s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAA IQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2h d5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzF LGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0B AAD//wMAUEsDBBQABgAIAAAAIQB0sUijYAYAADIbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnht bOxZT28cNRS/I/EdrLm32T9NyEbdVMnupoE2bZTdFvXonfXOuOsZj2xv0r2h9oiEhCiICxI3Dgio 1EpcyqcJFEGR+hV4tmd27cwsSdoIEHQjZWfsn9//9/zsvXrtQcLQIRGS8rQd1C/XAkTSkI9oGrWD O4OdS+sBkgqnI8x4StrBjMjg2ua771zFGyomCUGwPpUbuB3ESmUbKysyhGEsL/OMpDA35iLBCl5F tDIS+AjoJmylUautrSSYpgFKcQJkb4/HNCRooEkGmwXxHoPXVEk9EDLR16RJvsKgRpO6npMiGnaY QIeYtYOa+QQrm1dX8EYOYKqM2zGfHJcDRpPGafQMgKkybr2m/+b0DACHIchf5r293av1mjnWAdnH Mu0mfFotD+/Qb5Zk9nSzRA3IPl4p4T2bOSD7uFrCd7d63d6OJ48BWfxaCd/oNrrrWx7egGJG00kJ Xau14JOj55AxZ7uV8Far06kVhl+gwPvzmNEsxjxVXgTZmAv0XILvc7EDAP3CsKIpUrOMjHEIsdnB jA4F1fLgDYKdGTsUytKQ5oVkKGim2sEHGYY4X9B79fy7V8+folfPnxw/fHb88MfjR4+OH/5gaXkL d3EauQtffvPpH199hH5/+vXLx59X46WL/+X7j3/+6bNqoHKBL7548uuzJy++/OS3bx9XwLcEHrrw AU2IRLfIETrgCehmDONLTobifCsGMabuiq00kjjFmksF/Z6KPfStGWa4ArdNfAveFRQqWQXw+vS+ J3A/FlOVu9zT7EaceMA9ztk2F5VWuKF5OY4fTNOomrmYurgDjA+reHdw6vm3N82gINIqkp2YeGLu M5wqHJGUKKTn+ISQCjPco9Sz6x4NBZd8rNA9irYxrTTJgA69aFos2qUJ+GVWJSD427PN3l20zVmV 1l1y6CMhKzCrEH5AmGfG63iqcFJFcoAT5hr8JlZxlZD9mQhdXE8q8HREGEe9EZGyas1tAfo6Tr8B 1aPa7XtslvhIoeikiuZNzLmL7PJJJ8ZJVoXt0zR2se/LCYQoRvtcVcH3uJ8h+h38gNOl7r5Liefu 06vBHRp5Ii0CRM9MhfYlVGuvCCc0fVuRz1yRtwStTIndE3V4Ge5k9e1wMaL//uLbxdN0n0C8l3eg t7X3be0N/vO1d1k+n7XiLoos1F/d59gG2bTLydJueUwZ66sZIzelaZglbBijHRjU68z5j8xPY1kM j3mB93CRwGYNElx9SFXcj3EGzXbd9OORzElHEmVcwqHODFfS1kyhYVf29LeqjzK2Hkis9vjIDjfd Q+GcjNl2InO8LBg1NYGzMmu+92bM6laqpWbzVasb0Uyp81Sbqww+LKsGg3NrQieCoH8BK6/BCVzL DocUzMhI291uwoVbNOvi+UJcJGM8IrmPtN5lH9WNk4pYMWd9iJ0KH60b0f/Sag63lib7BtzO4iSX 3ZUl7ArvvYmXilNu4RljnJPpyFI3OVmKjtpBa7WxGqAQZ+1gDOdbeEwy8LrUzR9mEVz9hErYsD81 mY3hF95sFYpB9DkZV68V4yWFvTqQCam6WMY2NMxUHgIs1Zys/I1VMOtFKWAj/TWkaK5DMPxjUoAd fdeS8ZiEynW2M6JtZ1/zUsqnioh+PDpCQzYVBxjcr0MV9BlRCdcUpiLoF9EOtLXNlF+c88JYcdum uWGWxTgvtzpFi0y2cBOqcxnMmyMe6FYpu1Hu/KqYlL8gVdww/p+povcTuDJojrQHQrioFRjpfG0H XKiYQxXKYhruCGgcTO2AaEFQXfR2jeC62HwLcqi/bc5ZGpoag5OfOqAREhT2IxULQvahLJnoO4VY Pd+7LMmCkIkoR1yZWbGH5JCwga6Ba3pvD1AMoW6qSV4GDO5k/PnveQYNI93kuPnm1ZD53mtz4O/u fGwyg1J+HTYNTWH/uYjGWn7nY9eb5cXe6yqiJxZt1pUiK4CZsxW08rR/TRHOudXailXSuLFaCAde LGsMg/OGKIOLH6T/wf5HRcjsbw96Qx3wA6itCH5P0MQgbCCqL9nGA+kCaQeH0DjZQRtMmpQ1bd7d aqsVm/WFtFELF8z5njC2luws/j6nsefNmc/Oy8WLNHZuYc/WdmypqcGzJ1MUhsbFQcY4xvxo5f6u xIf3wdFduOufMiVNMJEHcM0HrWff5AEkv+Volm7+CQAA//8DAFBLAwQUAAYACAAAACEADdGQn7YA AAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE 94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFt uOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3 dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD/ /wMAUEsBAi0AFAAGAAgAAAAhAOneD7//AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAwAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAZAgAA dGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQB0sUijYAYAADIbAAAW AAAAAAAAAAAAAAAAANYCAAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3R kJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAAagkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdl ci54bWwucmVsc1BLBQYAAAAABQAFAF0BAABlCgAAAAAAAA8EOgEAADw/eG1sIHZlcnNpb249IjEu MCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczph PSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIg YmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEi IGFjY2VudDI9ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFj Y2VudDU9ImFjY2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9 ImZvbEhsaW5rIi8+AAAnBH4FAABQSwMEFAAGAAgAAAAhAJHvzfL7AAAAuwEAABMAAABbQ29udGVu dF9UeXBlc10ueG1sfJDJTsMwEIbvSLyD5SuKnXJACCXpgeXGcigPMHImiYU3edyqfXsmaZEqVDiN Zv3++Zv13juxw0w2hlauVC0FBhN7G8ZWfm5eqnspqEDowcWArTwgyXV3fdVsDglJ8HagVk6lpAet yUzogVRMGLgzxOyhcJpHncB8wYj6tq7vtImhYChVmW/IrnnCAbauiOc9l49KMjqS4vE4OLNaCSk5 a6CwUr0L/S9KdSIo3lxmaLKJbliG1BcJc+dvwGnvna3JtkfxAbm8gWcZus+kyXHxFaiwc+fJSv1/ 9oLuOAzWYB/N1rMnKmUkjssL3qkz0M8verG++wYAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAA OAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+O FgSPwzBvZur2NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGs YEwpHKRkPdKMXPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJ pR8Vkidr6IycKGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhALoV8QFN AgAAAA4AACEAAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsl91u2jAUx+8n7R0s 3040JARII0JFN7GbTkKjewDjOMSq40S2y2BPv3OCEUm3Sb1aKwFXtnw+fP6/4GPP7vaVIjthrKx1 RsObISVC8zqXepvRH4/LQUKJdUznTNVaZPQgLL2bf/wwa1K3X7uDEpZACG1TltHSuSYNAstLUTF7 UzdCw1pRm4o5mJptkBv2E0JXKoiGw0lQMamp9zev8a+LQnLxpebPldDuGMQIxRxs35aysadozWui NUZYCNN697Y0x/KkU6KtMMDpps4P7Ww+Y6naqbBZGcLUFlRTlBinMorasQd9b57acVFrt2gNNswK Skqmt1D76llzhwYYyDb8XhR+tOKO7BgEGg3hRyFt8MJiUbiXth07v5qL4jvszf4CnqAyJU/CIFsc t961kvlSKtVOkJX4rMwxs9uHp7xdKxRYE3doRME4fAULIxlUzUtmrGiLgc2yVLCOzbc1WX2tXSk5 JY10vFyySqoDVBd3PAdhlGBGlnL7D+d+FpDkWGCrjgeB/jCMkEnFzENG4/G0rf1K6O0JIRZPaHQm dBvGMX6dV0JvTwixeELxmVA4moaTK6L3ccwhF49o3EGURElyRfQ+ECEXj2hyRhRFCfyJugcd9K9H tllDfz6dgX9cH0JK2p57vk30bw8hxUT/odN/qvRAuWOH7rV3XBDsL60bF7j1t4h+q0ZVvEDTjkDT eNTv1RcrEKriBUrOAqE6/VZ5sQKhKl6g245Ak/G036guViBUBW7GvfdKk8I1XJjTWwYWT0+3+W8A AAD//wMAUEsBAi0AFAAGAAgAAAAhAJHvzfL7AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAAAAAAAAAs AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAuhXxAU0CAAAADgAAIQAAAAAAAAAAAAAAAAAT AgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAAAJ8EAAAA AA8A7gPwBAAAAgDvAxgAAAAQAAAAAAAAAAAAAACnAACAAAEAAAcAMQAPAAwE/wMAAA8AAvD3AwAA UAAI8AgAAAAEAAAABBAAAA8AA/DfAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAQAAAFAAAADwAE8PsAAACiDArwCAAAAAIQAAAACgAAkwAL8EwAAAB/AAAA7wGAAICk YAWFAAIAAAC/AAIABgC/AQAAEAD/AQAAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0ACAAQgBv AHgAIAA5AAAAAAAQ8AgAAAA5D8MHEA8iEA8ADfB/AAAAAACfDwQAAAABAAAAAACoDxcAAABBQ0Ug Qk9GLCBJRVRGLTg5IExvbmRvbgAAoQ8gAAAAGAAAAAAAJSAKAAAAAAAA/wAABwAYAAAAAAAiAP// EgAAAKoPDgAAABgAAAAHAAAAAAAJBAQIAACmDw4AAAD4AAAAAADUAdAC8AMQBQ8ABPA/AQAAogwK 8AgAAAADEAAAAAoAAIMAC/BIAAAAfwAAAO8BgAAAo2AFvwACAAYAvwEAABAA/wEAABgAPwMAAAgA gMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQAwAAAAAAAQ8AgAAADwAyABkBWWCw8ADfDH AAAAAACfDwQAAAABAAAAAACoD1EAAABBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBm b3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRzIChBQ0UpDUJPRiBTdW1tYXJ5DQ0AAKEPLgAAAFIA AAAAACUoCgAAAAAAAP8BADIABwBPAAAAAAAiAP//IAADAAAAAAAiAP//HAAAAKoPDgAAAFIAAAAH AAAAAAAJBAQIAACmDw4AAAD4AAAAAADUAdAC8AMQBQ8ABPBdAQAAogwK8AgAAAAEEAAAAAoAAIMA C/BIAAAAfwAAAO8BgACgomAFvwACAAYAvwEAABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABl AHgAdAAgAEIAbwB4ACAAMQAxAAAAAAAQ8AgAAACQCYAB0BSKDQ8ADfDlAAAAAACfDwQAAAABAAAA AACoD3sAAABXZWQgMDk6MDAtMTE6MzAsIEJhbG1vcmFsIA1CT0YgQ2hhaXJzOiBLZXBlbmcgTGks IEhhbm5lcyBUc2Nob2ZlbmlnIA1SZXNwb25zaWJsZSBBRDogQmFycnkgTGVpYmENTWFpbGluZyBM aXN0OiBhY2VAaWV0Zi5vcmcAAKEPIgAAAHwAAAAAACUoCgAAAAAAAP8BADIABwB8AAAAAAAiAP// EgAAAKoPDgAAAHwAAAAHAAAAAAAJBAQIAACmDw4AAAD4AAAAAADUAdAC8AMQBRAA8AcgAAAA//// AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTjQAAAA8AihOFAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLE2UAAAAAAB0QBAAAAAAAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/Eg AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAP AAIrAAAAAAAAHQQEAAAAAQAAAA8A7gMWBAAAAgDvAxgAAAAQAAAAAAAAAAAAAACoAACAAAAAAAcA MQAPAAwEugMAAA8AAvCyAwAAcAAI8AgAAAADAAAAAxQAAA8AA/CaAwAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8A0BAAASAArwCAAAAAIUAAAgAgAA AwEL8HAAAAAEAAAAAAB/AAEA7wGAAMCgYAWBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACH AAEAAACIAAAAAAC/AAAABgD/ARAAEQABAwIMAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABsAGUA IAAxAAAAAAAQ8AgAAACqACcBZxXQAg8AEfAcAAAAAADDCwgAAAD/////DQASLgAAHwQEAAAAAgAA AA8ADfBJAAAAAACfDwQAAAAAAAAAAACoDxEAAABFeGVjdXRpdmUgU3VtbWFyeQAAqg8cAAAAEQAA AAcAAAAAAAkEBAgBAAAABwAAAAAACQgECA8ABPBNAgAAEgAK8AgAAAADFAAAIAIAABMBC/CSAAAA BAAAAAAAfwABAO8BgADAo2AFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAA AAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDDAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4A dAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAADADngAPFmAPDwAR8BwAAAAA AMMLCAAAAP////8TABIuAAAfBAQAAAADAAAADwAN8GcBAAAAAJ8PBAAAAAEAAAAAAKgP8QAAAH4g MTIwIHBhcnRpY2lwYW50cyBhdCB0aGUgQk9GDUF1ZGllbmNlIGV4cHJlc3NlZCBzdHJvbmcgaW50 ZXJlc3QgdG8gd29yayBvbiB0aGlzIHRvcGljLiANfiAzMCBwZXJzb25zIHdpdGggaW50ZXJlc3Qg dG8gcmV2aWV3IHNwZWNpZmljYXRpb25zLg1+IDE1IHBlcnNvbnMgd2l0aCBpbnRlcmVzdCB0byB3 cml0ZSBzcGVjaWZpY2F0aW9ucy4NSGlnaCBsZXZlbCBzdW1tYXJ5IHBvc3RlZCB0byB0aGUgbWFp bGluZyBsaXN0LiAAAKoPKgAAAMIAAAAHAAAAAAAJBAQIEgAAAAcAAAAAAAkEBAgeAAAABwAAAAAA CQQECA8A8g8YAAAAAADzDxAAAAAAAAAAGwAAAAQAAAAImTEAAADfDwgAAADCAAAA1AAAABAA8Acg AAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAAAB0EBAAAAAEAAAAPAO4DYwQAAAIA 7wMYAAAAEAAAAAAAAAAAAAAAqAAAgAAAAAAHADEADwAMBAcEAAAPAALw/wMAAIAACPAIAAAAAwAA AAMYAAAPAAPw5wMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAA BQAAAA8ABPAVAQAAEgAK8AgAAAACGAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgACAoWAFgQAw ZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCDAAA PwMAAAgAgMMQAAAAvwMAAAIAVABpAHQAbABlACAAMQAAAAAAEPAIAAAAqgAnAWcV0AIPABHwHAAA AAAAwwsIAAAA/////w0AEi4AAB8EBAAAAAIAAAAPAA3wUQAAAAAAnw8EAAAAAAAAAAAAqA8ZAAAA Q29uc3RyYWluZWQgTm9kZSBOZXR3b3JrcwAAqg8cAAAAGQAAAAcAAAAAAAkEBAgBAAAABwAAAAAA CQgECA8ABPCSAgAAEgAK8AgAAAADGAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgABgo2AFgQAw ZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEA AQMDDAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABk AGUAcgAgADIAAAAAABDwCAAAANUDngDiFf4PDwAR8BwAAAAAAMMLCAAAAP////8TABIuAAAfBAQA AAADAAAADwAN8KwBAAAAAJ8PBAAAAAEAAAAAAKgPtAAAAENhcnN0ZW4gZXhwbGFpbmVkIHdoYXQg Y29uc3RyYWluZWQgbm9kZSBuZXR3b3JrcyBhcmUgYW5kIHdoeSB0aGV5IHBvc2UgY2hhbGxlbmdl cyBmb3IgcHJvdG9jb2wgZGVzaWduZXJzLiANU2xpZGVzOiANaHR0cDovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy84OS9zbGlkZXMvc2xpZGVzLTg5LWFjZS0yLnBkZiANDQAAoQ9QAAAAdAAAAAAA AAAAAD8AAAABAAAAAAABAAAAAQABAAAABAABAAAAAAAAAAAAdAAAAAAAAAA/AAAAAAQAAAAEAQAA AAAIAAAACAEAAAAADAAAAAwAAKoPVAAAAGsAAAAHAAAAAAAJCAQICAAAAAcAAAAAAAkEBAgBAAAA BwAAAAAACQgECD0AAAAHAAAAAAAJCAQIAgAAAAcAAAAAAAkIBAgCAAAABwAAAAAACQQECA8A8g8Y AAAAAADzDxAAAAAAAAAAHgAAAAQAAAAImTEAAADfDwgAAAB0AAAAsQAAABAA8AcgAAAA////AAAA AACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAAAB0EBAAAAAEAAAAPAO4Daw8AAAIA7wMYAAAAEAAA AAAAAAAAAAAAqAAAgAAAAAAHADEADwAMBA8PAAAPAALwBw8AAJAACPAIAAAAAwAAAAMcAAAPAAPw 7w4AAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAHAAABQAAAA8ABPAW AQAAEgAK8AgAAAACHAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgABAomAFgQAwZQEAggCYsgAA gwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCDAAAPwMAAAgAgMMQ AAAAvwMAAAIAVABpAHQAbABlACAAMQAAAAAAEPAIAAAAqgAnAWcV0AIPABHwHAAAAAAAwwsIAAAA /////w0AEi4AAB8EBAAAAAIAAAAPAA3wUgAAAAAAnw8EAAAAAAAAAAAAqA8aAAAAVXNlIENhc2Vz IGFuZCBSZXF1aXJlbWVudHMAAKoPHAAAABoAAAAHAAAAAAAJBAQIAQAAAAcAAAAAAAkIBAgPAATw mQ0AABIACvAIAAAAAxwAACACAAATAQvwkgAAAAQAAAAAAH8AAQDvAYAAQL5PBYEAMGUBAIIAmLIA AIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAL8BAQABAP8BEAARAAEDAwwAAD8D AAAIAIDDLAAAAL8DAAACAEMAbwBuAHQAZQBuAHQAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAy AAAAEwAi8Z8KAACpw5kKAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9U eXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/x I6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhC Ln0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ 5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT 2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACP AQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYw WEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSq UqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyX xnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMA UEsDBBQABgAIAAAAIQCoO52/yAQAAKAgAAAQAAAAZHJzL3NoYXBleG1sLnhtbOwZXW/bNvB9wP4D wffUtmzHjhClSDykK+AFRp1ijwUtUZFmitRIynXytP+wf7Cftl+yO1KS7aJZuzQNkkF+kHnkHXm8 b5Knr7eFIBuuTa5kRAev+pRwGasklzcRfX99eTSlxFgmEyaU5BG95Ya+Pvvxh9MyNCUBYmnCMqKZ tWXY65k44wUzr1TJJYylShfMAqhveqXmhkvLLCxUiF7Q7x/3CpZLegZTyc2yXGhsxVebhSZ5EtHJ YDKgRLICVp0paYGYLASLeaZEwjUJaK8m8LQMGJqreG1qrtjXcJVo9hG2esAQkeqNhj0NcIGeY6nh TgJzuGiZAYvbiI6Ck9HJ8SQ4Gde4HgGIdjsybmcs3Ka6+FbWzk5ZqNKUwNLBuD8NxpTcAqOw/qjf RxZYyLeWxDA+PR4FwzGoMwaM8XAyPJ5OHZOeE7czz1oZ2u2FSm6RegX/IH+v14dLEAzKgviVvqPk o2YgTPN7xTSnRLyVJqIng9EIWLMOGI0nAQB6f2S1PyKrYqYEKoQwGcOsEbVNc2YBwl2qomR2Lpdl jIi4l1Ibe739lemSYBOIQDZXapmxkjsEtpkbizrex3WgFwNOIoxd2lvBv1UkTjeNwzxYsG5boJ+C 6XlEh2B+oHaE3jkhiA1ICTpymYC3RPSowWDiBrxbUJLw9Jqtlne1ClDs1tNwNpcXeu3oU3C3c0ey YgaVBl4rd8MZkzfgNItKxrBI38lSoOSRPVPGi9iSDUOF9fFXW90+xgVPP8WFgNCiwhw7jPPUforb TAl49eiqmgnwTFhe36yg6dc/uZgNBrN6/RZlVS3vrrdOIavqErbaArOMaRLDJ6J///GX9yfLVt5K WAjCe7fQtcFgIGCh/4BG1lWRF+q33OsBBBRRLo/eXICdCjt38F12NLuCaArCH+Jeycory32riEoI sBhsdb6GkCfV0rUoWXMNygP8GB2pxkIzhy6JEVbkd/xnB6K6RI5x2o0ttFKpaye5thAHoNcUdiY4 czPiDoTEr1SXuRB+a77HKJEn2OmkinGdt3K1Wx8bQdz7WDxNeWwbaVVzWQu2wmnqtjMlYm9LnkIo j+i5zhnYJQrdcGdNTjGc7eH8siSLN8pmeUxJmds4u2RFLmA7w9Ee5dEgcAGOhbG5h/hwFXB77bVo z8gH/Plv29yBu5bDcSDBuAGmidP4GIKS6lzc2cu+A7fh4H/p4u+XnYuz8MW4ODj5kzjuBHIzVl+H uRkqmDY3B9PxBDG63AxlZ5O+vzI3//kIufk+xw2mXW5+hrl5l50h+2ICrnNy/ec7PHDo4F8s0p6h IXANJSgEi65Ya0rCw2Lt5Wu40+znNeuK7w+H+gXdl9+htu5S9Pc8Pj9Gir7v+Nyl6Gd5fG4PzrUT +z8ouKGxS9N7gOvcG2mbT1Ojjwcjd0N6WKNDSd7W6O5qsqvR/Z3of6zRH+P+7L7SrLs/e5YB4EnS tns7+NeTdee1D7/1foy0fZ/Xdmn7GXgtCzN4IVjPRB6v60ctOGt++f0Wnh3zmP+k4qqAtyX/fqs5 XucrabK8NPCUFOK7rX6bNK8D7fU6VgJkVwdgnm9zvR+qweavRnYkB/fsL/E03531PnvWO9CrP+PB w3nzFg1NU579AwAA//8DAFBLAwQUAAYACAAAACEAXtYrE9oAAAD8AAAADwAAAGRycy9kb3ducmV2 LnhtbESPTUvDQBRF94L/YXiCm2InUTQSOy0iSIsg/Yr7Z+Y1Cc28iTPTJP33Dl3o8nIv53Jmi9G0 oifnG8sK0mkCgri0uuFKQbF/v3sG4QOyxtYyKTiTh8X8+mqGubYDb6nfhUpECPscFdQhdLmUvqzJ oJ/ajjh2B+sMhhhdJbXDIcJNK++T5EkabDg+1NjRW03lcXcyCibFcn/Kjpvlp/t5+PpYd8NjP9ko dXszvr6ACDSG/zH3qyKs/8oLaqUVZGmWgjgsz9+u0Vv0gZyCqBdloyjI+S8AAAD//wMAUEsDBBQA BgAIAAAAIQDukFCp5gAAAGgBAAAbAAAAZHJzL19yZWxzL3NoYXBleG1sLnhtbC5yZWxzhNDNasMw DAfw+2DvYHRPlK4w0pGkl27Qwy6jewBjy4mpYxvLa9q3n8c+WGGwkxBCP/1Rtz3PTpwosQ2+h1Xd gCCvgrZ+7OH18FS1IDhLr6ULnnq4EMN2uL3pXsjJXJZ4spFFUTz3MOUcHxBZTTRLrkMkXyYmpFnm 0qYRo1RHORLeNc09pt8GDFem2Ose0l6vQBwusVz+3w7GWEW7oN5m8vmPEzgVKTnrjwWVaaT8wy7L UlvK5jNkCoro4weM7QbZWU38Vap2U0lF1bqO2nwzz0GXhI/nTMlLBzh0ePWf4R0AAP//AwBQSwEC LQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd LnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8u cmVsc1BLAQItABQABgAIAAAAIQCoO52/yAQAAKAgAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hh cGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAF7WKxPaAAAA/AAAAA8AAAAAAAAAAAAAAAAAHwcAAGRy cy9kb3ducmV2LnhtbFBLAQItABQABgAIAAAAIQDukFCp5gAAAGgBAAAbAAAAAAAAAAAAAAAAACYI AABkcnMvX3JlbHMvc2hhcGV4bWwueG1sLnJlbHNQSwUGAAAAAAUABQA+AQAARQkAAAAAAAAQ8AgA AAAwA54A4hVpEA8AEfAcAAAAAADDCwgAAAD/////EwASLgAAHwQEAAAAAwAAAA8ADfAMAgAAAACf DwQAAAABAAAAAACoDxgBAABMdWR3aWcgaW50cm9kdWNlZCB0aGUgY29udGFpbmVyIG1vbml0b3Jp bmcgdXNlIGNhc2UuDUZlZWRiYWNrOiANQ29uc2lkZXIgbG9va2luZyBhdCB0aGUgZW50aXJlIGxp ZmVjeWNsZSBvZiB0aGVzZSBJb1QgZGV2aWNlcy4NQXNzdW1wdGlvbnMgcmVnYXJkaW5nIHByb3hp ZXMsIGFuZCBjb25uZWN0aXZpdHkgcmVxdWlyZSBtb3JlIGRpc2N1c3Npb24vYW5hbHlzaXMuIA1T bGlkZXM6DWh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODkvc2xpZGVzL3NsaWRlcy04 OS1hY2UtMy5wZGYgAAChD0wAAABAAAAAAAAAAAAAkgAAAAEAAAAAAAgAAAAAAAAAAAA/AAAAAQAA AAAAQAAAAAAAAACSAAAAAAAAAAgAAAAABAAAAAQ/AAAAAAgAAAAIAACqD1QAAAA1AAAABwAAAAAA CQgECEoAAAAHAAAAAAAJBAQIUwAAAAcAAAAAAAkIBAgIAAAABwAAAAAACQQECD0AAAAHAAAAAAAJ BAQIAgAAAAcAAAAAAAkEBAgPAPIPGAAAAAAA8w8QAAAAAAAAAB8AAAAEAAAACJkxAAAA3w8IAAAA 2gAAABcBAAAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAAAAAdBAQAAAAB AAAADwDuA8oEAAACAO8DGAAAABAAAAAAAAAAAAAAAKgAAIAAAAAABwAxAA8ADARuBAAADwAC8GYE AACgAAjwCAAAAAMAAAADIAAADwAD8E4EAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAACAAAAUAAAAPAATwFwEAABIACvAIAAAAAiAAACACAAADAQvwcAAAAAQAAAAAAH8A AQDvAYAAQKVgBYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAG AP8BEAARAAEDAgwAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAgADEAAAAAABDwCAAAAKoA JwFnFdACDwAR8BwAAAAAAMMLCAAAAP////8NABIuAAAfBAQAAAACAAAADwAN8FMAAAAAAJ8PBAAA AAAAAAAAAKgPGwAAAEFyY2hpdGVjdHVyZSBEZXNpZ24gQ2hvaWNlcwAAqg8cAAAAGwAAAAcAAAAA AAkEBAgBAAAABwAAAAAACQgECA8ABPD3AgAAEgAK8AgAAAADIAAAIAIAABMBC/CSAAAABAAAAAAA fwABAO8BgADApmAFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAA AAYAvwEBAAEA/wEQABEAAQMDDAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAA bABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAADADngDiFWkQDwAR8BwAAAAAAMMLCAAA AP////8TABIuAAAfBAQAAAADAAAADwAN8BECAAAAAJ8PBAAAAAEAAAAAAKgPRwEAAEdvZXJhbiBw cmVzZW50ZWQgdGhlIGFyY2hpdGVjdHVyZSBkZXNpZ24gY2hvaWNlcy4gDUZlZWRiYWNrOg1JcyBp dCBhc3N1bWVkIHRoYXQgZGV2aWNlcyBoYXZlIGEgY2xvY2s/DURvZXMgdGhlIHdvcmsgZm9jdXMg b25seSBvbiBDb0FQIGFuZCBEVExTIG9yIG90aGVyIHRyYW5zcG9ydCBiaW5kaW5ncyBpbiBmb2N1 cz8NTW9yZSBkaXNjdXNzaW9uIG5lZWRlZCByZWdhcmRpbmcgc3ltbWV0cmljIHZzLiBhc3ltbWV0 cmljIGNyeXB0b2dyYXBoeS4gDVNsaWRlczoNaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84OS9zbGlkZXMvc2xpZGVzLTg5LWFjZS00LnBwdHgNDQAAoQ9MAAAAPQAAAAAAAAAAAMIAAAAB AAAAAAAIAAAAAAAAAAAAQQAAAAEAAAAAAD0AAAAAAAAAwgAAAAAAAAAIAAAAAAQAAAAEQQAAAAAI AAAACAAAqg8qAAAABwEAAAcAAAAAAAkEBAg+AAAABwAAAAAACQQECAMAAAAHAAAAAAAJBAQIDwDy DxgAAAAAAPMPEAAAAAAAAAAiAAAABAAAAAiZMQAAAN8PCAAAAAcBAABFAQAAEADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAAAAHQQEAAAAAQAAAA8A7gOQBgAAAgDvAxgAAAAQ AAAAAAAAAAAAAACoAACAAAAAAAcAMQAPAAwENAYAAA8AAvAsBgAAsAAI8AgAAAADAAAAAyQAAA8A A/AUBgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAAAFAAAADwAE 8AgBAAASAArwCAAAAAIkAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGAAICnYAWBADBlAQCCAJiy AACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ARAAEQABAwIMAAA/AwAACACA wxAAAAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACqACcBZxXQAg8AEfAcAAAAAADDCwgA AAD/////DQASLgAAHwQEAAAAAgAAAA8ADfBEAAAAAACfDwQAAAAAAAAAAACoDwwAAABHYXAgQW5h bHlzaXMAAKoPHAAAAAwAAAAHAAAAAAAJBAQIAQAAAAcAAAAAAAkIBAgPAATwzAQAABIACvAIAAAA AyQAACACAAATAQvwkgAAAAQAAAAAAH8AAQDvAYAAoKhgBYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIA AIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAL8BAQABAP8BEAARAAEDAwwAAD8DAAAIAIDDLAAAAL8D AAACAEMAbwBuAHQAZQBuAHQAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ8AgAAAAw A54A4hVpEA8AEfAcAAAAAADDCwgAAAD/////EwASLgAAHwQEAAAAAwAAAA8ADfDmAwAAAACfDwQA AAABAAAAAACgDxgDAABIAGEAbgBuAGUAcwAgAHAAcgBlAHMAZQBuAHQAZQBkACAAZgBvAHUAcgAg AEkARQBUAEYAIABzAGUAYwB1AHIAaQB0AHkAIABwAHIAbwB0AG8AYwBvAGwAcwAgACgASwBlAHIA YgBlAHIAbwBzACwAIABBAEIARgBBAEIALAAgAE8AYQB1AHQAaAAsACAAYQBuAGQAIABQAEsASQAp ACAAYQBuAGQAIABhAHMAawBlAGQAIAB0AGgAZQAgAHEAdQBlAHMAdABpAG8AbgAgAHcAaABlAHQA aABlAHIAIAB0AGgAZQB5ACAAYwBvAHUAbABkACAAYgBlACAAcgBlAC0AdQBzAGUAZAA/ACAADQBW AGEAcgBpAG8AdQBzACAAZwBhAHAAcwAgAGgAYQB2AGUAIABiAGUAZQBuACAAaQBkAGUAbgB0AGkA ZgBpAGUAZAAgAGIAdQB0ACAAdABoAGUAIABmAGkAbgBhAGwAIAB2AGUAcgBkAGkAYwB0ACAAZABl AHAAZQBuAGQAcwAgAG8AbgAgAHQAaABlACAAYQBnAHIAZQBlAGQAIAByAGUAcQB1AGkAcgBlAG0A ZQBuAHQAcwAgAGEAbgBkACAAYQBzAHMAdQBtAHAAdABpAG8AbgBzAC4AIAANAEMAaABhAGkAcgBz ACAAZQBuAGMAbwB1AHIAYQBnAGUAZAAgAHQAbwAgABwgcABsAGEAeQAgAGEAcgBvAHUAbgBkAB0g IAB3AGkAdABoACAAcwB0AHIAYQB3AG0AYQBuACAAcAByAG8AcABvAHMAYQBsAHMAIAB0AG8AIABn AGEAaQBuACAAZQB4AHAAZQByAGkAZQBuAGMAZQAuACAADQBTAGwAaQBkAGUAcwA6ACAADQBoAHQA dABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AcAByAG8AYwBlAGUAZABpAG4AZwBz AC8AOAA5AC8AcwBsAGkAZABlAHMALwBzAGwAaQBkAGUAcwAtADgAOQAtAGEAYwBlAC0ANQAuAHAA cAB0AHgAIAAAAKEPJgAAAE0BAAAAAAAAAABAAAAAAQAAAAAATQEAAAAAAABAAAAAAAQAAAAEAACq D1QAAACHAAAABwAAAAAACQgECLwAAAAHAAAAAAAJBAQIAQAAAAcAAAAAAAkIBAgJAAAABwAAAAAA CQQECD4AAAAHAAAAAAAJBAQIAgAAAAcAAAAAAAkEBAgPAPIPGAAAAAAA8w8QAAAAAAAAACUAAAAE AAAACJkxAAAA3w8IAAAATQEAAIsBAAAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAAAAAdBAQAAAABAAAADwDuA5MPAAACAO8DGAAAABAAAAAAAAAAAAAAAKgAAIAAAAAABwAx AA8ADAQ3DwAADwAC8C8PAADAAAjwCAAAAAMAAAADKAAADwAD8BcPAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAACgAAAUAAAAPAATwDgEAABIACvAIAAAAAigAACACAAAD AQvwcAAAAAQAAAAAAH8AAQDvAYAAIKdgBYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcA AQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgwAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAg ADEAAAAAABDwCAAAAKoAJwFnFdACDwAR8BwAAAAAAMMLCAAAAP////8NABIuAAAfBAQAAAACAAAA DwAN8EoAAAAAAJ8PBAAAAAAAAAAAAKgPEgAAAENoYXJ0ZXIgRGlzY3Vzc2lvbgAAqg8cAAAAEgAA AAcAAAAAAAkEBAgBAAAABwAAAAAACQgECA8ABPDJDQAAEgAK8AgAAAADKAAAIAIAABMBC/CSAAAA BAAAAAAAfwABAO8BgACgpWAFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAA AAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDDAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4A dAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAATACLxwAoAAKnDugoAAFBLAwQUAAYACAAA ACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFp ugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO 6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhL BjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5 aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwD AAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+D vYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng 4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB 9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdA v/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAFJ1tL/kBAAASiYAABAA AABkcnMvc2hhcGV4bWwueG1s7Frbcts2EH3vTP8Bg3dHF0u2pDGdsdVxmhnVo4mc6WMGIkGTFQiw AKTIfuo/9A/6af2SHgAkJTm9JE7d1g31QOKySyx29yyAhc5ebgtBNlybXMmI9l50KeEyVkkubyP6 9ubqaESJsUwmTCjJI3rHDX15/vVXZ+XElATM0kzKiGbWlpNOx8QZL5h5oUou0ZcqXTCLqr7tlJob Li2zGKgQnX63e9IpWC7pOT4lN4tyrl0pvt7MNcmTiI564yElkhUYdaqkBTOZCxbzTImEa9KnnYoh 8DIINFPxylRSsY+RKtHsPaZ6IBCR6pXGnHpugI4XqZZOQjg3aJlBxG1EB/3xYHxy2oekgTYQgGk3 I+NnxibbVBefK9r5GZuoNCUYuj/sjvpQ0B0ExfiDbteJwCZ8a0mM/tHJoH88hDljUAzGw+NuoOgE SfzMgmjlxG4vVXLnuJd4Q//Bro/XIBzKQv1K31PyXjMo0/y4ZppTIl5LE9FxbzCAaNZXBsPTPip6 v2e53yPXxVQJZxDCZIyvRtTWxalFzc1SFSWzM7koY0fo5lJqY2+23zNdElcEE3RzrRYZK7knYJuZ sc5u+7S+GtTgPiKMXdg7wT9XJd42NWAerVg/LdinYHoW0WO4H4zqam+8EsQGWkJDLhOgJaJHNQUT t0C3oCTh6Q1bLu4rEzi128DD2Uxe6pXnTwG3C8+yZMYZDaiVu+6MyVuAZr6WMQbpel0Kp3knninj eWzJhjmDwecar9unuOTpQ1oEhIYU39hRXKT2Ia13dVgNdFXvcj0VQCaa9O0SxTD++HLa6009NOHa Nclyvbi/2XqDLNdXmGpTmWZMkxiPiP760y8BT5Ytg5ewCZT3Zq4rh3GBgE3CAxZZrYu8UD/kwQ5Q UES5PHq7gJ8KO/P1++xoeo1oCuV7MJJlMJZ/riMqEWBdsNX5CiFPqoUvUbLiGsZzPu6AVFE5N0eT dBFW5Pf8W1915hK5i9O+b66VSn05ybVFHECrKexUcOa/6GYgpHtKdZULEaYWWowSeeIavVZdXOeN Xu02xEaoe5+KpymPba2t9UxWil27z1Rl70rE3pU8RSiP6IXOGfzSKd1w703eMJzt0Xy3IPNXymZ5 TEmZ2zi7YkUuMJ3jwR7nUa8/CiaLzR8wH44CB9LBivacvMMPD/euy02Lb3AE7whxwQL+6HhD4HDq +ZtxfQpcu8h9iGtEvwbX/dHw1FG0uP50XP/8hLjuj1w8bnH9H8J1g+gG14cYfnQM/xdtzTVWKMSD NpbXK8ZhLH8Qpp+jiVvT/r5p3Rrsf+1C/Nw32O1C/KVtsMMS7PbRB+ht4/NzPkaxSYYj52oq8nhV ZUmwO/nrhCDyWHnMv1HxukCyIiQENXfnQyVNlpcGuYmJSwTq10l93GzOa/40dnBU8y2tW2FR+J+e zj8IG9jzlU9w+q5zZoenbxzrmtN3TdGevj/99N1m1b64Rd9F5uYUHnJpTdVH7X8orVbDtgX2Lhfe psvbdPlj0+Ueuw2SUQjY3kc7kB0QXuO86ty96m7P7qk9R8W2X3Y8+LXBor1ba+/Wnt3d2j7iK3BX 8aLGeNN6mBx4ol3+B9drext8FNut/Udt7a9xZe3va//8lpzLZM40w+V5e0+O6+Lnd0++M2B96Y2/ ONX/GkLRlOe/AQAA//8DAFBLAwQUAAYACAAAACEAmIZHYdwAAAD8AAAADwAAAGRycy9kb3ducmV2 LnhtbESPXUvDMBiF7wX/Q3gFb4ZLp0xnXTbGQCrC3Kd4+65514Y1SU2ytvPXG7xwl4dzeA7PeNrp ijXkvLJGwKCfACOTW6lMIWC3fb0bAfMBjcTKGhJwJg/TyfXVGFNpW7OmZhMKFiHGpyigDKFOOfd5 SRp939ZkYnewTmOI0RVcOmwjXFf8PkkeuUZl4kOJNc1Lyo+bkxbQ22Xb09NxlS3c98Pn+7Juh01v JcTtTTd7ARaoC5ex+vrZf2T/5R/qTQoYDZ6HwA7Zee+UXKMP5AREvSgbRYFPfgEAAP//AwBQSwME FAAGAAgAAAAhADQGIwHpAAAAaQEAABsAAABkcnMvX3JlbHMvc2hhcGV4bWwueG1sLnJlbHOE0M9K A0EMBvC74DsMuXczVVCR7vZShR68SH2AOJvdGTp/lsy02769o6BYEDyGkN/3kdX6FLw6smSXYgvL RoPiaFLv4tjC2+558QAqF4o9+RS5hTNnWHfXV6tX9lTqUbZuyqoqMbdgS5keEbOxHCg3aeJYN0OS QKWOMuJEZk8j443Wdyi/DeguTLXtW5BtvwS1O081+X87DYMzvEnmEDiWPyLQVkm8i/uKkoxcfth5 nhvHZfgqGcj5BYmx7sg48zuSYTQHkU825FHrW33f2BL8t/OS+lrx6VRYInnAboUXD+o+AAAA//8D AFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFJ1tL/kBAAASiYAABAAAAAAAAAAAAAAAAAAKQIAAGRy cy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAmIZHYdwAAAD8AAAADwAAAAAAAAAAAAAAAAA7 BwAAZHJzL2Rvd25yZXYueG1sUEsBAi0AFAAGAAgAAAAhADQGIwHpAAAAaQEAABsAAAAAAAAAAAAA AAAARAgAAGRycy9fcmVscy9zaGFwZXhtbC54bWwucmVsc1BLBQYAAAAABQAFAD4BAABmCQAAAAAA ABDwCAAAADADngDiFWAPDwAR8BwAAAAAAMMLCAAAAP////8TABIuAAAfBAQAAAADAAAADwAN8BsC AAAAAJ8PBAAAAAEAAAAAAKgPWwEAAFNjb3BlIG9mIHRoZSB3b3JrIG5lZWRzIHRvIGJlIGNsYXJp ZmllZC4gDUlzIHRoZSBmb2N1cyBvbmx5IG9uIENvQVAgYW5kIERUTFM/IA1DaGFpcnMgc3RhcnRl ZCBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiBhbHJlYWR5Lg1NaWxlc3RvbmVzIGFuZCB0YXNrIGxp c3RzIGdvdCBzaW1wbGlmaWVkLiANU3VnZ2VzdGlvbiB3YXMgbWFkZSB0byBkb2N1bWVudCB1c2Ug Y2FzZXMsIHJlcXVpcmVtZW50cywgYW5kIGRlc2lnbiBjb25zaWRlcmF0aW9ucyBvbiBhIFdpa2kg cGFnZSByYXRoZXIgdGhhbiBwcm9kdWNpbmcgUkZDcy4gDVNvbHV0aW9uIHNwZWNpZmljIGNoYXJ0 ZXIgaXRlbXMgd2lsbCBiZSByZW1vdmVkLiANAAChD0IAAAAqAAAAAAAAAAAAVQAAAAEAAAAAANwA AAAAAAAAAAABAAAAAAABAAAABAAqAAAAAAAAAFUAAAAAAAAA3QAAAAAAAAAAAKoPKgAAAF4AAAAH AAAAAAAJBAQIFwAAAAcAAAAAAAkEBAjnAAAABwAAAAAACQQECA8A8g8YAAAAAADzDxAAAAAAAAAA JgAAAAQAAAAImTEAAADfDwgAAABeAAAAdQAAABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAz M5kAAJmZAJnMAAAAAB0EBAAAAAEAAAAPAO4D0AUAAAIA7wMYAAAAEAAAAAAAAAAAAAAAqAAAgAAA AAAHADEADwAMBHQFAAAPAALwbAUAANAACPAIAAAAAwAAAAMsAAAPAAPwVAUAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAALAAABQAAAA8ABPAMAQAAEgAK8AgAAAACLAAA IAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgAAgqmAFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAA AAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCDAAAPwMAAAgAgMMQAAAAvwMAAAIAVABpAHQA bABlACAAMQAAAAAAEPAIAAAAqgAnAWcV0AIPABHwHAAAAAAAwwsIAAAA/////w0AEi4AAB8EBAAA AAIAAAAPAA3wSAAAAAAAnw8EAAAAAAAAAAAAqA8QAAAAU2NvcGUgRGlzY3Vzc2lvbgAAqg8cAAAA EAAAAAcAAAAAAAkEBAgBAAAABwAAAAAACQgECA8ABPAIBAAAEgAK8AgAAAADLAAAIAIAABMBC/CS AAAABAAAAAAAfwABAO8BgABAqGAFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAA iAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDDAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABl AG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPICngAPFiIPDwAR8BwA AAAAAMMLCAAAAP////8TABIuAAAfBAQAAAADAAAADwAN8CIDAAAAAJ8PBAAAAAEAAAAAAKAPiAIA AEQAaQBmAGYAaQBjAHUAbAB0ACAAdABvACAAZABlAGMAaQBkAGUAIAB3AGgAZQB0AGgAZQByACAA bwByACAAbgBvAHQAIAB0AG8AIAByAGUAcwB0AHIAaQBjAHQAIABzAGMAbwBwAGUAIAB0AG8AIABD AG8AQQBQACAAJgAgAEQAVABMAFMALgANAEYAbwByADoAIAB3AGUAIABjAGEAbgAZIHQAIABkAGUA ZgBpAG4AZQAgAGcAZQBuAGUAcgBhAGwAIABwAHIAbwB0AG8AYwBvAGwAIAB3AG8AcgBrAGkAbgBn ACAAZgBvAHIAIABlAHYAZQByAHkAdABoAGkAbgBnAC4ADQBBAGcAYQBpAG4AcwB0ADoAIAB3AGUA IABzAGgAbwB1AGwAZAAgAGEAbABsAG8AdwAgAG8AdABoAGUAcgAgAHQAcgBhAG4AcwBwAG8AcgB0 AHMALgANAEMAaABhAGkAcgAZIHMAIABwAHIAbwBwAG8AcwBhAGwAOgAgAGkAbgBpAHQAaQBhAGwA IABmAG8AYwB1AHMAIABzAGgAbwB1AGwAZAAgAGIAZQAgAHUAcwBlACAAbwBmACAAQwBvAEEAUAAg AGkAbgAgAEQAVABMAFMALAAgAGIAdQB0ACAAbwB0AGgAZQByACAAYgBpAG4AZABpAG4AZwBzACAA ZgBvAHIAIABDAG8AQQBQACAAYQBuAGQAIABvAHQAaABlAHIAIAB0AHIAYQBuAHMAcABvAHIAdAAg AHcAbwB1AGwAZAAgAGIAZQAgAHAAbwBzAHMAaQBiAGwAZQAgAGwAYQB0AGUAcgAuACAADQBOAG8A IABjAG8AbgBzAGUAbgBzAHUAcwAuAAAAoQ9MAAAARQAAAAAAAAAAAGkAAAABAAAAAACJAAAAAAAA AAAADgAAAAEAAAAAAEUAAAAAAAAAaQAAAAAAAACJAAAAAAQAAAAEDgAAAAAIAAAACAAAqg8qAAAA wAAAAAcAAAAAAAkEBAiEAAAABwAAAAAACQgECAEAAAAHAAAAAAAJBAQIEADwByAAAAD///8AAAAA AICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAAAAHQQEAAAAAQAAAA8A7gMeKgAAAgDvAxgAAAAQAAAA AAAAAAAAAACoAACAAAAAAAcAMQAPAAwEwikAAA8AAvC6KQAA4AAI8AgAAAASAAAAEjAAAA8AA/A6 KQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAwAAAFAAAADwAE8A0B AAASAArwCAAAAAIwAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGAAICqYAWBADBlAQCCAJiyAACD ADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ARAAEQABAwIMAAA/AwAACACAwxAA AAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACqACcBZxXQAg8AEfAcAAAAAADDCwgAAAD/ ////DQASLgAAHwQEAAAAAgAAAA8ADfBJAAAAAACfDwQAAAAAAAAAAACoDxEAAABPcGVuIElzc3Vl OiBTY29wZQAAqg8cAAAAEQAAAAcAAAAAAAkEBAgBAAAABwAAAAAACQgECA8ABPBNAQAAEgAK8AgA AAADMAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgADAqWAFgQAwZQEAggCYsgAAgwAwZQEAhACY sgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDDAAAPwMAAAgAgMMsAAAA vwMAAAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAA ABUNngAPFuEPDwAR8BwAAAAAAMMLCAAAAP////8TABIuAAAfBAQAAAADAAAADwAN8GcAAAAAAJ8P BAAAAAEAAAAAAKgPPQAAAFdoYXQgcHJvdG9jb2xzIHNob3VsZCBiZSB1c2VkIGluIHdoaWNoIG9m IHRoZXNlIGludGVyZmFjZXM/oA0AAKoPDgAAAD4AAAAHAAAAAAAJBAQIDwAD8D0LAAAPAATwdgAA AAEACfAQAAAAsGAzADymHQDDwU0A4xcrAAIACvAIAAAABDAAAAECAABDAAvwKAAAAAQAAAAAAH8A AADhAYDDEAAAAL8DAAACAEcAcgBvAHUAcAAgADEAAAATACLxBgAAAH8AAAAAAgAAEPAIAAAAewNc DJ0QpgUPAATwqgkAABIACvAIAAAAETAAAAIKAADzAAvwcgAAAH8AAAAEAIAAYBxfBYcAAQAAAL8A AAAGAL8BAAAQAMABAQAACP8BCAAIAAECAAAAAAQCmVkAAAUCAAAAAAYC2FkAABECAIAAAD8CAgAD AIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANgAAADMAIvGSCAAA/wEAAEAAHAJAnAAA qcOACAAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR zUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4p uC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzG XgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZude w4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/ uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVs cy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2 tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0p oDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfX eKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAA ACEABPVCRhoEAAAzEwAAEAAAAGRycy9zaGFwZXhtbC54bWzsWM1u2zgQvi+w70DwunAt+VcWqhRJ AHcP3sCI0wegacrWhiIFkvbaefqdISVbbdP1Ik4PbZNDTEojznzfkPPD9x/2pSQ7YWyhVUbjdxEl QnG9KtQ6o58epp2EEuuYWjGplcjoQVj64er3395Xqa0IfKxsWmV041yVdruWb0TJ7DtdCQXvcm1K 5mBq1t3KCCuUYw4UlbLbi6JRt2SFolewlNotqrnBEb/bzQ0pVhkdUaJYCSrvBQcD1lKQEe3WMiju xwrEYdBtr2H9Wizd56asTWT/x8SVYf8A7i+sY6nOc7LPaL8/GkcJ8HEAoiaDfhxFaA9Lxd4RDgLx uJeMkzElHCSSJI5GfRToBktQsjLWfRT6YqsILpRRA8wAfyxlu5l1QVWjAh8rPS2kvJQCj1GqS5dB g6yWxQpt8hPcLOJWGrJjMqNuH9dstaSAO6m8e4NTYde5gxT4uVT3Avzid+CL3Qs7DR3nSfSb92QP 4xz2a2OT14Zqc7D+1RT3zyuu9aFqkefg8FdT3juv/KjRI9fq9ZSXhdLmOQPkkfI86AveD16vUre/ 0asDmrOEXwgVl24ApvhGm4xyZ8JpltYtUNulK6ONcidjCEZEsJm6MY8ZhfC6gVgGUWa+VRyOcOQ5 WIn8HuPfC04IKIGYqog7VCJnHOLltSmYhCC0YcYKryJEKdaS+WtB5h+12xSckqpwfDNlZSEhbPUH rS87cS+pz2RjIR7IAKrG10N8JTOzjI4HvckQEBZqBScno51eMhzjg58NPmKu4fdP8ON40I8gJ7Tw 95IRPvjZ8CPoGv+ghR+wQlr/BfAj6Br/8IS/Fw3Hg18CP4Ku8Y9a+IfxwG/30/l/Zv9jVL+Wayg2 l8yK58OhrfiNyFEDjObchQLBV1sQfz57e527/5Cr3zbB60cJr0hqze+4xe9kHCdn99cbv8fE9830 haTW/CYnfvuQvs7H7zd+z/OLpNb8Tlr8JsnofH544/c8v0iq7yubWhXJbrrxF/dCfpFjMQd5HKq6 e1+yQsXnf5vADu+YD+FYNBOIrg9suXjK6CQe+ARoXJA/1j0xJV/61Vet36qKQ0Mm1aLiaFU7C0DX jYc0NLttiVfNGMst9KUPe184L7eLp+NwCunrOLmDKxEv4tgyNOAsDbkmmFcfA6FWc2YYVPjkcVsW pf67CLRCJ5BRoTqfFkiom/n506ZzeweXLsBnCPfLwL3/v82oAqV4J2OKRyj2lV74ESWPwuANjj9h nMGdTC1Ycf8ltFslk8WT+NNPMfnKAm90wJlKz43WuR/b0t1KwWCp0Jpg+93cJDSke5981sqb9fLY yE/939e9fNPANkxtZ6pmcotXAvX4+3czLOW21Qr9UaoOt7W5J1f581X55rPpOeGSyVZX/wIAAP// AwBQSwMEFAAGAAgAAAAhAN8RtNzXAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj1FLwzAUhd8F /0O4gm8uVaFKt2yIrCgKY52yvd41d2lok3RJtnX/fmEP+ng4h+/wTWaD6diRfNDOCngcZcDI1k5q qwT8/pQPr8BCRCuxc5YEnCnAbHp7M8FCupOt6LiKiiWIDQUKaGLsC85D3ZDBMHI92dTtnDcYU/SK S4+nBDcdf8qynBvUNj002NN7Q3W7OhgB7eLF532l1aEt98t5+fW8+FYbIe7vhrcxsEhD/B/Ps3W5 b//KK+pTCsiB7T7OW69lhSGSF5DckmmyBD69AAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAA AOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh ADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AAT1QkYaBAAAMxMAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYA CAAAACEA3xG03NcAAAD5AAAADwAAAAAAAAAAAAAAAABxBgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA AAAEAAQA9QAAAHUHAAAAAAAAD/AQAAAAsGAzADymHQDDwU0A4xcrAA8ADfBmAAAAAACfDwQAAAAB AAAAAAChDyYAAAABAAAAAAAlKAoAAAAAAAD/AQAAAAcAAQAAAAAAJgD//xIA/////gAAqg8OAAAA AQAAAAcAAAAAAAkEBAgAAKYPDgAAAPgAAAAAANQB0ALwAxAFDwAE8AUBAAASAArwCAAAABIwAAAC CgAAkwAL8E4AAAB/AAAA7wGAAAA/fAWFAAIAAAC/AAIABgC/AQAAEAD/AQAAGAA/AwAACACAwxgA AAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADcAAAAAAA/wEAAAAK4wNACvqh4AW4hMAGqHKAAP AA3wfwAAAAAAnw8EAAAAAQAAAAAAqA8VAAAAQXV0aG9yaXphdGlvbiALU2VydmVyAAChDyIAAAAW AAAAAAAlKAoAAAAAAAD/AQAAAAcAFgAAAAAAIgD//xIAAACqDw4AAAAWAAAABwAAAAAACQQECAAA pg8OAAAA+AAAAAAA1AHQAvADEAUPAAPwKgsAAA8ABPB2AAAAAQAJ8BAAAAAYbxIASNNDAE1KJwDv RFEAAgAK8AgAAAAFMAAAAQIAAEMAC/AoAAAABAAAAAAAfwAAAOEBgMMQAAAAvwMAAAIARwByAG8A dQBwACAAMgAAABMAIvEGAAAAfwAAAAACAAAQ8AgAAACjCZEC7gXOCw8ABPD0AAAAEgAK8AgAAAAP MAAAAgoAAJMAC/BOAAAAfwAAAO8BgACgq2AFhQACAAAAvwACAAYAvwEAABAA/wEAABgAPwMAAAgA gMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA0AAAAAAAP8BAAAACjYxUApj1HAMZ7IABS 3EwADwAN8G4AAAAAAJ8PBAAAAAEAAAAAAKgPBgAAAENsaWVudAAAoQ8gAAAABwAAAAAAJSAKAAAA AAAA/wAABwAHAAAAAAAiAP//EgAAAKoPDgAAAAcAAAAHAAAAAAAJBAQIAACmDw4AAAD4AAAAAADU AdAC8AMQBQ8ABPCoCQAAEgAK8AgAAAAQMAAAAgoAAPMAC/ByAAAAfwAAAAQAgADgEV8FhwABAAAA vwAAAAYAvwEAABAAwAEBAAAI/wEIAAgAAQIAAAAABAKZWQAABQIAAAAABgLYWQAAEQIAgAAAPwIC AAMAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA4AAAAMwAi8ZAIAAD/AQAAQAAcAkCc AACpw34IAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1s lJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W2 3im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOm PMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm 517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPh xn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9y ZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x 7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qL HSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJq x9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAI AAAAIQDdgsXoGQQAADQTAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxY3XLaOhC+78x5B41uz1BsMOAw dTpJZui5oBkmpA8ghAw+kSWPJDiQpz+7kg1um5ZOSC/aJhdBstfa/b6V9kfv3u9KSbbC2EKrjMZv I0qE4npZqFVGP91POikl1jG1ZFIrkdG9sPT95V9v3lVjWxH4WNlxldG1c9W427V8LUpm3+pKKHiX a1MyB1Oz6lZGWKEcc6ColN1eFA27JSsUvYSl1HZezQyO+O12ZkixBFvAFMVK0HknOFiwkoKktFsL obwfK5CHQbe9iPWLsfEuN2VtI/sRG5eG/QfAvzCPjXWekx1Y1IvSKAVC9hlNkmQQRRHaw8Zi5whH gf5wmPZHlHCQSNM4GvZRoBssQcnKWPdB6LOtIrhQRg0wAwSyMdtOrQuqGhX4WOlJIeW5FHiMUp27 DBpktSyWaJOf4G4RN9KQLZMZdbu4ZqslBdxJ5d0bnArbzu2lwM+luhPgF78Fn+1e2GroOE+i371H exjnsGEbm7w2VJuD9S+muH9aca0PVYs8B4e/mPLeaeUHjR65Vi+nvCyUNk8ZIA+U50Ff8H7wejV2 u2u93KM5C/iFWHHuBmCKr7XJKHcmnGZp3Ry1nbsy2ii3MoZgRASbqmvzkFEIamuIZRBlZhvF4QhH noOlyO8wAD7jhIASCKqKuH0lcsYhXl6ZgkkIQmtmrPAqQpRiLZmPczL7oN264JRUhePrCSsLCWGr n7S+7MQ9H3LhFDYW4oEMoGp8PcRXMjPN6CjpXQwAYaGWcHIy2umlgxE++N3gI+Yafv8IP46TPuaE Fv5eOsQHvxt+BF3jT1r4ASvk9T8AP4Ku8Q+O+HvRYJT8EfgRdI1/2MI/iBO/3Y/n/4n9j1H9Sq6g 2lwwK54Oh7bi1yJHDTCacRcKBF9tQfz57O1V7r4jV79tgtevEl6R1JrfUYvfi1Gcntxfr/weEt83 0xeSWvObHvntQ/o6Hb9f+T3NL5Ja83vR4jdNh6fzwyu/p/lFUn1f2dSqSHbTjj+7F/KLHIo5yONQ 1d35khUqPv/bBHZ4x3wIx6KZQHS9Z4v5Y0Yv4sQnQOOC/KHuiSn50q++av1WVRwaMqnmFUer2lkg hiMKQTA0u22JF80Yiw30pfc7XzgvNvPHw3AC6eswuYU7ES/i2CI04E2hHMyrj4FQyxkzDCp88rAp i1L/WwRaoRPIqFCdT3Mk1E39/HHdubmFWxfgM4T7ReDe/99kVIFSvJQxxQMU+0rP/YiSB2HwCsef MM7gUqYWrLj/EtqtksniUfzjp5h8ZYFXOuBMpWdG69yPbelupGCwVGhNsP1ubhIa0r1PPmvlzWpx aOQn/u/rXr5pYBumNlNVM7nBK4F6/PO7GTbmttUK/V2qDre1uUdX+fNV+eaz6TnhkslWl/8DAAD/ /wMAUEsDBBQABgAIAAAAIQCqvHap1gAAAPoAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/BSgMxEEDv gv8QRvBmsypUWZsWkS6KQulW0eu4mWbDbpJtkrbbv3fwoMeZN7zhzRaj68WBYrLBK7ieFCDIN0Fb bxR8vFdX9yBSRq+xD54UnCjBYn5+NsNSh6Ov6bDJRrDEpxIVtDkPpZSpaclhmoSBPLNtiA4zj9FI HfHIctfLm6KYSofW84cWB3pqqek2e6egW93F6VBbs++q3XpZvd6u3syXUpcX4+MDiExj/j9eFp/V rvuDv6oXzS2csn0+fUera0yZogLecCojkPMfAAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAA AOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh ADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AN2CxegZBAAANBMAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYA CAAAACEAqrx2qdYAAAD6AAAADwAAAAAAAAAAAAAAAABwBgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA AAAEAAQA9QAAAHMHAAAAAAAAD/AQAAAAGG8SAEjTQwBNSicA70RRAA8ADfBmAAAAAACfDwQAAAAB AAAAAAChDyYAAAABAAAAAAAlKAoAAAAAAAD/AQAAAAcAAQAAAAAAJgD//xIA/////gAAqg8OAAAA AQAAAAcAAAAAAAkEBAgAAKYPDgAAAPgAAAAAANQB0ALwAxAFDwAE8KIAAAACAgrwCAAAAAYwAADA CwAAswAL8HoAAAB/AAAA6wG/AQAAEQDAAQEAAAjLAZwxAADQAQUAAADRAQUAAAD/ARgAGAADAwAA AAA/AwgACACAwzgAAAC/AwAAAgBTAHQAcgBhAGkAZwBoAHQAIABBAHIAcgBvAHcAIABDAG8AbgBu AGUAYwB0AG8AcgAgADMAOAAAAAAAEPAIAAAAuAr6BWcMuAoPAATwnAAAAAICCvAIAAAABzAAAAAL AACjAAvwdAAAAH8AAADrAb8BAAARAMABAQAACMsBnDEAANEBBQAAAP8BGAAYAAMDAAAAAD8DCAAI AIDDOAAAAL8DAAACAFMAdAByAGEAaQBnAGgAdAAgAEEAcgByAG8AdwAgAEMAbwBuAG4AZQBjAHQA bwByACAAMwA4AAAAAAAQ8AgAAAC0BcsOyw6iCQ8ABPAAAQAAogwK8AgAAAAIMAAAAAoAAIMAC/BG AAAAfwAAAO8BgABgpmAFvwACAAYAvwEAABAA/wEAABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgA dABCAG8AeAAgADMAOQAAAAAAEPAIAAAA4AoeBQQNyQsPAA3wigAAAAAAnw8EAAAAAQAAAAAAqA8I AAAAICAgICAgIGkAAKEPOgAAAAkAAAAAACUoCgAAAAAAAP8BAAAABwAHAAAAAABnAAIA//8CABIA /wAA/gIAAAAAAGMAAgD//wIAEgAAAKoPDgAAAAkAAAAHAAAAAAAJBAQIAACmDw4AAAD4AAAAAADU AdAC8AMQBQ8AA/A8CwAADwAE8HgAAAABAAnwEAAAALBgMwA8ph0Aw8FNAOMXKwACAArwCAAAAAkw AAABAgAAQwAL8CoAAAAEAAAAAAB/AAAA4QGAwxIAAAC/AwAAAgBHAHIAbwB1AHAAIAAyADcAAAAT ACLxBgAAAH8AAAAAAgAAEPAIAAAAiwmbDNwQtgsPAATwrAkAABIACvAIAAAADTAAAAIKAADzAAvw dAAAAH8AAAAEAIAAQKtgBYcAAQAAAL8AAAAGAL8BAAAQAMABAQAACP8BCAAIAAECAAAAAAQCmVkA AAUCAAAAAAYC2FkAABECAIAAAD8CAgADAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAA MgA4AAAAMwAi8ZIIAAD/AQAAQAAcAkCcAACpw4AIAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEA ABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJ mVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9 C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kAS aWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJEl Dxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYA CAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5L B7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzc SWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQ j24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxM q/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAVxbBrGgQAADUTAAAQAAAAZHJzL3NoYXBleG1s LnhtbOxYzW7bOBC+L7DvQPC6cC35T7JRpUgCuHvwBkacPgBNU7Y2FCmQtNfO0+8MKdlqm64XcXpo mxxiShpy5vuGnB++/7AvJdkJYwutMhq/iygRiutVodYZ/fQw7aSUWMfUikmtREYPwtIPV7//9r6a 2IrAZGUnVUY3zlWTbtfyjSiZfacroeBbrk3JHDyadbcywgrlmANFpez2omjULVmh6BUspXaLam5w xO92c0OKFdgypkSxEnTeCw4WrKUgvZR2aymc4McKJsCg217F+tXYZJ+bsjaS/R8jV4b9A8i/sI9N dJ6TfUb7/VESpcDIAc0b9OMoQnvYROwd4SAQJ700SRNKOEikaRyN+ijQDZagZGWs+yj0xVYRXCij BqgBBtmE7WbWBVWNCnyt9LSQ8lIKPEapLl0GDbJaFiu0yT/gdhG30pAdkxl1+7hmqyUF3Enl3Ruc CvvOHaTA6VLdC/CL34Mvdi/sNXScJ9Fv35M9jHPYsY1NXhuqzcH6V1PcP6+41oeqRZ6Dw19Nee+8 8qNGj1yr11NeFkqb5wyQR8rzoC94P3i9mrj9jV4d0Jwl/EKwuHQDMMU32mSUOxNOs7RugdouXRlt lDsZQzAigs3UjXnMKATYDQQziDLzreJwhCPPwUrk9xgBX3BCQAlEVUXcoRI54xAwr03BJAShDTNW eBUhSrGWzF8LMv+o3abglFSF45spKwsJYas/aM3sxCHkwilsLMQDGUDV+HqIr2RmltFk0BsPAWGh VnByMtrppcMEX/xs8BFzDb9/gh/Hg34EOaGFv5eO8MXPhh9B1/gHLfyAFRL7L4AfQdf4hyf8vWiY DH4J/Ai6xj9q4R/GA7/dT+f/mf2PUf1arqHcXDIrng+HtuI3IkcNMJpzFwoEX21B/Pns63Xu/kOu /toErx8lvCKpNb9Ji99xEqdn99cbv8fE9830haTW/KYnfvuQvs7H7zd+z/OLpNb8jlv8punofH54 4/c8v0iq7yubWhXJbvrxF/dCfpFjMQd5HKq6e1+yQsXnf5vADt+YD+FYNBOIrg9suXjK6Dge+ARo XJA/1j0xJV/61Vet36qKQ0Mm1aLiaFU7C0DXjYc0NLttiVfNGMst9KUPe184L7eLp+NwCunr+HAH lyJexLFlaMCbQjmYVx8DoVZzZhhU+ORxWxal/rsItEInkFGhOp8WSKib+eenTef2Dq5dgM8Q7peB e/9/m1EFSvFWxhSPUOwrvfAjSh6FwTscf8I4g1uZWrDifia0WyWTxZP40z9i8pUF3umAM5WeG61z P7alu5WCwVKhNcH2u7lJaEj3PvmslTfr5bGRn/q/r3v5poFtmNrOVM3kFq8E6vH372bYhNtWK/RH qTrc1uaeXOXPV+Wbz6bnhEsmW139CwAA//8DAFBLAwQUAAYACAAAACEAo0FgrdcAAAD6AAAADwAA AGRycy9kb3ducmV2LnhtbESPQUsDMRBG74L/IYzgzWZVqLo2LSJdFIXiVtHruJlmw26SbZK223/v 4EGPwxvex5stRteLPcVkg1dwOSlAkG+Ctt4o+HivLm5BpIxeYx88KThSgsX89GSGpQ4HX9N+nY1g iU8lKmhzHkopU9OSwzQJA3lmmxAdZj6jkTrigeWul1dFMZUOreeFFgd6bKnp1junoFvdxOlQW7Pr qu3bsnq5Xr2aL6XOz8aHexCZxvz/vCw+q233B39Vz5pb7kBsno7f0eoaU6aogOM4lRHI+Q8AAAD/ /wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAFcWwaxoEAAA1EwAAEAAAAAAAAAAAAAAAAAApAgAA ZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCjQWCt1wAAAPoAAAAPAAAAAAAAAAAAAAAA AHEGAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAdQcAAAAAAAAP8BAAAACwYDMAPKYd AMPBTQDjFysADwAN8GYAAAAAAJ8PBAAAAAEAAAAAAKEPJgAAAAEAAAAAACUoCgAAAAAAAP8BAAAA BwABAAAAAAAmAP//EgD////+AACqDw4AAAABAAAABwAAAAAACQQECAAApg8OAAAA+AAAAAAA1AHQ AvADEAUPAATwAAEAABIACvAIAAAADjAAAAIKAACTAAvwTgAAAH8AAADvAYAAwKxgBYUAAgAAAL8A AgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANwAA AAAAD/AQAAAAXd42ANydHwBqu0kAl3opAA8ADfB6AAAAAACfDwQAAAABAAAAAACoDxAAAABSZXNv dXJjZSALU2VydmVyAAChDyIAAAARAAAAAAAlKAoAAAAAAAD/AQAAAAcAEQAAAAAAIgD//xIAAACq Dw4AAAARAAAABwAAAAAACQQECAAApg8OAAAA+AAAAAAA1AHQAvADEAUPAATw6wAAAKIMCvAIAAAA CjAAAAAKAACTAAvwTAAAAH8AAADvAYAAYKxgBYUAAgAAAL8AAgAGAL8BAAAQAP8BAAAYAD8DAAAI AIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgAIAAzADkAAAAAABDwCAAAADIHYA05DhsIDwAN8G8A AAAAAJ8PBAAAAAEAAAAAAKgPAwAAAGlpaQAAoQ8kAAAABAAAAAAAJSAKAAAAAAAA/wAABwAEAAAA AABjAAIA//8CABIAAACqDw4AAAAEAAAABwAAAAAACQQECAAApg8OAAAA+AAAAAAA1AHQAvADEAUP AATw6gAAAKIMCvAIAAAACzAAAAAKAACTAAvwTAAAAH8AAADvAYAA4KpgBYUAAgAAAL8AAgAGAL8B AAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgAIAAzADkAAAAAABDwCAAA AJoFLQfkB4MGDwAN8G4AAAAAAJ8PBAAAAAEAAAAAAKgPAgAAAGlpAAChDyQAAAADAAAAAAAlIAoA AAAAAAD/AAAHAAMAAAAAAGMAAgD//wIAEgAAAKoPDgAAAAMAAAAHAAAAAAAJBAQIAACmDw4AAAD4 AAAAAADUAdAC8AMQBQ8ABPCiAAAAAgIK8AgAAAAMMAAAQAsAALMAC/B6AAAAfwAAAOsBvwEAABEA wAEBAAAIywGcMQAA0AEFAAAA0QEFAAAA/wEYABgAAwMAAAAAPwMIAAgAgMM4AAAAvwMAAAIAUwB0 AHIAYQBpAGcAaAB0ACAAQQByAHIAbwB3ACAAQwBvAG4AbgBlAGMAdABvAHIAIAAzADgAAAAAABDw CAAAALcEKgQjDFMJPwAF8GAAAAABABLwGAAAAAEAAAAAAAAAAAAAAAYwAAD//////////wEAEvAY AAAAAgAAAAAAAAAAAAAABzAAAP//////////AQAS8BgAAAADAAAAAAAAAAAAAAAMMAAA//////// //8QAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAAAAAdBAQAAAABAAAADwDu AxcDAAACAO8DGAAAABAAAAAAAAAAAAAAAKgAAIAAAAAABwAxAA8ADAS7AgAADwAC8LMCAADwAAjw CAAAAAMAAAADNAAADwAD8JsCAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAADQAAAUAAAAPAATwBQEAABIACvAIAAAAAjQAACACAAADAQvwcAAAAAQAAAAAAH8AAQDvAYAA 4K1gBYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BEAAR AAEDAgwAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAgADEAAAAAABDwCAAAAKoAJwFnFdAC DwAR8BwAAAAAAMMLCAAAAP////8NABIuAAAfBAQAAAACAAAADwAN8EEAAAAAAJ8PBAAAAAAAAAAA AKgPCQAAAE5leHQgU3RlcAAAqg8cAAAACQAAAAcAAAAAAAkEBAgBAAAABwAAAAAACQgECA8ABPBW AQAAEgAK8AgAAAADNAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgACArWAFgQAwZQEAggCYsgAA gwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDDAAAPwMA AAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIA AAAAABDwCAAAAPICngAPFiIPDwAR8BwAAAAAAMMLCAAAAP////8TABIuAAAfBAQAAAADAAAADwAN 8HAAAAAAAJ8PBAAAAAEAAAAAAKgPRgAAAERpc2N1c3MgdGhlIHNjb3BlIGFuZCBjaGFydGVyIGlu IHRoZSBtYWlsaW5nIGxpc3QsIGFuZCBnZXQgY29uc2Vuc3VzLiAAAKoPDgAAAEcAAAAHAAAAAAAJ BAQIEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAAAAHQQEAAAAAQAAAA8A 8AOvAwAAAQDxAwgAAAASAgAABwD4LQ8ADARvAwAADwAC8GcDAABgAAjwCAAAAAQAAAAEPAAADwAD 8E8DAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAADwAAAUAAAAPAATw /QAAAKIMCvAIAAAAAjwAAAAKAACTAAvwTgAAAH8AAQDvAYAAYGNgCIcAAgAAAL8AAAAGAL8BAAAQ AP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANwAAAAAAEPAIAAAA YBWQCeAQgBYPABHwCQAAAAAAIAQBAAAACA8ADfBuAAAAAACfDwQAAAACAAAAAACgDwIAAAAqAAAA oQ8aAAAAAgAAAAAAACgKAAIAAAAHAAIAAAAAACAA//8AANgPBAAAAAAAAAAAAKoPDgAAAAIAAAAH AAAAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwygAAABIACvAIAAAAAzwAACACAAAzAQvw igAAAAQAAAAAAH8AhQHvAYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAA AL8AAAAGAIABAAAAAIEB////AIIBAAABAL8BEAAQAP8BAQARAAEDBDgAAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAAsAHQAhAOIAoPABHwEAAAAAAAwwsI AAAAAAAAAAsAEi4PAATwQAEAABIACvAIAAAABDwAACACAABzAQvwogAAAAQAAAAAAH8AAQDvAYAA QGVgCIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAIABAAAA AIEB////AIIBAAABAL8BEAAQAMABAAAAAMEBAAABAMQBAAAAAP8BCQAZAAEDBTgAAD8DAAAIAIDD GAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAsApAAqAO0BQPABHwEAAA AAAAwwsIAAAAAQAAAAwAEi4PAA3wVgAAAAAAnw8EAAAAAgAAAAAAoQ8YAAAAAQAAAAAAACAKAAAA BwABAAAAAAACABIAAACqDw4AAAABAAAABwAAAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFEADw ByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAAAAchdEAAAAAQAAAQAAAAD1owAA YiEAAAJAAACaZAAAcuYAAGrrAACI7wAA8/MAAGYDAQA4CAEA0A4BAGseAQBDJAEAaU4BAIhRAQAA APUPHAAAAAAAAADAGwADAAAAAD9VAQABAAAAEAAAAAEAVFUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACk4gAADAAA AAEAAABoAAAAAgAAAHAAAAAEAAAAgAAAAAgAAACQAAAACQAAAKwAAAASAAAAuAAAAAoAAADcAAAA CwAAAOgAAAAMAAAA9AAAAA0AAAAAAQAADwAAAAwBAAARAAAAFAEAAAIAAADkBAAAHgAAAAgAAABE aWEgMQAAAB4AAAAIAAAAVGVybwAAAAAeAAAAFAAAAEhhbm5lcyBUc2Nob2ZlbmlnAAAAHgAAAAQA AAA5OTgAHgAAABwAAABNaWNyb3NvZnQgT2ZmaWNlIFBvd2VyUG9pbnQAQAAAAPA9j/RNAAAAQAAA AIDdHK0oUsoBQAAAAJCKJBPXjc4BQAAAAJCzoasoOc8BAwAAAK0BAABHAAAAiOEAAP////8DAAAA CACJEGcMAAABAAkAAAO8cAAAAAChcAAAAAAFAAAACwIAAAAABQAAAAwC0ALAAwUAAAAHAQMAAACh cAAAQQsgAMwAeACgAAAAAADQAsADAAAAACgAAACgAAAAeAAAAAEAGAAAAAAAAOEAAAAAAAAAAAAA AAAAAAAAAAAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAY OQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAY MQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAY OQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAY OQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAY OQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAY MQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAY OQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAY OQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAY MQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAY OQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQ MQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAY OQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAY MQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAY OQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQ MQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAY OQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAY OQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAY OQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAY OQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAY MQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAY OQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAY OQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAY OQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAY MQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAY OQAYMQAYOQAYOQAYOQAYMQAYOQAYOQD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////9jtf////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///W//+MtbVjY2PWjIw5jNYAAADWjDkAY7UAAAD/tWP///8AY7UAAAD/tWM5jNYAAAC1YwC1tbX/ //////////+MjLUAY4wAAAD/tWO1///WjIy1tbX////W//8AOYxjAAAAY2OMOQD//9b///8AY7Vj OQAAOWNjAAC1tWOMtf8AOTk5AAAAOTljAAC1tWO1tf///7X///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////+MjNa1tbXW/7W1jIz///////8AY7UAAAD/tWP/ //8AY7VjAADW/7XWtbX///+MjNYAY2NjAAD//7X///+MjLUAY4wAAAD/tWO1///WjIwAY7VSAAA5 OWM5c3OMYwC1jIyMjNb//7X///+1tbXW//8AOYxjAAAAY2M5AAAAOTk5AAAAOTljAAAAY2NjAAD/ /7X///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////+1//+1 Y2P///85jNYAAADWjDkAY7U5AAD/1oz///8AY7U5AAD/1ow5jNYAAADWjDkAY7U5AAD/1oz///+M jLUAY4w5AAD/1owAY7U5AAAAOTk5AAD/1owAY7WMOQAAY4yMOQD//9b///+1tbX///////////// //////////+1tf///7X///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////8AY7WMOQD//9b///////////////////////////////////////////////// //////////85jNYAAAAAAAC1Yzn//9b///////////////////////////////8AY7WMOQD//9b/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////+1tbVjY7WMtbUAOTljAACMtWO1jIy1tbW1tbWMtf+1jDmMjNb//7X///8AY7WMOQCMtYwA OYyMOQCMjIzW1rXW//8AOYw5AAAAOTljOQAAOWNjAACM1ozWtbWMjIzWtbWMtbUAOYxjAACMjGO1 tYxjjLUAOWNjAACMtWO1jIyMjNb//7X///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9jtbW1tbWMY7UAOTljAACMtWO1jIy1tbUAY7U5 AAAAOTljAAD//7X///+1tbX///+MtbUAOYyMYwCMY4y11tbW//8AOYw5AAAAOTk5AAAAOTljAABj jGPWtYy1tdaMjIyMtYwAOYw5AABjYzm1jGPW//8AOYxjAAAAY2MAAABjAAD//7X///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////9jY7X/ /7VjY7X//7X///9jtf+1jIxjtf////////////////////////+1tbX///9jtf////////+1tbX/ //////////////////////////////+M1v8AADkAAAD/tWNjtf////////+1tbU5Y7X/1oz///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8AY7XWjDn///// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////W//9jOYz//7X///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////+1tbW1//+M Y2MAOYw5AAAAOTmMOQC1tYxjjNYAOTljAAC1tWOMtf8AOTmMOQC1tYwAY7U5AACMjDkAOYxjAAD/ /7XW//+MtbVjY2PWjIwAY7UAAADWjDnW1tb///8AY7UAAADWtWMAOYxjAAC1tWO1tbVjtf//tWP/ //8AY7VjOQAAOWNjAAC1tWMAY7U5AAAAOTljAAD//7X///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////8AY7UAAADWtWMAOYw5AAAAOTm1YwAAY7U5AAAAOTljAAAAY2M5AAAA OTm1YwC1tbUAY7U5AACMjDkAOYxjAAD//7X///+MjNa1tbX//7W1tbX///+1tbW11v////8AY7Vj AADW/7UAOYxjAAA5Y2MAOTm1YwCMjLX//9a1tbXW//8AOYxjAAC1tWMAY7U5AAAAOTljAAD//7X/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8AY7UAAADWjDn///////// //////////////////////////////////////9jtf+1tbXW//+1jIz///////////////+1//+1 Y2P///8AY7UAAAD/tWP///////8AY7U5AAD/1oz///////////////////////////+1tbX///// //////9jtf+1tbX///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////8AY7XWjDn///////////////8AY7WMOQD//9b///////////////9jtf////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8AY7WMOQD//9b///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////8AY7UAAAD/tWM5jNYAAAC1YwC1tbX///////85jNYAAADWjDm1tbWMtf8AOTljAAC1 tWOMtbUAOYyMOQDW1rX///////+1tbVjtf+1jDkAOYxjAAC1tWNjjNYAOTljAAC1tWOMtf+1jDmM jNb//7X///8AY7WMOQC1tYz///////+1tbXW//+1tbUAOYxjAAC1tWO1tf+1tWOMtf8AOTk5AAAA OTmMOQD//9b///+1//+1jIwAOYxjOQAAOWOMOQC1tYyMtf8AOTljAACMtWMAOYxjAAC1tWO1tf+M tWO1jIyMjNb//7X///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////8AY7VjAADW/7XWtbX///+MjNYAY2NjAADW /7W1jIz///////8AY7U5AAAAOTljAAC1tWMAY7UAAAC1YwC11v////////8AY7W1YwDW//8AOYxj AAAAY2M5AAAAOTljAAAAY2M5AAAAOTljAAD//7X///+1tbX///+1tbX///////8AY7UAAAC1jDkA OYxjAAAAY2NjAAAAY2M5AAAAOTk5AAAAOTm1YwD///////+1//+1jIwAOYyMYwAAOYxjAAAAY2M5 AAAAOTk5AACMjDkAOYxjAAAAY2NjAACMtWMAOYxjAAD//7X///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A Y7U5AAD/1ow5jNYAAADWjDkAY7U5AAD/1ow5jNYAAADWjDm1tbX///////////9jtf////////// //////////////+1tbVjtf/WjDn///////////////////////////////////////////////+1 tbX///9jtf////////+1tbXW///WtbX///////////////////////////////////////////// //8AY7U5AAD/1oz///////////+1tbX///////////85Y7X/1oz///////////9jtf////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////9jtf////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////9jtf//tWNjjNbW 1owAOYw5AAAAOTljAAD//7UAY7WMOQAAY4yMOQDW1rUAY7WMOQAAY4yMOQD//9bW///WtbXW///W tbW11tYAOYxjAAAAY2OMOQD//9b///////////////8AY7UAAADWtWMAOYw5AAC1jDm1tbW1tdaM tdYAOTljAACMtWMAOYw5AAC1jDn///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////+MjLWMtYyMtbXWtbUAOYw5AAAAOTljAADW/7XWtbWMtf+1jDmMjNaM1rXW tbWMtf/WtWOUtf85OWOMlIzWtWOMtf/WtWO11v+M1v+MYznWtbW1tf///7X///////////////8A Y7VjAADW/7UAOYw5AAC1jDkAY7UAAAA5AAAAOTljAAAAY2MAAAA5AAC1jDn///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////W///WtbVjjNb/1oy1tbX///////// //+1tf///7UAY7WMOQAAY4yMOQD//9YAY7WMOQAAY4yMOQD//9a1///WjIy1///WjIz///8AY7WM OQAAY4yMOQD//9b///////////////8AY7U5AAD/1oz////W//+1jIz///////////////////// ///////W//+1jIz///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////8AY7XWjDn///////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9jtf8AAAAAAAA5AAD/1ozW//8A OYwAAABjAAD//7VjjNb/1oz///////////////////9jtdYAADkAAAA5AAD/1oxjtf8AAAA5OQDW jGNjjNb/1oyM1v//tYy1//+1Y2NjjNb/1oyM1v//tYy1//+1Y2M5jNYAAAAAAADWjDljY7X//7XW //+MY4z//9b///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////9jtf//tWP///+1//+1Y2M5jNb/tWP///+M1v+1YzljjNb/1oz///////////////////+1 tf///7X///+1//+1Y2NjjNb/1oxjtf/WjDljjNb/1oyM1v//tYy1//+1Y2NjjNb/1oyM1v//tYy1 //+1Y2NjY7X//7Vjtf/WjDljY7X//7W1//9jOYz/1oz///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9jtf8AAAAAAAAAAAD/tWNjY7X//7X////W//+1 jIw5jNYAAAAAAAD/tWP////////////W//8AOYwAAAA5AAD/1oxjjNb/1oyM1v/WjGM5jNbWjDmM 1v+1Yzm1//+1Y2M5jNbWjDmM1v+1Yzm1//+1Y2OM1tYAAGMAAADWjDk5Y7X/1oyMtf+11ozWjIz/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////9jtf// tWP///+M1v//tYw5jNb/tWP///+M1v/WjGNjjNb/1oz///////////////////9jjNb/1oz////W ////1tZjjNb/1oyM1v/WjGNjjNY5Y2M5AABjjIwAAADWjDljjNY5Y2M5AABjjIwAAADWjDljtf8A AAAAAAD/tWM5Y7VjOTmMjGP//9aMjLX//9b///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////9jtf8AAAAAAAA5AAD/1ozW//8AOYwAAABjAAD//7U5jNYAAAAA AAC1YwD///////////+1//8AAGMAAAA5AAD/1oz///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////W//+MY4z//9b///// ///////////////////////////////////////////////W//+MY4z//9b///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////W//8AOYwAAABjAAD//7WM1v8AADk5 AAD/1oxjjNb/1oyM1v+1jGMAOYwAAAAAAAD/tWNjtf+MOQBjY4z//7U5jNYAAAAAAADWjDljtf// tWNjjNb/1oyM1v/WjGOM1v8AADkAAADWjDk5jNYAAAA5OTn/tWP///////9jtf8AAAAAAAAAAAC1 YwBjjNb/1oyM1v/WjGOM1v85ADn/1oxjtf//tWNjY7X//7WM1v8AADk5AAD/1oxjjNb/1oyM1v/W jGNjjNb/1oyM1v//tYy1//+1Y2OM1v8AADkAAADWjDljjNb/1oyM1v/WjGNjtf9jOQAAOWMAAAAA AAD/tWP///////+Mtf/W1oyMY4z//9b///+1//85AGPW1owAOYwAAABjAAD//7Vjtf8AAAAAAAAA AAC1YwCM1v//tYz///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //85jNb/tWP///+M1v+1YzljY7X//7W1//+1Y2NjjNb/1oyM1v/WjGP///+M1v8AADm1YwCMtf// 1oxjY7X//7VjY7X//7Vjtf/WjDljtf//tWNjjNb/1oyM1v/WjGNjY7X//7X///+1//+1Y2P///85 jNb/tWP///////9jtf//tWP///////////9jjNb/1oyM1v/WjGM5jNZjY2PWjDljtf//tWNjY7X/ /7VjY7X//7W1//+1Y2NjjNb/1oyM1v/WjGNjjNb/1oyM1v//tYy1//+1Y2NjY7X//7X///////9j jNb/1oyM1v/WjGOMtf//1oz///+M1v8AADm1YwD///////9jY7X//7Vjtf//tWP///85jNbWjDk5 jNb/tWP///+M1v+1Yzljtf//tWP///////////+1//+1Y2P///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////9jY7X//7X///////////9jY7X//7W1//+1Y2NjjNb/ 1oyM1v+1jGMAOYwAAAD/tWP///+Mtf//1ow5Y7X/1oyM1tYAAGMAAADWjDljtf//tWNjjNb/1oyM 1v/WjGMAY7UAAAAAAABjYwC1Y2P///8AY7X/tWP///////9jtf8AAAAAAAAAAAD/tWNjjNb/1oyM 1v/WjGNjY7W1/7W1Y2Njtf//tWM5Y7X/1oxjY7X//7W1//+1Y2NjjNb/1oyM1v/WjGM5jNbWjDmM 1v+1Yzm1//+1Y2MAY7UAAAAAAAC1YwBjjNb/1oyM1v/WjGOMtf/W1owAOYwAAAD/tWP///////// //9jY7X//7XW//8AOYwAAABjAAD//7VjY7X//7X///////////9jtf8AAAAAAAAAAAD/tWO1//+1 Y2P///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////85jNb/tWP/ //+M1v/WjGOM1v8AADk5AAD/1ow5jNYAAAAAAAD/tWMAY7UAAAAAAADWtWMAOYyMOQA5Y4xjOTlj tbUAAAAAAAD/tWNjtf//tWM5jNYAAAAAAAD/tWOM1v8AADk5AAD/1ow5jNYAAABjY2P/tWP///// //9jtf//tWP///////////85jNYAAAAAAAC1tWO1Y2P///9jY7VjtbX/tWM5Y7VjOTmM1rUAADk5 AAD/1ow5jNYAAAAAAAD/tWNjjNY5Y2M5AABjjIwAAADWjDmM1v8AADk5AAD/1ow5jNYAAAAAAADW tWMAOYyMOQAAY4wAAAAAAAD/tWP///////+Mtf//1oz///85jNZjY2O1YwD///85jNb/tWP///+M 1v/WjGNjtf//tWP///////////+M1v//tYz///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////W//8AOYwAAABjAAD//7X///////////////////////////////// //////////////+Mtf//1oz///////////////////////9jtf//tWP///////////////////// //////////////////9jtf//tWP///////9jtf8AAAAAAAAAAADWjDn///////////////////// //////9jtf//tWP///////////////////////////////////////////////////////////// //////////////////////////////////+Mtf//1oz///////////////////////+1//+MOWP/ /9a1//85AGP/1oz////W//8AOYwAAABjAAD//7Vjtf8AAAAAAAAAAAC1jDmMY4z//9b///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////W//+MY4z//9b///+1//85AGNj jIwAAAA5OQDWjGNjtf+MOQBjjLX/1oyM1v/WjGOM1v8AADkAAADWjDljjNb/1oyM1v/WjGNjtf+M OQBjtdb/tWO1//8AAGMAAAC1YwA5jNYAAAAAAADWjDljtf+MOQBjtdb/tWOM1v8AADk5AAD/1oxj jNb/1oyM1v/WjGP///////85jNYAAAAAAADWjDljjNb/1oyM1v/WjGM5jNYAAAA5OTn/tWP////W //+MY4z//9b///+1//85AGNjjIwAAAA5OQDWjGNjtf+MOQBjjLX/1oyM1v/WjGOM1v8AADk5AAD/ 1oxjY7X//7Vjtf+1tWMAAGMAAAA5AAA5Y2MAAAAAAADWjDljtf+MOQBjtdb/tWOM1v8AADk5AAD/ 1oxjjNb/1oyM1v/WjGP///////9jtf//tWOM1v8AADk5AAD/1oxjY7X//7X///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////9jtf//tWP///85jNbWjDljjNb/1oxjtf/WjDmMtf//1oxjjNb/1oyM1v/WjGNjY7X/ /7X///////9jjNb/1oyM1v/WjGOMtf//1oxjtf//tWNjjNb/1oz///////9jY7X//7Vjtf/WjDmM tf//1oxjtf//tWNjY7X//7W1//+1Y2NjjNb/1oyM1v/WjGP///////9jY7X//7Vjtf/WjDljjNb/ 1oyM1v+MjGO1Y2P///85jNb/tWP///////9jtf//tWP///85jNbWjDljjNb/1oxjtf/WjDmMtf// 1oxjjNb/1oyM1v/WjGNjY7X//7W1//+1Y2NjY7X//7Vjtf//tWM5jNa1YwD///9jY7X//7Vjtf/W jDmMtf//1oxjtf//tWNjY7X//7W1//+1Y2NjjNb/1oyM1v/WjGP///////9jtf//tWNjY7X//7W1 //+1Y2NjY7X//7X///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////W//8AOYwAAABjAAD//7VjjNb/1oyM1v/W jGOMtf//1ow5jNb/tWOM1v/WjGMAY7UAAAAAAAC1YwBjjNb/1oyM1v/WjGOMtf//1oxjtf//tWNj jNb/1oz////W1taM1tYAAGMAAADWjDmMtf//1oxjtf//tWNjY7X//7W1//+1Y2NjjNb/1oyM1v/W jGP///////+M1tYAAGMAAADWjDljjNb/1oyM1v+MjGO1Y2P///8AY7X/tWP////////W//8AOYwA AABjAAD//7VjjNb/1oyM1v/WjGOMtf//1ow5jNb/tWOM1v/WjGNjY7X//7W1//+1Y2M5Y7X/1oxj tf//tWPW//8AOYz/tWOM1tYAAGMAAADWjDmMtf//1oxjtf//tWNjY7X//7W1//+1Y2NjjNb/1oyM 1v/WjGP///////9jtf//tWNjY7X//7W1//+1Y2M5Y7X/1oz///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //85jNZjY2O1YwD///9jjNb/1oyM1v+1jGMAOYyMOQBjjLUAOTkAAAD/tWOM1v8AADk5AAD/1ow5 jNYAAAAAAADWtWMAOYyMOQBjtdb/tWOM1v8AADkAAADWjDljtf8AAAAAAADWtWMAOYyMOQBjtdb/ tWOM1v8AADk5AAD/1ow5jNYAAAAAAAD/tWP///////9jtf8AAAAAAAD/tWM5jNYAAAAAAAD/tWM5 jNYAAABjY2P/tWP///////////85jNZjY2O1YwD///9jjNb/1oyM1v+1jGMAOYyMOQBjjLUAOTkA AAD/tWOM1v8AADk5AAD/1ow5Y7VjOTljtbXWtWMAOYwAAACMOQBjtdYAAAAAAADWtWMAOYyMOQBj tdb/tWOM1v8AADk5AAD/1ow5jNYAAAAAAAD/tWP////W//8AOYxjAACM1rUAADk5AAD/1ow5Y7Vj OTn//7X///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////+1//85AGP/1oz///////////////////+Mtf//1oxj jNb/1oz///////////////////////////////////////+Mtf//1oxjtf//tWP///////////// //////////////////+Mtf//1oxjtf//tWP///////////////////////////////////////// //////////////////////////////////////9jtf//tWP///////////+1//85AGP/1oz///// //////////////+Mtf//1oxjjNb/1oz///////////////////////////////9jtf//tWP///// //////////////////////+Mtf//1oxjtf//tWP///////////////////////////////////// //9jtf85AAD/1oz///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////8YMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAY OQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQ MQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAY OQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAY MQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAY OQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQ MQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAY OQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAY MQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYOQAYMQAYOQAY OQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAY OQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAY MQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAY OQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAY OQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAY OQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAY MQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAY OQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAYOQAYOQAYMQAYOQAY OQAYOQAYMQAYOQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAY MQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAY OQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQ MQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAY OQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAY MQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAY OQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQ MQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAY OQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQAQMQAYOQAYMQAYOQADAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4b EJOXCAArLPmu9AIAALACAAAPAAAAAQAAAIAAAAADAAAAiAAAAAQAAACoAAAABgAAALAAAAAHAAAA uAAAAAgAAADAAAAACQAAAMgAAAAKAAAA0AAAABcAAADYAAAACwAAAOAAAAAQAAAA6AAAABMAAADw AAAAFgAAAPgAAAANAAAAAAEAAAwAAABZAgAAAgAAAOQEAAAeAAAAGAAAAE9uLXNjcmVlbiBTaG93 ICg0OjMpAAAAAAMAAAAZwAEAAwAAAD4AAAADAAAACgAAAAMAAAABAAAAAwAAAAAAAAADAAAAAAAA AAMAAAAAAA4ACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAEAAAAAYAAABBcmlh bAALAAAATVMgUEdvdGhpYwAIAAAAQ2FsaWJyaQAQAAAAMl9PbGV0dXNyYWtlbm5lABAAAAAzX09s ZXR1c3Jha2VubmUAEAAAADRfT2xldHVzcmFrZW5uZQAYAAAAUG93ZXJQb2ludCBQcmVzZW50YXRp b24AEgAAAEV4ZWN1dGl2ZSBTdW1tYXJ5ABoAAABDb25zdHJhaW5lZCBOb2RlIE5ldHdvcmtzABsA AABVc2UgQ2FzZXMgYW5kIFJlcXVpcmVtZW50cwAcAAAAQXJjaGl0ZWN0dXJlIERlc2lnbiBDaG9p Y2VzAA0AAABHYXAgQW5hbHlzaXMAEwAAAENoYXJ0ZXIgRGlzY3Vzc2lvbgARAAAAU2NvcGUgRGlz Y3Vzc2lvbgASAAAAT3BlbiBJc3N1ZTogU2NvcGUACgAAAE5leHQgU3RlcAAMEAAABgAAAB4AAAAL AAAARm9udHMgVXNlZAADAAAAAwAAAB4AAAAGAAAAVGhlbWUAAwAAAAMAAAAeAAAADQAAAFNsaWRl IFRpdGxlcwADAAAACgAAAAD4CwAACgAAAAAAAABYAAAAAQAAABUBAAACAAAAHQEAAAMAAACJCQAA BAAAAIUKAAAFAAAAnQoAAAYAAACZCwAABwAAALELAAAIAAAAyQsAAAkAAADhCwAACAAAAAIAAAAM AAAAX1BJRF9ITElOS1MAAwAAAA8AAABfbXNfcElEXzcyNTM0MwAEAAAAEgAAAF9tc19wSURfNzI1 MzQzXzAwAAUAAAAQAAAAX21zX3BJRF83MjUzNDMxAAYAAAATAAAAX21zX3BJRF83MjUzNDMxXzAw AAcAAAAQAAAAX21zX3BJRF83MjUzNDMyAAgAAAATAAAAX21zX3BJRF83MjUzNDMyXzAwAAkAAAAG AAAAc2ZsYWcAAgAAAOQEAABBAAAAZAgAAEgAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAA BwAAAB8AAAA/AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBp AGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBhAGMAZQAvAGMAdQByAHIAZQBuAHQALwBtAHMA ZwAwADAAMwAwADkALgBoAHQAbQBsAAAAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAA AAAAAAADAAAABwAAAB8AAAA+AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIA ZwAvAHAAcgBvAGMAZQBlAGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkAZABl AHMALQA4ADkALQBhAGMAZQAtADIALgBwAGQAZgAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYA AAADAAAAAAAAAAMAAAAHAAAAHwAAAD4AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAu AG8AcgBnAC8AcAByAG8AYwBlAGUAZABpAG4AZwBzAC8AOAA5AC8AcwBsAGkAZABlAHMALwBzAGwA aQBkAGUAcwAtADgAOQAtAGEAYwBlAC0AMwAuAHAAZABmAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAAD AAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAPwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUA dABmAC4AbwByAGcALwBwAHIAbwBjAGUAZQBkAGkAbgBnAHMALwA4ADkALwBzAGwAaQBkAGUAcwAv AHMAbABpAGQAZQBzAC0AOAA5AC0AYQBjAGUALQA0AC4AcABwAHQAeAAAAAAAHwAAAAEAAAAAAAAA AwAAAAcAAAADAAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAPwAAAGgAdAB0AHAAOgAvAC8AdwB3 AHcALgBpAGUAdABmAC4AbwByAGcALwBwAHIAbwBjAGUAZQBkAGkAbgBnAHMALwA4ADkALwBzAGwA aQBkAGUAcwAvAHMAbABpAGQAZQBzAC0AOAA5AC0AYQBjAGUALQA1AC4AcABwAHQAeAAAAAAAHwAA AAEAAAAAAAAAAwAAAAcAAAADAAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAPwAAAGgAdAB0AHAA OgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAv AHcAZQBiAC8AYQBjAGUALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADMAMAA3AC4AaAB0AG0A bAAAAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAADAAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAPwAA AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMA aABpAHYAZQAvAHcAZQBiAC8AYQBjAGUALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADMAMAA5 AC4AaAB0AG0AbAAAAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAADAAAABgAAAAMAAAAAAAAAAwAAAAcA AAAfAAAAPgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBwAHIAbwBj AGUAZQBkAGkAbgBnAHMALwA4ADkALwBzAGwAaQBkAGUAcwAvAHMAbABpAGQAZQBzAC0AOAA5AC0A YQBjAGUALQAyAC4AcABkAGYAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAAD AAAABwAAAB8AAAA+AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAHAA cgBvAGMAZQBlAGQAaQBuAGcAcwAvADgAOQAvAHMAbABpAGQAZQBzAC8AcwBsAGkAZABlAHMALQA4 ADkALQBhAGMAZQAtADMALgBwAGQAZgAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAA AAAAAAMAAAAHAAAAHwAAAD8AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBn AC8AcAByAG8AYwBlAGUAZABpAG4AZwBzAC8AOAA5AC8AcwBsAGkAZABlAHMALwBzAGwAaQBkAGUA cwAtADgAOQAtAGEAYwBlAC0ANAAuAHAAcAB0AHgAAAAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAA AAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAAD8AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQA ZgAuAG8AcgBnAC8AcAByAG8AYwBlAGUAZABpAG4AZwBzAC8AOAA5AC8AcwBsAGkAZABlAHMALwBz AGwAaQBkAGUAcwAtADgAOQAtAGEAYwBlAC0ANQAuAHAAcAB0AHgAAAAAAB8AAAABAAAAAAAAAAMA AAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAAD8AAABoAHQAdABwADoALwAvAHcAdwB3 AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAGEA YwBlAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAAzADAANwAuAGgAdABtAGwAAAAAAB8AAAAB AAAAAAAAAB4AAAD0AAAAKDMpVy9VS0pEK012bys1bUs4OFlCdVRqbHFhcjdSYUR4TGhkWlR0RklT aFk0clFtWG5QNVhIQm8wL1cyZ3NFeEtmOUpuODZwVE1DK1RZWHpuSkovVUg3QzJudlpaeEhadis4 WnZyOVcxbXZEbTZ5SjJJaUJPV1U5azMzTUQxY1ViTC9OS085WWF6QWpFSWh3TkFsQXFPZ0RaWmRu dzdQd0ZDN0lnWWQ0cW95ekpPanFLZjM1TThJMEMwdko5MXpZQzdGeUQ2dTJYL0ZnMVYwYThnS1BI NzhSSHYyaHJjbHJIOTV5NXd1M2xSTk9XUHBUTGVUAB4AAAAQAAAAX21zX3BJRF83MjUzNDMAAB4A AAD0AAAAK1JmN0l5ckhjeU5DUi83WnFiY25EZmswSWNlbDdBdW9QcU5HQ3dQaU5rSVFUSEpiSFl4 cHZBeXk1cjdWSTRUSFg4RVo1M2ttdHBncEpFN0JaUUZNL3JIT3pBZisvUHdHd0Z1UXJabmtYY2Zn VU5JZ2R0RzAyR2NrYnFlWnI3NFRNTDVrUHhpaTk4QXpMRmJUd2xpc2p5MTU4NEZ6UStzM3AvdjNP MnArVXh1OTk2TklQMTFsV3NoTnpxWGpaM1FZOGFEUWtvZTBpMkdkZ3EzemlNaEVlZnZJVlArZGhZ RWQ2bnZ2cVFsQUoyZFhtS1VhAAAAAB4AAAAQAAAAX21zX3BJRF83MjUzNDMxAB4AAAAQAAAAdUQ3 VEdRMXhNYVU9AAAAAB4AAAAQAAAAX21zX3BJRF83MjUzNDMyAB4AAAAMAAAAMTM5NDA0ODE4NgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DykA AAAUAAAAX8CR44tVAQARAPQDAwAxAEhhbm5lcyBUc2Nob2ZlbmlnCAAAAEgAYQBuAG4AZQBzACAA VABzAGMAaABvAGYAZQBuAGkAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAA ABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAA IQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAv AAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA/v///zcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0A AAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAA AEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAA WgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABo AAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYA AAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAA AIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAA kwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAACh AAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8A AACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAA AL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAA zAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADa AAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA/v///+IAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgA AADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA9gAA APcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAAABAQAAAgEAAAMBAAAEAQAA BQEAAAYBAAAHAQAACAEAAAkBAAAKAQAACwEAAAwBAAANAQAADgEAAA8BAAAQAQAAEQEAABIBAAAT AQAAFAEAABUBAAAWAQAAFwEAABgBAAAZAQAAGgEAABsBAAAcAQAAHQEAAB4BAAAfAQAAIAEAACEB AAAiAQAAIwEAACQBAAAlAQAAJgEAACcBAAAoAQAAKQEAACoBAAArAQAALAEAAC0BAAAuAQAALwEA ADABAAAxAQAAMgEAADMBAAA0AQAANQEAADYBAAA3AQAAOAEAADkBAAA6AQAAOwEAADwBAAA9AQAA PgEAAD8BAABAAQAAQQEAAEIBAABDAQAARAEAAEUBAABGAQAARwEAAEgBAABJAQAASgEAAEsBAABM AQAATQEAAE4BAABPAQAAUAEAAFEBAABSAQAA/v///1QBAABVAQAAVgEAAFcBAABYAQAAWQEAAFoB AAD+////XAEAAF0BAABeAQAAXwEAAGABAABhAQAAYgEAAP7////9/////f////3///9nAQAA/v// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdABy AHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////// //8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAUABp AGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAamoAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAFsBAAAAEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAUAAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAANTiAAAAAAAAUABvAHcAZQByAFAAbwBpAG4A dAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAr1UBAAAAAAAFAEQA bwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAA AAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFMB AAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --_004_34966E97BE8AD64EAE9D3D6E4DEE36F252B010A9SZXEMA501MBSchi_-- From nobody Fri Mar 7 00:47:42 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161241A002B for ; Fri, 7 Mar 2014 00:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLI-SqTnp2Ql for ; Fri, 7 Mar 2014 00:47:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 520131A010B for ; Fri, 7 Mar 2014 00:47:39 -0800 (PST) Received: from [192.168.10.136] ([130.129.155.192]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MTTKZ-1WniJW2TfL-00SQQI for ; Fri, 07 Mar 2014 09:47:34 +0100 Message-ID: <531987A2.10700@gmx.net> Date: Fri, 07 Mar 2014 09:47:30 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" References: <531876A0.7030301@gmx.net> In-Reply-To: <531876A0.7030301@gmx.net> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FNb7LdvxRhNf5jvJwhnPtFJPvTWm6W1hB" X-Provags-ID: V03:K0:aOWggNx+8MtrLx8qU9zhD/EpOfPqb0JNfKd2m22ymvTorJynI+r 1Irxq0dEp1yJGZaUmMYUYeUHOQMSPAbD7l749a8p1PHyv3HXhbWwnI4flYMlC+zp2O0K0bN rbYHPdZy//SmN34TZ3cvnNY+ABKSaGZmgyPuspyJH5Tdpm7Gm2vIPaGMYQsgAb3CrPrB5JV JfkRPlaH+974iCXohy+fg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/IwItmtND0ny3S8NokqG6j7F1AK4 Subject: [Ace] CORRECTION: IoT Chill-out on Friday, 8pm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 08:47:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FNb7LdvxRhNf5jvJwhnPtFJPvTWm6W1hB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Based on the feedback from various persons I would suggest to gather a bit later, namely 8pm instead of 5pm as previously proposed. Ciao Hannes On 03/06/2014 02:22 PM, Hannes Tschofenig wrote: > Hi all, >=20 > I was wondering whether some of you are still around on Friday > afternoon. In case there is interest to have a relaxed chat (maybe with= > a drink) with IoT-minded persons I would suggest to gather in the Hilto= n > hotel bar at 5pm. >=20 > Feel free to forward the message to other IoT-related groups. >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --FNb7LdvxRhNf5jvJwhnPtFJPvTWm6W1hB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTGYejAAoJEGhJURNOOiAtKxMH/12ulH/tym/RZ9B0oSIAsyqH 5SLwnI+5YBuqyl35wzLI1hk72IuVgH5BPciPP32lYdMSFut6180XouAokgjrpA/9 FwWeb1gywSsV7Jb8KiG7yTyfKMnuaE4VsGr4Jr3/1a2uo8pTsAYf4Bg6WUiRZEKp +rVfq1cVShY4vWXcStjKHXPD6wQNgBtDOGsP08rz8Qfxh3b5fV2JGOfdkfAgUhDN ZoT5Suh+RtEZv5GuQ4hDpiHbkS7z2Tn6oETuKBENUL0aksp6cOjrlL4YlReMDXTk j3qGy3SYpdptoQHXI64Wr/cJiLVm8WEazl4UOxTM5jNpkbbAr3XfMe4yUKW4Rf0= =kGNN -----END PGP SIGNATURE----- --FNb7LdvxRhNf5jvJwhnPtFJPvTWm6W1hB-- From nobody Fri Mar 7 01:05:55 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF191A0255 for ; Fri, 7 Mar 2014 01:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwWNb4KMw2_n for ; Fri, 7 Mar 2014 01:05:53 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 869911A016A for ; Fri, 7 Mar 2014 01:05:53 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-8f-53198bec0b1c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CC.4F.04249.CEB89135; Fri, 7 Mar 2014 10:05:48 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Fri, 7 Mar 2014 10:05:48 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "ace@ietf.org" Thread-Topic: CNN input to TLS 1.3 Thread-Index: AQHPOeRu8LREXBvyh0CxaBWLUmagFQ== Date: Fri, 7 Mar 2014 09:05:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3ADAD13888212A44BDD4486F71FAF042@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje6bbslggzUbjCy+f+thdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrsNTxgLbjJVdG9oYm5g7GLqYuTgkBAwkZizKryLkRPIFJO4 cG89G4gtJHCEUeL6Jd4uRi4gezGjxJYXl5lAEmwCrhIHHrwD6xURUJS4/igRJCwsICvx8/0/ RhBbREBJ4sbUzWwQtp7EtF3vwOIsAioSj878BLN5BcwltratYAGxGYH2fj+1Bmw8s4C4xK0n 85kg7hGQWLLnPDOELSrx8vE/VhBbFGjmvUdzWSDiShKNS56wQvTqAe2dwgZhW0tMuruDBcLW lli28DUzxF5BiZMzn7BMYBSdhWTdLCTts5C0z0LSPgtJ+wJG1lWMHMWpxUm56UYGmxiB0XBw y2+LHYyX/9ocYpTmYFES5/341jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6cUMPRXmt24vok5 5+iKPq3+va9bpk2veSnj/6d98tn88L33X2j42u+/GCeQd2S322ozJ6kpTtFrOvRvPYng1yov +Bf2z84/X761dGqXhoqOwfny3DPrjmy3OrrTYbGal983w2j/IO6XOrw/7ssqLOM65B/dufk1 h9Ua/mp+5dSEVGWzewuuBn8TVWIpzkg01GIuKk4EAFwXqwRUAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/X4mF_EuNPJ1nIhywxCVfaC_tDMs Subject: [Ace] CNN input to TLS 1.3 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:05:54 -0000 Hi IoT security fans Has there been any work on compiling input to TLS 1.3 from constrained node networks point of view? If there is anyone still at the Hilton who is interested about this and care to discuss it I=B9ll be in the "IETF lounge=B2 (East Wing 2nd Lower Ground Floor) from 9.30 and on for some time. Thanks G=F6ran From nobody Fri Mar 7 02:42:46 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7421A00DC for ; Fri, 7 Mar 2014 02:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlgqINBQDzj6 for ; Fri, 7 Mar 2014 02:42:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8397E1A0079 for ; Fri, 7 Mar 2014 02:42:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEI25833; Fri, 07 Mar 2014 10:42:36 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Mar 2014 10:42:02 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Mar 2014 10:42:35 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Fri, 7 Mar 2014 18:42:29 +0800 From: Likepeng To: Zach Shelby , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= Thread-Topic: [Ace] Scope of the ACE Charter Thread-Index: AQHPOH/FaDU9crAJNUG+lhDmAkHArJrSSMQAgAADZACAAieowA== Date: Fri, 7 Mar 2014 10:42:28 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B013F9@SZXEMA501-MBS.china.huawei.com> References: <5317357B.6020407@gmx.net> <5C0365A6-995F-4500-8147-DDD35CD43EA0@arm.com> In-Reply-To: <5C0365A6-995F-4500-8147-DDD35CD43EA0@arm.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.90.220] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/rR9aBEL0N6gxHg1kjDObCrv8JDU Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:42:45 -0000 SGkgWmFjaCwNCg0KPkkgdGhpbmsgdGhhdCBvbiBhbnkgb25lIG9mIHRob3NlIGludGVyZmFjZXMg ZWl0aGVyIENvQVAvRFRMUyBvciBIVFRQL1RMUyBjb3VsZCBiZSB1c2VkIGRlcGVuZGluZyBvbiB0 aGUgbm9kZSBhbmQgbmV0d29yay4gKGlpKSB3aWxsIHR5cGljYWxseSBiZSBDb0FQL0RUTFMgYXMg dGhpcyBpcyB0aGUgd2hvbGUgcG9pbnQgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIChpKSBhbmQgcG9z c2libHkgKGlpaSkgY291bGQgYmUgZWl0aGVyLg0KDQpJIGFtIG5vdCBzdXJlIHdoeSAoaWkpIGFu ZCAoaWlpKSBhcmUgdHJlYXRlZCBkaWZmZXJlbnRseS4gSSB3b3VsZCBhc3N1bWUgdGhhdCBSZXNv dXJjZSBTZXJ2ZXIgaXMgY29uc3RyYWluZWQsIHRoZW4gKGlpaSkgc2hvdWxkIGFsc28gdHlwaWNh bGx5IGJlIENvQVAvRFRMUyB0b28uDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCi0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5v cmddIOS7o+ihqCBaYWNoIFNoZWxieQ0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0M+aciDXml6UgMTg6 MzUNCuaUtuS7tuS6ujogR8O2cmFuIFNlbGFuZGVyDQrmioTpgIE6IEhhbm5lcyBUc2Nob2Zlbmln OyBhY2VAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtBY2VdIFNjb3BlIG9mIHRoZSBBQ0UgQ2hhcnRl cg0KDQpIaSwNCg0KT25lIG9mIHRoZSAib3RoZXIiIHRoaW5ncyBtZW50aW9uZWQgd2FzIFNNUywg YnV0IHRoYXQgd2FzIGp1c3QgYSBtaXN1bmRlcnN0YW5kaW5nLiBUaGV5IHdlcmUgbG9va2luZyBm b3IgRFRMUyBzdXBwb3J0IGZvciBTTVMsIHdoaWNoIHdvdWxkIGJlIHNvbWV0aGluZyBmb3IgdGhl IFRMUyB3b3JraW5nIGdyb3VwIGFuZCBub3QgQUNFLiBBbmQgd2l0aCBzdWNoIHN1cHBvcnQsIG9m IGNvdXJzZSB0aGF0IGlzIENvQVAvRFRMUy4gU28gbm8gaXNzdWVzIG9uIHRoYXQgb25lLg0KDQpJ IHRoaW5rIHRoYXQgb24gYW55IG9uZSBvZiB0aG9zZSBpbnRlcmZhY2VzIGVpdGhlciBDb0FQL0RU TFMgb3IgSFRUUC9UTFMgY291bGQgYmUgdXNlZCBkZXBlbmRpbmcgb24gdGhlIG5vZGUgYW5kIG5l dHdvcmsuIChpaSkgd2lsbCB0eXBpY2FsbHkgYmUgQ29BUC9EVExTIGFzIHRoaXMgaXMgdGhlIHdo b2xlIHBvaW50IG9mIHRoZSB3b3JraW5nIGdyb3VwLiAoaSkgYW5kIHBvc3NpYmx5IChpaWkpIGNv dWxkIGJlIGVpdGhlci4NCg0KQmVpbmcgdGhlIG9uZSB0aGF0IGJyb3VnaHQgdXAgdGhlICJwcm94 eSIgaXNzdWUsIEkgcHJvYmFibHkgdXNlZCBhIHJlYWxseSBwb29yIGNob2ljZSBvZiB3b3JkcyB0 aGVyZS4gV2hhdCBJIHJlYWxseSBtZWFudCB3YXMgdGhpcyBkdWFsaXR5IG9mIGFuIEhUVFAvVExT IGJhc2VkIHNvbHV0aW9uIChPQXV0aCkgb3IgYSBDb0FQL0RUTFMgc29sdXRpb24gb24gdGhvc2Ug aW50ZXJmYWNlcywgYnV0IGNob29zZSBvbmUgYW5kIHJ1biBpdCBlbmQtdG8tZW5kLg0KDQpaYWNo DQoNCk9uIE1hciA1LCAyMDE0LCBhdCA2OjIzIFBNLCBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNl bGFuZGVyQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj4gSGkgSGFubmVzLA0KPg0KPg0KPiBKdXN0 IGxvb2tpbmcgYXQgaW50ZXJmYWNlIChJKTogSWYgdGhlIGNsaWVudCBpcyBub3QgY29uc3RyYWlu ZWQgSSANCj4gdGhpbmsgSFRUUC9UTFMgc2hvdWxkIGJlIGFuIG9wdGlvbiB0byBDT0FQL0RUTFMu DQo+DQo+IEFkZGluZyB0byB0aGUgZGlzY3Vzc2lvbiBhYm91dCBIVFRQL0NPQVAgcHJveGllcyBp biB0aGUgbWVldGluZzogSWYgDQo+IGJvdGggdGhlIGF1dGhvcmlzYXRpb24gaW5mb3JtYXRpb24g YW5kIHRoZSBrZXlpbmcgaW5mb3JtYXRpb24gaXMgDQo+IG9iamVjdCBzZWN1cmUgKEpXVCwgQ01T LCDFoCkgdGhlcmUgaXMgbm8gbmVlZCB0byB0cnVzdCB0aGUgcHJveHkuDQo+DQo+IEfDtnJhbg0K Pg0KPiBPbiAwNS8wMy8xNCAxNDozMiwgIkhhbm5lcyBUc2Nob2ZlbmlnIiA8aGFubmVzLnRzY2hv ZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQo+DQo+PiBIaSBhbGwsDQo+Pg0KPj4gSSB3b3VsZCBsaWtl IHRvIHRoYW5rIHlvdSBhbGwgZm9yIHRoZSBncmVhdCBkaXNjdXNzaW9uIHRvZGF5IGF0IHRoZSBC T0YuDQo+PiBUaGVyZSB3YXMgZ29vZCBmZWVkYmFjayBhbmQgdGhlIGZvbGxvd2luZyBzY29waW5n IGFzcGVjdCBzaG93ZWQgdXAuDQo+Pg0KPj4gSW4gYSBudXRzaGVsbCB0aGVyZSB3YXMgc29tZSBk aXNhZ3JlZW1lbnQgdG8gcHVyZWx5IGZvY3VzIG9uIA0KPj4gQ29BUC9EVExTIGFzIHBhcnQgb2Yg YSBmdXR1cmUgd29ya2luZyBncm91cC4NCj4+DQo+PiBUaGVyZSB3YXMgbm90IGVub3VnaCB0aW1l IHRvIGdvIGRvd24gdG8gdGhlIGRldGFpbHMgZHVyaW5nIHRoZSANCj4+IHNlc3Npb24gZHVlIHRv IGxhY2sgb2YgdGltZS4gSGVuY2UsIEkgd2lsbCB0cnkgdG8gY2xhcmlmeSB0aGlzIGFzcGVjdCAN Cj4+IG9uIHRoZSBtYWlsaW5nIGxpc3QuDQo+Pg0KPj4gTGV0IHVzIGhhdmUgYSBsb29rIGF0IHRo ZSBoaWdoIGxldmVsIGFyY2hpdGVjdHVyZToNCj4+DQo+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IEF1dGhvcml6YXRpb24gfA0KPj4gICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgIFNlcnZlciAgICAgICB8DQo+PiAgICAgICAg ICAgIHwgICAgICAgIChJKSAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCj4+ICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQo+PiAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IElJSQ0KPj4gICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KPj4gICAgICAgICAgICB2ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHYNCj4+ICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAg ICArLS0tLS0rLS0tLS0rDQo+PiAgICAgICB8ICAgICAgICAgICB8ICAgICAgSUkgICAgICAgICAg ICAgfCBSZXNvdXJjZSAgfA0KPj4gICAgICAgfCAgIENsaWVudCAgfCA8Li4uLi4uLi4uLi4uLi4u Li4uPnwgU2VydmVyICAgIHwNCj4+ICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0rDQo+Pg0KPj4gSTogVGhpcyBpcyB0aGUgaW50ZXJhY3Rpb24gd2hl cmUga2V5aW5nIGFuZCBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIA0KPj4gaXMgcHJvdmlkZWQg dG8gdGhlIGNsaWVudC4NCj4+DQo+PiBJSTogVGhpcyBpcyB0aGUgcmVzb3VyY2UgYWNjZXNzLg0K Pj4NCj4+IElJSTogVGhpcyBpcyBhIHBvdGVudGlhbCBleGNoYW5nZSBuZWNlc3NhcnkgZm9yIGhh dmluZyB0aGUgcmVzb3VyY2UgDQo+PiBzZXJ2ZXIgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW5nIA0KPj4gdGhlIGNsaWVudCBhbmQgZm9y IGF1dGhvcml6aW5nIHRoZSBjbGllbnQuDQo+Pg0KPj4gKFRoZSBleGFjdCBkZXRhaWxzIG9mIHRo ZSBpbnRlcmFjdGlvbiBkZXBlbmQgb24gdGhlIHNwZWNpZmljIA0KPj4gc29sdXRpb24sIG9mIGNv dXJzZS4pDQo+Pg0KPj4gQXMgeW91IGNhbiBzZWUgaW4gdGhlIGZpZ3VyZSwgdGhlcmUgYXJlIHZh cmlvdXMgcGxhY2VzIHdoZXJlIERUTFMgYW5kIA0KPj4gQ29BUCBzaG91bGQgb3Igc2hvdWxkbid0 IGJlIHVzZWQuDQo+Pg0KPj4gQSBmZXcgcGVyc29ucyBzYWlkIHRoYXQgdGhleSB3YW50IHRvIHVz ZSBvdGhlciBwcm90b2NvbHMgYmVzaWRlcyBDb0FQIA0KPj4gYW5kIERUTFMuDQo+Pg0KPj4gUGxl YXNlIGV4cGxhaW4gbWUgd2hlcmUgeW91IHdvdWxkIGxpa2UgdG8gb3RoZXIgcHJvdG9jb2xzIGJl aW5nIHRha2VuIA0KPj4gaW50byBjb25zaWRlcmF0aW9uLiBXaGF0IHByb3RvY29scyBhcmUgeW91 IGNvbnNpZGVyaW5nIGluIHdoaWNoIG9mIA0KPj4gdGhlc2UgaW50ZXJmYWNlcz8NCj4+DQo+PiBD aWFvDQo+PiBIYW5uZXMNCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEFjZSBtYWlsaW5nIGxpc3QNCj4gQWNlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+DQoNClphY2ggU2hlbGJ5 DQpEaXJlY3RvciBvZiBUZWNobm9sb2d5DQpBUk0gSW50ZXJuZXQgb2YgVGhpbmdzIEJVDQp3d3cu YXJtLmNvbQ0KbW9iaWxlOiArMSAoNDA4KSAyMDMtOTQzNA0KU2t5cGU6IHpkc2hlbGJ5DQpMaW5r ZWRJbjogZmkubGlua2VkaW4uY29tL2luL3phY2hzaGVsYnkvDQoNCg0KLS0gSU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwg dXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IG1lZGl1bS4gIFRoYW5rIHlvdS4NCg0KQVJNIExpbWl0ZWQsIFJlZ2lzdGVyZWQgb2Zm aWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0ZXJlZCBpbiBF bmdsYW5kICYgV2FsZXMsIENvbXBhbnkgTm86ICAyNTU3NTkwIEFSTSBIb2xkaW5ncyBwbGMsIFJl Z2lzdGVyZWQgb2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVn aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMsIENvbXBhbnkgTm86ICAyNTQ4NzgyDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBs aXN0DQpBY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWNlDQo= From nobody Fri Mar 7 02:54:00 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6C1A00DC for ; Fri, 7 Mar 2014 02:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swn2q9NGZ7wu for ; Fri, 7 Mar 2014 02:53:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id ABD821A006F for ; Fri, 7 Mar 2014 02:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s27Arout022387; Fri, 7 Mar 2014 11:53:50 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 13163D46; Fri, 7 Mar 2014 11:53:49 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <5317357B.6020407@gmx.net> Date: Fri, 7 Mar 2014 10:53:48 +0000 X-Mao-Original-Outgoing-Id: 415882428.687284-872093489634c7620a29a53f3180d82c Content-Transfer-Encoding: quoted-printable Message-Id: References: <5317357B.6020407@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/dMgNrnh8nuRDirZGc3V6aTElcMM Cc: "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:53:58 -0000 On 05 Mar 2014, at 14:32, Hannes Tschofenig = wrote: > In a nutshell there was some disagreement to purely focus on CoAP/DTLS > as part of a future working group. Yes, and (for some reason I don=92t understand) nobody said aloud why = that focus might be a problem (while, e.g., Sam very clearly said why = *not* having that focus might be a problem). It seems to me there is a false choice being presented here. If we define a solution that is good for CoAP/DTLS, we would actively = have to go out of our way to make that useless for HTTP/TLS. So the legacy SEP2.0*) support that seems to be the issue behind this = disagreement can easily be accommodated without the WG losing its focus. Gr=FC=DFe, Carsten *) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP, = TLS, TCP. From nobody Fri Mar 7 03:00:21 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B883B1A0170 for ; Fri, 7 Mar 2014 03:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylKOLAxAk3A7 for ; Fri, 7 Mar 2014 03:00:13 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E87661A00DC for ; Fri, 7 Mar 2014 03:00:12 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id y10so4766512wgg.25 for ; Fri, 07 Mar 2014 03:00:08 -0800 (PST) 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; bh=nUODSdCukLKd94+Gj7ChpBtYu5S7bfsynTRNyIY+9CM=; b=jcIcOUTNVGeO8ihCUxzAgffahXZY4uyrfLUJS0Mh4H+rlnu1lK+5Wn/91VZBlh/wUS nG/ZWk7nBCWO5FvduP273TFw5uwaw9ZH/eJjlSyb+FGmGT3tgKtiVOpykGPaf+eMPWHQ la3fqRIslBARFUsMMn0iOjGnCxXuJKTOFUS/XTYjsUdKrJ58pcWQfxYw+z2XrOH0wPID sjA3DMOR+jA2md38hdppZEji8p3wEX2aybdSLuzAqHF+i/XGSw50g0GTJB+C3gHptfMp b+NtBrwFzGYg+yGa4v2M8cR6Hi0o3/aZ7tejeOLkQJu6b20sgOeiSFImCuzxIU0qm2GE yEsg== X-Received: by 10.194.91.232 with SMTP id ch8mr17960350wjb.13.1394190008103; Fri, 07 Mar 2014 03:00:08 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:c46a:1730:6338:20ec? ([2001:67c:370:160:c46a:1730:6338:20ec]) by mx.google.com with ESMTPSA id q15sm7703242wjw.18.2014.03.07.03.00.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 03:00:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Fri, 7 Mar 2014 11:00:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> References: <5317357B.6020407@gmx.net> To: Carsten Bormann Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0hrkFY0CyqAj3QqMIqPeoEODwXc Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:00:16 -0000 > On Mar 7, 2014, at 10:53 AM, Carsten Bormann wrote: >=20 >> On 05 Mar 2014, at 14:32, Hannes Tschofenig w= rote: >>=20 >> In a nutshell there was some disagreement to purely focus on CoAP/DTLS >> as part of a future working group. >=20 > Yes, and (for some reason I don=E2=80=99t understand) nobody said aloud wh= y that focus might be a problem (while, e.g., Sam very clearly said why *not= * having that focus might be a problem). >=20 > It seems to me there is a false choice being presented here. >=20 > If we define a solution that is good for CoAP/DTLS, we would actively have= to go out of our way to make that useless for HTTP/TLS. Where is that conclusion assured in the ACE charter or otherwise documented?= >=20 > So the legacy SEP2.0*) support that seems to be the issue behind this disa= greement can easily be accommodated without the WG losing its focus. By "legacy" do you mean "not part of a walled garden"? - Ralph >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > *) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP, TLS, T= CP. >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Fri Mar 7 03:07:22 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8A31A01F5 for ; Fri, 7 Mar 2014 03:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7dqYe2bd_Wh for ; Fri, 7 Mar 2014 03:07:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 71B6C1A019F for ; Fri, 7 Mar 2014 03:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s27B79m9018036; Fri, 7 Mar 2014 12:07:09 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 923D5D62; Fri, 7 Mar 2014 12:07:08 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> Date: Fri, 7 Mar 2014 11:07:06 +0000 X-Mao-Original-Outgoing-Id: 415883226.796039-0bca18065e91e5ea8da6d38333efcf0a Content-Transfer-Encoding: quoted-printable Message-Id: <84151D19-6A9E-4449-B6D0-F9EF53916E42@tzi.org> References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Ng5Yf9EMgVc9B6wtv6xx5v952mo Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:07:21 -0000 On 07 Mar 2014, at 11:00, Ralph Droms wrote: >> If we define a solution that is good for CoAP/DTLS, we would actively = have to go out of our way to make that useless for HTTP/TLS. >=20 > Where is that conclusion assured in the ACE charter or otherwise = documented? We indeed have to add that consideration. (It was not part of the feedback that led to the current charter draft.) >> So the legacy SEP2.0*) support that seems to be the issue behind this = disagreement can easily be accommodated without the WG losing its focus. >=20 > By "legacy" do you mean "not part of a walled garden=94? No, legacy as in =93inherited=94. This profile is out there, so we can=92t ignore it, even if we wanted = to. Gr=FC=DFe, Carsten From nobody Fri Mar 7 03:11:41 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41F21A019F for ; Fri, 7 Mar 2014 03:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MSGID_FROM_MTA_HEADER=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0dB2LqBYCT9 for ; Fri, 7 Mar 2014 03:11:33 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2D01A1A0233 for ; Fri, 7 Mar 2014 03:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s27BB7qN026582; Fri, 7 Mar 2014 12:11:07 +0100 (CET) Message-Id: <201403071111.s27BB7qN026582@informatik.uni-bremen.de> Received: from [31.133.164.94] (dhcp-a45e.meeting.ietf.org [31.133.164.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AEDADD66; Fri, 7 Mar 2014 12:11:07 +0100 (CET) Date: Fri, 07 Mar 2014 11:11:06 +0000 From: Stefanie Gerdes To: Likepeng MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/deB_Jx4z2mrTY8X89Y_wWrFZUm0 Cc: Hannes Tschofenig , Zach Shelby , =?ISO-8859-1?Q?G=F6ran_Selander?= , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:11:40 -0000 SGkgYWxsLAoKbWF5YmUgaXQgaGVscHMgdG8gZGlzY3VzcyB1c2luZyB0aGUgZGlmZmVyZW50IHJv bGVzIGEgZGV2aWNlIG1pZ2h0IGhhdmUuClRoaXMgbWlnaHQgbWFrZSB0aGUgZGlzY3Vzc2lvbiBh IGJpdCBlYXNpZXIgYmVjYXVzZSB3ZSBrbm93IGF0IGVhY2ggcG9pbnQgaWYgd2UgYXJlIHRhbGtp bmcgYWJvdXQgYSBjb25zdHJhaW5lZCBkZXZpY2Ugb3Igbm90LgoKSW4gbXkgdW5kZXJzdGFuZGlu ZyB3ZSBoYXZlIGZvdXIgcm9sZXM6IHRoZSBjbGllbnQgYW5kIHJlc291cmNlIHNlcnZlciB3aGlj aCBhcmUgY29uc3RyYWluZWQgYW5kIHRoZSAid2lzZSBlbGRlcnMiIHdoaWNoIGFyZSB1bmNvbnN0 cmFpbmVkLiBBIGRldmljZSBoYXMgb25lIG9yIG1vcmUgcm9sZXMuCgpBIGNsaWVudCBtaWdodCBh dCB0aGUgc2FtZSB0aW1lIGJlIHRoZSBBdXRob3JpemF0aW9uIE1hbmFnZXIgYW5kIHdpbGwgdGhl biBiZSBhIGxlc3MtY29uc3RyYWluZWQgZGV2aWNlLiBUaGUgUmVzb3VyY2UgU2VydmVyIG1pZ2h0 IGF0IHRoZSBzYW1lIHRpbWUgYmUgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLgoKUm9sZXM6Cgo+ ID4+Cj4gPj7CoMKgwqDCoMKgKy0tLS0tLS0tLS0tLS0tLSsgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCDCoCArLS0tLS0tLS0tLS0tLS0tKyAKPiA+PsKgwqDCoMKgQXV0aG9yaXph dGlvbsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCBBdXRob3JpemF0aW9uIHwg Cj4gPj7CoMKgwqDCoMKgTWFuYWdlcsKgICstLS0tLS0tLS0tLS0tLS0tPnzCoCBTZXJ2ZXLCoMKg wqDCoMKgwqAgfCAKPiA+PsKgwqDCoMKgKy0tLS0tLS0tLS0tLS0tLSsgwqDCoCAoSS4yKcKgwqDC oMKgwqDCoMKgwqDCoCArLS0tLS0tLS0tLS0tLS0tKyAKPiA+PsKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBeIAo+ID4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwg Cj4gPj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCAKPiA+PsKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfMKgwqAoSS4xKSDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHwgSUlJIAo+ID4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHwgCj4gPj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCAKPiA+PsKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IAo+ID4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHYgCj4gPj7CoMKgwqDCoMKgwqAgKy0tLS0tLS0tLS0tK8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tKy0tLS0tKyAKPiA+PsKgwqDCoMKgwqDC oCB8wqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqAgSUnCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfCBSZXNvdXJjZcKgIHwgCj4gPj7CoMKgwqDCoMKgwqAgfMKgwqAgQ2xpZW50wqAgfCA8 Li4uLi4uLi4uLi4uLi4uLi4uPnwgU2VydmVywqDCoMKgIHwgCj4gPj7CoMKgwqDCoMKgwqAgKy0t LS0tLS0tLS0tK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0t LS0tLS0tKwoKPiA+PiAKPiA+PiBJOiBUaGlzIGlzIHRoZSBpbnRlcmFjdGlvbiB3aGVyZSBrZXlp bmcgYW5kIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24KSS4xOiBiZXR3ZWVuIGEgY29uc3RyYWlu ZWQgZGV2aWNlcyBhbmQgaXRzICJ3aXNlIGVsZGVyIgpJLjI6IGJldHdlZW4gdGhlIGxlc3MtY29u c3RyYWluZWQgZGV2aWNlcyBiZWxvbmdpbmcgdG8gZGlmZmVyZW50IHNlY3VyaXR5IGRvbWFpbnMK Cj4gPj4gaXMgcHJvdmlkZWQgdG8gdGhlIGNsaWVudC4gCj4gPj4gCj4gPj4gSUk6IFRoaXMgaXMg dGhlIHJlc291cmNlIGFjY2Vzcy4gCj4gPj4gCj4gPj4gSUlJOiBUaGlzIGlzIGEgcG90ZW50aWFs IGV4Y2hhbmdlIG5lY2Vzc2FyeSBmb3IgaGF2aW5nIHRoZSByZXNvdXJjZSAKPiA+PiBzZXJ2ZXIg aW50ZXJhY3Rpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0 aW5nIAo+ID4+IHRoZSBjbGllbnQgYW5kIGZvciBhdXRob3JpemluZyB0aGUgY2xpZW50LiAKPiA+ PiAKPiA+PiAoVGhlIGV4YWN0IGRldGFpbHMgb2YgdGhlIGludGVyYWN0aW9uIGRlcGVuZCBvbiB0 aGUgc3BlY2lmaWMgCj4gPj4gc29sdXRpb24sIG9mIGNvdXJzZS4pIAo+ID4+IAo+ID4+IEFzIHlv dSBjYW4gc2VlIGluIHRoZSBmaWd1cmUsIHRoZXJlIGFyZSB2YXJpb3VzIHBsYWNlcyB3aGVyZSBE VExTIGFuZCAKPiA+PiBDb0FQIHNob3VsZCBvciBzaG91bGRuJ3QgYmUgdXNlZC4gCj4gPj4gCj4g Pj4gQSBmZXcgcGVyc29ucyBzYWlkIHRoYXQgdGhleSB3YW50IHRvIHVzZSBvdGhlciBwcm90b2Nv bHMgYmVzaWRlcyBDb0FQIAo+ID4+IGFuZCBEVExTLiAKPiA+PiAKPiA+PiBQbGVhc2UgZXhwbGFp biBtZSB3aGVyZSB5b3Ugd291bGQgbGlrZSB0byBvdGhlciBwcm90b2NvbHMgYmVpbmcgdGFrZW4g Cj4gPj4gaW50byBjb25zaWRlcmF0aW9uLiBXaGF0IHByb3RvY29scyBhcmUgeW91IGNvbnNpZGVy aW5nIGluIHdoaWNoIG9mIAo+ID4+IHRoZXNlIGludGVyZmFjZXM/IAo+ID4+CgpCZXN0IFJlZ2Fy ZHMsClN0ZWZmaQo= From nobody Fri Mar 7 03:24:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514D71A029E for ; Fri, 7 Mar 2014 03:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc_KK5jqs5_V for ; Fri, 7 Mar 2014 03:24:50 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6696D1A01E0 for ; Fri, 7 Mar 2014 03:24:50 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id a1so423132wgh.8 for ; Fri, 07 Mar 2014 03:24:45 -0800 (PST) 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; bh=uLWmpA7EE3nFCo/t7UoCfqAcPlSeLtlE5vSMEFw0z8U=; b=V6tb2Lu8ZUkONpkBo/6G45QHTdasZ/Wwc+LeKCUbqVc6YWSDsDMpmrStPYUTe7TpPt GiVwI5tmed8oOoYPyhhbplxPlPGnfB9ZV5F9Jx6V+Ndq86utvv3mBOaqMunKj4EUT2+p N/czxrYnCRftheoWVpLZzXqPBp1ypoPezILha6gbKonRfcR+bi1MR7hw62d1iCK/+B7C u/WIBVVDHOqQQp4Fw3OzMDHHDQGPWw84iCig+MI2CvHetCX7E3ZiR3LqIihZSCUvHNyN 2ybcHXV9skBf20ZD8OVBVR3myv5KAHjMDa7x3fXy+qNKWaFnfzFrMLliZjOTlN+PGl0/ 5JIg== X-Received: by 10.194.190.10 with SMTP id gm10mr18192495wjc.55.1394191485782; Fri, 07 Mar 2014 03:24:45 -0800 (PST) Received: from [31.133.167.24] (dhcp-a718.meeting.ietf.org. [31.133.167.24]) by mx.google.com with ESMTPSA id r3sm8073336wjw.0.2014.03.07.03.24.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 03:24:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPad Mail (11B651) In-Reply-To: <5317357B.6020407@gmx.net> Date: Fri, 7 Mar 2014 11:24:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> References: <5317357B.6020407@gmx.net> To: Hannes Tschofenig Archived-At: http://mailarchive.ietf.org/arch/msg/ace/9MMyXj_nWtgEUwUJvoJn8FumAmE Cc: "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:24:52 -0000 Hannes - I don't think I can answer your question as you've posed it. COAP/= DTLS might or might not be used across any of these interactions. It really= depends on the specific applications and deployment scenario - including co= nsiderations like scope of intended participants, interest in reusing existi= ng deployed code, existence of gateways, etc. - Ralph > On Mar 5, 2014, at 2:32 PM, Hannes Tschofenig w= rote: >=20 > Hi all, >=20 > I would like to thank you all for the great discussion today at the BOF. > There was good feedback and the following scoping aspect showed up. >=20 > In a nutshell there was some disagreement to purely focus on CoAP/DTLS > as part of a future working group. >=20 > There was not enough time to go down to the details during the session > due to lack of time. Hence, I will try to clarify this aspect on the > mailing list. >=20 > Let us have a look at the high level architecture: >=20 > +---------------+ > | Authorization | > +--------------------------->| Server | > | (I) +---------------+ > | ^ > | | > | | > | | III > | | > | | > | | > v v > +-----------+ +-----+-----+ > | | II | Resource | > | Client | <..................>| Server | > +-----------+ +-----------+ >=20 > I: This is the interaction where keying and authorization information is > provided to the client. >=20 > II: This is the resource access. >=20 > III: This is a potential exchange necessary for having the resource > server interacting with the authorization server for authenticating the > client and for authorizing the client. >=20 > (The exact details of the interaction depend on the specific solution, > of course.) >=20 > As you can see in the figure, there are various places where DTLS and > CoAP should or shouldn't be used. >=20 > A few persons said that they want to use other protocols besides CoAP > and DTLS. >=20 > Please explain me where you would like to other protocols being taken > into consideration. What protocols are you considering in which of these > interfaces? >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Fri Mar 7 03:25:20 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48B1A01EF for ; Fri, 7 Mar 2014 03:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcZY7PuGQ1OM for ; Fri, 7 Mar 2014 03:25:15 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8FB1A02A4 for ; Fri, 7 Mar 2014 03:25:13 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-32-5319ac94d7f6 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E4.26.04249.49CA9135; Fri, 7 Mar 2014 12:25:09 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.347.0; Fri, 7 Mar 2014 12:25:07 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CB39C1101FA for ; Fri, 7 Mar 2014 13:25:07 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 92A9656BE6 for ; Fri, 7 Mar 2014 13:25:02 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 43D2856BE5 for ; Fri, 7 Mar 2014 13:25:02 +0200 (EET) Message-ID: <5319AC92.4010203@ericsson.com> Date: Fri, 7 Mar 2014 13:25:06 +0200 From: Mohit Sethi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: References: <52FC8838.6060707@ericsson.com> In-Reply-To: <52FC8838.6060707@ericsson.com> X-Forwarded-Message-Id: <52FC8838.6060707@ericsson.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvje7UNZLBBj9usVl8/9bD7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNnv3jAVLBerOHj6ElMD41XBLkZODgkBE4m2SQ0sELaYxIV7 69m6GLk4hASOMEp8eNzOCJIQEljPKLFqiR1E4jyjxOEPh1khnAOMEgtutkG1bGSUuDDnHtgs XgFtiWl7l4O1swioSDTP6mEFsdkE9CQ6zx1nBrFFBcIk7v5fywhRLyhxcuYTsF4RASGJ6x3L wOqFBYIkvh05CFTDAbRAW+L8j3CQMKeAjsSCi7/ZQcISAuYS7RO4QcLMAhYSi98cZIew5SW2 v53DDPGZmsTVc5uYIZ5Rl9jacYBxAqPoLCSLZyFpn4WkfQEj8ypGjuLU4qTcdCODTYzAED+4 5bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHBmSwGqRKb he1Gq/c+Ul3fa/lRweJf8b0DJ6eyaSeqzDvMzDDv+M1uja/1E/h6pu/cJ/zs1eMfO287F/V0 vWP1W31scvD0fXVT2hZc7svUuZXsqn/mGf9cp+J0v985t/ZK9r0ozNuWINR0dVbVxYyyO4wr /f9ni+q9OKvzZStbptd1s7fTpj1TYinOSDTUYi4qTgQAWdgkzz8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Ev993IOk2I0b-f9OcN-A3og7Fhk Subject: [Ace] Fwd: Fwd: New Version Notification for draft-sethi-gba-constrained-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:25:18 -0000 Hi folks The chairs of LWIG asked me to submit the draft on GBA implementation guidance to ACE for feedback. While I agree with Hannes that the need for SIM cards might be a show stopper, any feedback is more than welcome. --Mohit -------- Original Message -------- Subject: Fwd: New Version Notification for draft-sethi-gba-constrained-01.txt Date: Thu, 13 Feb 2014 10:54:16 +0200 From: Mohit Sethi To: lwip@ietf.org Hi We have submitted a new draft on implementation experiences and guidelines for using Generic Bootstrapping Architecture (GBA) as a bootstrapping mechanism for Constrained devices. We have the necessary 3GPP interfaces (NAF/BSF) for experimentation running on our public server (p133.piuha.net). Feel free to try it out with your own implementation. Comments on the draft are welcome! --Mohit -------- Original Message -------- Subject: New Version Notification for draft-sethi-gba-constrained-01.txt Date: Thu, 13 Feb 2014 00:42:19 -0800 From: To: Vesa Lehtovirta , Patrik Salmela , Vesa Lehtovirta , Mohit Sethi , Mohit Sethi , Patrik Salmela A new version of I-D, draft-sethi-gba-constrained-01.txt has been successfully submitted by Mohit Sethi and posted to the IETF repository. Name: draft-sethi-gba-constrained Revision: 01 Title: Using Generic Bootstrapping Architecture with Constrained Devices Document date: 2014-02-13 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-sethi-gba-constrained-01.txt Status: https://datatracker.ietf.org/doc/draft-sethi-gba-constrained/ Htmlized: http://tools.ietf.org/html/draft-sethi-gba-constrained-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-sethi-gba-constrained-01 Abstract: This document discusses the use of the 3GPP Generic Bootstrapping Architecture (GBA) for authenticating and securing constrained devices. While GBA re-uses the 3GPP credentials, it does not require mobile network access, such as LTE, but requires only IP connectivity. Though building devices that employ GBA is obviously well known, this document specifically focuses on techniques necessary to minimize memory and energy consumption which is essential for constrained device networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Mar 7 03:27:03 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4867B1A02AC for ; Fri, 7 Mar 2014 03:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrdkqlcfolTm for ; Fri, 7 Mar 2014 03:26:59 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id ED93E1A0256 for ; Fri, 7 Mar 2014 03:26:58 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s27BQoh0027116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Mar 2014 11:26:50 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s27BQm1u008328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Mar 2014 11:26:49 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s27BQmX8023158; Fri, 7 Mar 2014 11:26:48 GMT Received: from [192.168.101.208] (/85.133.27.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Mar 2014 03:26:48 -0800 References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Phil Hunt Date: Fri, 7 Mar 2014 11:26:44 +0000 To: Ralph Droms X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/ace/W8gORN3Pk3EjRtEkE6UYrU1slVg Cc: Carsten Bormann , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:27:01 -0000 While a 100% constrained case is foundational I think you need to consider d= ual protocol and mixed protocol cases.=20 Eg. A web server contacting a constrained resource. That server might obtain= a token from an http authz server for use against a constrained resource. O= r it might obtain one from a constrained authz server too.=20 All permutations seem likely to me. So much so, I think a constrained only c= harter would be problematic.=20 Phil > On Mar 7, 2014, at 11:00, Ralph Droms wrote: >=20 >=20 >=20 >>> On Mar 7, 2014, at 10:53 AM, Carsten Bormann wrote: >>>=20 >>> On 05 Mar 2014, at 14:32, Hannes Tschofenig w= rote: >>>=20 >>> In a nutshell there was some disagreement to purely focus on CoAP/DTLS >>> as part of a future working group. >>=20 >> Yes, and (for some reason I don=E2=80=99t understand) nobody said aloud w= hy that focus might be a problem (while, e.g., Sam very clearly said why *no= t* having that focus might be a problem). >>=20 >> It seems to me there is a false choice being presented here. >>=20 >> If we define a solution that is good for CoAP/DTLS, we would actively hav= e to go out of our way to make that useless for HTTP/TLS. >=20 > Where is that conclusion assured in the ACE charter or otherwise documente= d? >=20 >>=20 >> So the legacy SEP2.0*) support that seems to be the issue behind this dis= agreement can easily be accommodated without the WG losing its focus. >=20 > By "legacy" do you mean "not part of a walled garden"? >=20 > - Ralph >=20 >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> *) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP, TLS,= TCP. >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Fri Mar 7 03:31:08 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDB71A01AE for ; Fri, 7 Mar 2014 03:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SShNWpEX6tyW for ; Fri, 7 Mar 2014 03:31:04 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B08441A01FC for ; Fri, 7 Mar 2014 03:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s27BUtJ7005592; Fri, 7 Mar 2014 12:30:55 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4D0E1D83; Fri, 7 Mar 2014 12:30:55 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> Date: Fri, 7 Mar 2014 11:30:53 +0000 X-Mao-Original-Outgoing-Id: 415884653.389343-71278a99ba5074ef8b0277aabae52966 Content-Transfer-Encoding: quoted-printable Message-Id: <58385C98-8471-488C-A437-8C851E6988A4@tzi.org> References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/IPcBm_L5ctLacP7sXq2htX9zsCw Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:31:05 -0000 On 07 Mar 2014, at 11:24, Ralph Droms wrote: > Hannes - I don't think I can answer your question as you've posed it. = COAP/DTLS might or might not be used across any of these interactions. = It really depends on the specific applications and deployment scenario - = including considerations like scope of intended participants, interest = in reusing existing deployed code, existence of gateways, etc. Indeed, and, again, any reasonable solution that works with CoAP/DTLS = will work with HTTP/TLS here as well. What Steffi called I.2 is different from the other arrows as it is often = not involving constrained nodes at all, so it is here that we want to = embrace the ecosystem around HTTP/TLS (say, OAuth) more aggressively. Gr=FC=DFe, Carsten From nobody Fri Mar 7 05:30:37 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691111A01C9 for ; Fri, 7 Mar 2014 05:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPJLwR8r5pKm for ; Fri, 7 Mar 2014 05:30:33 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 573491A0159 for ; Fri, 7 Mar 2014 05:30:33 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-26-5319c9f43d0d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E0.E7.04853.4F9C9135; Fri, 7 Mar 2014 14:30:28 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Fri, 7 Mar 2014 14:30:27 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Phil Hunt , Ralph Droms Thread-Topic: [Ace] Scope of the ACE Charter Thread-Index: AQHPOH/Ac8HmUR+Qg0a24PkLLktiB5rVZUUAgAABxICAAAdwAIAAHU0A Date: Fri, 7 Mar 2014 13:30:26 +0000 Message-ID: References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <400BC3DC5FCDD541854BE3C92E416961@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM+Jvje6Xk5LBBnO2ylh8/9bDbHFkyl1W i6U777FaLJjfyG7ReK2P1YHVY+esu+weizftZ/NYsuQnk8fHp7dYPKYtygxgjeKySUnNySxL LdK3S+DKaDx8kLFgiUjFjp1HmBsYTwp0MXJySAiYSHy78JANwhaTuHBvPZDNxSEkcIJR4s6S OywQzmJGie1r37GDVLEJuEocePCOCcQWEfCU+L56MVicWaBIYs3030BxDg5hAW2Jxnd6ECU6 EpcOrGSHsN0krvb2sIDYLAIqEnfOHmYEsXkFzCV+fjwBNlJIYB+jxJVVDiA2p4CdxIJ7O8F6 GYGO+35qDRPEKnGJW0/mM0EcLSCxZM95ZghbVOLl43+sILaogJ7EvUdzWSDiShIrtl9ihOjV k7gxdQobhG0tcfDRD6jztSWWLXzNDHGPoMTJmU9YJjBKzEKybhaS9llI2mchaZ+FpH0BI+sq Rsni1OLi3HQjA73c9NwSvdSizOTi4vw8veLUTYzASD645bfRDsaTe+wPMUpzsCiJ815nrQkS EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCg98ZlQt+f/Q7860lK9ZjwQtRI1SVqTkfTn1pwV p5wr5ZpUIto4+L80JdwN1OHt457ppuH98OPCm+9ZuU6u2NCq/5Q1o+nx22in959Vr3I+q7E+ cf5EQ4yb5/KrnkVP3ii56G1SPPbw+oqk6rRXs8xa9+uWTupeErcvoXbBzxNyPnEZpq5njiix FGckGmoxFxUnAgA33cOWsgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3R2ebAGjJjsDPDmDMOGc0_-g2bM Cc: Carsten Bormann , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:30:35 -0000 Hi Phil On 07/03/14 11:26, "Phil Hunt" wrote: >While a 100% constrained case is foundational I think you need to >consider dual protocol and mixed protocol cases. > >Eg. A web server contacting a constrained resource. That server might >obtain a token from an http authz server for use against a constrained >resource. Or it might obtain one from a constrained authz server too. I agree with your statement to consider mixed protocol cases, but just want to point out that one reason for introducing the authz server is for offloading a constrained resource server with policy management and decision. So I would like to to assume that at least the authz server is less constrained. G=F6ran > >All permutations seem likely to me. So much so, I think a constrained >only charter would be problematic. >=20 > >Phil > >> On Mar 7, 2014, at 11:00, Ralph Droms wrote: >>=20 >>=20 >>=20 >>>> On Mar 7, 2014, at 10:53 AM, Carsten Bormann wrote: >>>>=20 >>>> On 05 Mar 2014, at 14:32, Hannes Tschofenig >>>> wrote: >>>>=20 >>>> In a nutshell there was some disagreement to purely focus on CoAP/DTLS >>>> as part of a future working group. >>>=20 >>> Yes, and (for some reason I don=B9t understand) nobody said aloud why >>>that focus might be a problem (while, e.g., Sam very clearly said why >>>*not* having that focus might be a problem). >>>=20 >>> It seems to me there is a false choice being presented here. >>>=20 >>> If we define a solution that is good for CoAP/DTLS, we would actively >>>have to go out of our way to make that useless for HTTP/TLS. >>=20 >> Where is that conclusion assured in the ACE charter or otherwise >>documented? >>=20 >>>=20 >>> So the legacy SEP2.0*) support that seems to be the issue behind this >>>disagreement can easily be accommodated without the WG losing its focus. >>=20 >> By "legacy" do you mean "not part of a walled garden"? >>=20 >> - Ralph >>=20 >>>=20 >>> Gr=FC=DFe, Carsten >>>=20 >>> *) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP, >>>TLS, TCP. >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Fri Mar 7 05:51:37 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E381A0164 for ; Fri, 7 Mar 2014 05:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhDgAjYuEf5c for ; Fri, 7 Mar 2014 05:51:32 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BFAC01A0118 for ; Fri, 7 Mar 2014 05:51:32 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s27DpLZM025054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Mar 2014 13:51:22 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s27DpLcO018405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Mar 2014 13:51:21 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s27DpLYY018401; Fri, 7 Mar 2014 13:51:21 GMT Received: from [10.32.98.134] (/31.221.87.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Mar 2014 05:51:21 -0800 References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Phil Hunt Date: Fri, 7 Mar 2014 13:51:18 +0000 To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/ace/2ZQKq753lEZ4lx9E6S-Gy7WMVxQ Cc: Carsten Bormann , Hannes Tschofenig , Ralph Droms , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:51:34 -0000 Agreed. However I can see cases where RS and authz are both constrained beca= use they are on same server. In this case i would suspect "policy" is largel= y driven by basic func of the device.=20 I mention this because as/rs on one server occurs frequently on web, not sur= e constrained would never have this.=20 Phil > On Mar 7, 2014, at 13:30, G=C3=B6ran Selander wrote: >=20 > Hi Phil >=20 >> On 07/03/14 11:26, "Phil Hunt" wrote: >>=20 >> While a 100% constrained case is foundational I think you need to >> consider dual protocol and mixed protocol cases. >>=20 >> Eg. A web server contacting a constrained resource. That server might >> obtain a token from an http authz server for use against a constrained >> resource. Or it might obtain one from a constrained authz server too. >=20 > I agree with your statement to consider mixed protocol cases, but just > want to point out that one reason for introducing the authz server is for > offloading a constrained resource server with policy management and > decision. So I would like to to assume that at least the authz server is > less constrained. >=20 > G=C3=B6ran >=20 >=20 >=20 >>=20 >> All permutations seem likely to me. So much so, I think a constrained >> only charter would be problematic. >>=20 >>=20 >> Phil >>=20 >>> On Mar 7, 2014, at 11:00, Ralph Droms wrote: >>>=20 >>>=20 >>>=20 >>>>> On Mar 7, 2014, at 10:53 AM, Carsten Bormann wrote: >>>>>=20 >>>>> On 05 Mar 2014, at 14:32, Hannes Tschofenig >>>>> wrote: >>>>>=20 >>>>> In a nutshell there was some disagreement to purely focus on CoAP/DTLS= >>>>> as part of a future working group. >>>>=20 >>>> Yes, and (for some reason I don=C2=B9t understand) nobody said aloud wh= y >>>> that focus might be a problem (while, e.g., Sam very clearly said why >>>> *not* having that focus might be a problem). >>>>=20 >>>> It seems to me there is a false choice being presented here. >>>>=20 >>>> If we define a solution that is good for CoAP/DTLS, we would actively >>>> have to go out of our way to make that useless for HTTP/TLS. >>>=20 >>> Where is that conclusion assured in the ACE charter or otherwise >>> documented? >>>=20 >>>>=20 >>>> So the legacy SEP2.0*) support that seems to be the issue behind this >>>> disagreement can easily be accommodated without the WG losing its focus= . >>>=20 >>> By "legacy" do you mean "not part of a walled garden"? >>>=20 >>> - Ralph >>>=20 >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>> *) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP, >>>> TLS, TCP. >>>>=20 >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Sat Mar 8 14:53:06 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A021A0274 for ; Sat, 8 Mar 2014 14:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9WRHD0k5tOi for ; Sat, 8 Mar 2014 14:52:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id AC5971A01EE for ; Sat, 8 Mar 2014 14:52:58 -0800 (PST) Received: from sandelman.ca (unknown [209.87.252.140]) by relay.sandelman.ca (Postfix) with ESMTPS id AE0132207B for ; Sat, 8 Mar 2014 17:52:53 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D765FCA0E2 for ; Sat, 8 Mar 2014 10:38:41 -0500 (EST) From: Michael Richardson To: "ace\@ietf.org" In-reply-to: <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> Comments: In-reply-to Ralph Droms message dated "Fri, 07 Mar 2014 11:24:44 +0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 08 Mar 2014 10:38:41 -0500 Message-ID: <7540.1394293121@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Z4IZ2SplgTKxNoI632UnDxTgc44 Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:53:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This is what I understand about the concern about scope. (Gotta love emacs picture-mode... outlook users will need a fixed font) +---------------+ | Authorization | +------------------+-------->| Server | | (I) / +---------------+ | authz / ^ | / | /--------\ / | (IV) | oauth | / | III | proxy | / | authz \--------/ / | |----------/ | v v +-----------+ (access) +-----+-----+ | | /------\ (II) | Resource | | Client | <...|https/|.......>| Server | +-----------+ | coap | +-----------+ | dtls | |proxy | (V) \------/ =3D=3D=3D=3D IV - is some kind of translator that can take/process OAUTH2 (or some other system!) requests into our authorization protocol. It might be that teaching the authorization server itself to speak OAUTH2 is really the only answer, and that would be fine with me. V - this is an HTTPS(with OAUTH2 token) to COAP/DTLS (with ACE token) proxy. It would be nice if (V) did not have to have god/superuser access to the authorization server. I.e. it would be nice if that proxy could be untrusted by both the client and the authorization server.=20=20 Does this diagram match what others have been asking about? (I have intentionally left out the SEP2.0 stuff out of this diagram, as I have no idea what it uses for authorization) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJTGzl/AAoJEKD0KQ7Gj3P2QSoH/07/cADXftAp7cQbKEVNlzld qho0d8NfJBBbJsmgj2/65KuhYztXJMekbZTBbukOdNnX43pJGwxxr2l6nUiO3/tB Fr6yO/i5rq+kayiBpYbqHEeTgKQdYO8L6gNSBDUVOEe8JOuod15OH88Muc7+T0+d Q2XXU2z/tCqzqonzWODHhOmN6TGKwDSsE4HDZ+CZSGRnDpnEXbsGAh3KszCx6mN1 /L7ZOmSf8x0xTUJVfCfR94JpYkzRSlj5Mtu6aBTHmrajBRJd7krUbDBTmAcT8LCo Z7VvvmtBWbhrV1Hhd17qin4uISQkuM+qejMvesX7twpAaYc4KdCnerfWqtCPpNA= =7KNh -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 8 14:53:13 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8301A02EC for ; Sat, 8 Mar 2014 14:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR3NtnGfGh6E for ; Sat, 8 Mar 2014 14:52:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id B75501A02EB for ; Sat, 8 Mar 2014 14:52:58 -0800 (PST) Received: from sandelman.ca (unknown [209.87.252.140]) by relay.sandelman.ca (Postfix) with ESMTPS id B66232207E for ; Sat, 8 Mar 2014 17:52:53 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1FB8ECA0E0 for ; Sat, 8 Mar 2014 10:25:58 -0500 (EST) From: Michael Richardson To: "ace\@ietf.org" In-reply-to: References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> Comments: In-reply-to Phil Hunt message dated "Fri, 07 Mar 2014 11:26:44 +0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 08 Mar 2014 10:25:57 -0500 Message-ID: <7074.1394292357@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/4kQvkRix2b-TcTByt5TWemwxMQ4 Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:53:02 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Phil Hunt wrote: > While a 100% constrained case is foundational I think you need to > consider dual protocol and mixed protocol cases. > Eg. A web server contacting a constrained resource. That server might > obtain a token from an http authz server for use against a constrained > resource. Or it might obtain one from a constrained authz server too. 1) can we all agree that when you write "100% constrained case", what you mean is that all clients and servers can speak CoAP/DTLS, not that all nodes are constrainted. (In particular that the authz server is not constrained) 2) while I need to re-read the charter (and I can not yet do that from the airplane), what I would like to suggest is the following: a) that we come up with a protocol that works for where there are no proxies to/from CoAP, and that OAUTH2/Kerberos/etc. interoperation is out of scope (initially). b) that before we claim the protocol is baked in any important way, that we, as a WG milestone, do an analysis of proxy interaction, and either fix the protocol (if we can), or make that scenario out of scope. We may have to add MTI pieces to make things work. Running code would be good to have at this point. =20=20=20=20=20=20 What I don't want to do is to fall into some trap where we had what would been a simple and elegant protocol start it's life ugly. While we might decide to make it ugly, it should be a conscious choice. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJTGzaBAAoJEKD0KQ7Gj3P2avcIAKOesQGvUx3F/gxRU43z2p7A VHkZBhO8LDJJ/GBDP10y70/kZ4v0Az1BgH7jxVUrKniol9Ubxq78j+T996fDBfE3 +Fr+3JseAMQBGX2wCYAsjiIQ/KloR4gMqvq73DaKOjuu1y0I11HnTB44ruj+o63U 4WEkutzrsYt0aOvNj4fVq5b+MywUxNF6Gwu8WVNerPv5HwIG70LTOVtGwUL3OFQi /MIRe49HicNWB7anHGFBNBzSLUREjD6eMZcPh/MwG7wWAR5F4042BZGq1QIzI+36 GmsnBH+z0dcJecRHQpwTBtQ86/TdRb/nTp1mhvjVWF2Eav6hc5MyiXrTk1sc6G8= =QRab -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 9 08:18:08 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782F11A014D; Wed, 5 Mar 2014 08:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB3IjI0JMIlK; Wed, 5 Mar 2014 08:57:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F20B51A0179; Wed, 5 Mar 2014 08:57:23 -0800 (PST) Received: from [192.168.10.133] ([31.133.156.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MJByE-1WMtoy300Y-002mSN; Wed, 05 Mar 2014 17:57:18 +0100 Message-ID: <5317576C.6090400@gmx.net> Date: Wed, 05 Mar 2014 17:57:16 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM" X-Provags-ID: V03:K0:kiDWCHk4d7y7EV13i4sr91IATfQ0ToNtgW8+odv+G5cURJs9uNq XcHBZGD7pXKcaH51gtjN4ycNychhrD3rWOHLVdPLLVcFKnPPUNaAM3ZgaJqrbMxwXccUvJd LTqJaiNalinmCdeyYoOoJKV3Ybq3hqRpw96g0tn96smmY6TfQkhQQsbUYwxf67o439euUbR HdkE25h2cWLJvxjEa4DrQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/iHQFf9lHJ6yUs0T-G1Yy2WMtwbI X-Mailman-Approved-At: Sun, 09 Mar 2014 08:18:05 -0700 Subject: [Ace] IETF#89 ACE Summary X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:57:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We held the ACE BOF this morning from 9am to 11:30am. We started with a presentation about what constrained node networks are, explained use cases & requirements and discussed design choices. We concluded with a gap analysis. There was good support for doing the work in the IETF and there was a fair amount of feedback from the audience regarding the charter text. About 30 persons indicated that they are willing to review specifications and 15 persons said that they will be contributing documents. The feedback from the audience included: - Scope of the work Should it be focused on CoAP / DTLS only? In particular, the question about the suitability of the developed solutions for HTTP and SMS transport was raised. - Assumptions What assumptions are being made by the use cases in terms of requirement for a clock, interworking with existing infrastructure, interaction with proxies, and intermittent connectivity of different parties (off-line use cases). - Provisioning of credentials and other configuration parameters Participants suggested to consider looking at the entire life cycle of these IoT devices to prevent problems later with provisioning. While those do not necessarily be standardized in this group there was a desire to avoid later problems. As next steps the charter discussions will have to continue to resolve some of the raised questions. The BOF chairs encouraged the audience to develop strawman proposals to gain further experience about the underlying assumptions. Ciao Hannes --hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTF1dsAAoJEGhJURNOOiAtoawH/38WQ7V9LeUTNpYgdffi2hoL iQRvFj4zdIUoOzDytpQElvlJdHHxnBlKuLnJgdbQgts6XRqBpFUM5nYq/IX5X/Au +ZfYIDV2rqn1wL4qC8cI0TeMiUFUprBjk3JgeXeZX7h6Z+Y78bOIab2E9YrCJTju NanG6r4eydQSBxEMWwu7t4llQQPy67CmC4YevTaE3fH8Gcy3tywQHWuctCL665g8 RQPeNTnPZ7inDz8nhzZnbOMB+9AiuYdmcZcTVAfmX4OW/aIQBdTIMg+T2jkw4Dg2 Q0znMWmVdE6rBiaz7zHaVTQK7SQGpxYZTXVPLDrC70V8PWpjPRRfMrKUC+ufcFI= =/dtW -----END PGP SIGNATURE----- --hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM-- From nobody Sun Mar 9 22:55:16 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB21A03CA for ; Sun, 9 Mar 2014 22:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0xrScD-_7OE for ; Sun, 9 Mar 2014 22:55:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4A1A03D1 for ; Sun, 9 Mar 2014 22:55:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-0e-531d53b94057 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 97.54.23809.9B35D135; Mon, 10 Mar 2014 06:55:06 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 06:55:05 +0100 From: =?windows-1254?Q?G=F6ran_Selander?= To: Phil Hunt Thread-Topic: [Ace] Scope of the ACE Charter Thread-Index: AQHPOH/Ac8HmUR+Qg0a24PkLLktiB5rVZUUAgAABxICAAAdwAIAAHU0AgAALFwCABEKygA== Date: Mon, 10 Mar 2014 05:55:05 +0000 Message-ID: References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="windows-1254" Content-ID: <0A3B622D655920499F11593F3D614F05@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3RndXsGywwcM93Bbfv/UwWxyZcpfV YunOe6wWC+Y3sls0XutjdWD12DnrLrvH4k372TyWLPnJ5PHx6S0Wj2mLMgNYo7hsUlJzMstS i/TtErgyrp5bwF6wQL5i04TNzA2MRyS7GDk5JARMJCadbWaBsMUkLtxbz9bFyMUhJHCIUWLX 1etMEM4SRomJu2aCVbEJuEvM2bsSzBYRUJH4dvU6I0gRs8B0Rol5v/vYuxg5OIQFtCUa3+lB 1OhIXDqwkh3CDpNY0v+ICcRmEVCVuLRuClicV8BcYuabi8wQyxYwSfRvawQr4hSwk3jw+CSY zQh03vdTa8BsZgFxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rCC2qICexL1Hc6FeU5JYe3g7C0Sv gcSRczdZIWxrifaW9ewQtrbEsoWvmSEOEpQ4OfMJywRGiVlI1s1C0j4LSfssJO2zkLQvYGRd xciem5iZk15utIkRGKkHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTCunlPmd/au2r/cuuxcnTbpdQ9/7l504+Vqq/Dnn1VL5zqf85y5PH9fv3Xzivgl qxgnR2twqWx92RrKq5PI1yifwe9S/umpwW2X4uTvok6vt9qL9NTlpRRkCl1ZvfGaN5/7waMr fb+LnFd7ECXDzs2edEdp2u+vbXMLNGbYyF/aaFu95Fu8f74SS3FGoqEWc1FxIgAzQ6owogIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/R25hy-Tsms67H3P_kQfnsFcVeds Cc: Carsten Bormann , Hannes Tschofenig , Ralph Droms , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 05:55:15 -0000 Hi Phil On 07/03/14 14:51, "Phil Hunt" wrote: >Agreed. However I can see cases where RS and authz are both constrained >because they are on same server. In this case i would suspect "policy" is >largely driven by basic func of the device. > >I mention this because as/rs on one server occurs frequently on web, not >sure constrained would never have this. I would like to see the AS as optional functionality, in cases where the RS does not have the authz info it requires to decide on grant or deny an access request. In use cases where it suffices with configured access policies in the RS (corresponding to what you call =93basic fund=94?) there= is no need for an AS at all. With this in mind I would like to assume that the AS, when present, is not a constrained device. Does that make sense or are there still other options to consider? Thanks G=F6ran > >Phil > >> On Mar 7, 2014, at 13:30, G=F6ran Selander >>wrote: >>=20 >> Hi Phil >>=20 >>> On 07/03/14 11:26, "Phil Hunt" wrote: >>>=20 >>> While a 100% constrained case is foundational I think you need to >>> consider dual protocol and mixed protocol cases. >>>=20 >>> Eg. A web server contacting a constrained resource. That server might >>> obtain a token from an http authz server for use against a constrained >>> resource. Or it might obtain one from a constrained authz server too. >>=20 >> I agree with your statement to consider mixed protocol cases, but just >> want to point out that one reason for introducing the authz server is >>for >> offloading a constrained resource server with policy management and >> decision. So I would like to to assume that at least the authz server is >> less constrained. >>=20 >> G=F6ran >>=20 >>=20 >>=20 >>>=20 >>> All permutations seem likely to me. So much so, I think a constrained >>> only charter would be problematic. >>>=20 >>>=20 >>> Phil >>>=20 >>>> On Mar 7, 2014, at 11:00, Ralph Droms wrote: >>>>=20 >>>>=20 >>>>=20 >>>>>> On Mar 7, 2014, at 10:53 AM, Carsten Bormann wrote: >>>>>>=20 >>>>>> On 05 Mar 2014, at 14:32, Hannes Tschofenig >>>>>> wrote: >>>>>>=20 >>>>>> In a nutshell there was some disagreement to purely focus on >>>>>>CoAP/DTLS >>>>>> as part of a future working group. >>>>>=20 >>>>> Yes, and (for some reason I don=B9t understand) nobody said aloud why >>>>> that focus might be a problem (while, e.g., Sam very clearly said why >>>>> *not* having that focus might be a problem). >>>>>=20 >>>>> It seems to me there is a false choice being presented here. >>>>>=20 >>>>> If we define a solution that is good for CoAP/DTLS, we would actively >>>>> have to go out of our way to make that useless for HTTP/TLS. >>>>=20 >>>> Where is that conclusion assured in the ACE charter or otherwise >>>> documented? >>>>=20 >>>>>=20 >>>>> So the legacy SEP2.0*) support that seems to be the issue behind this >>>>> disagreement can easily be accommodated without the WG losing its >>>>>focus. >>>>=20 >>>> By "legacy" do you mean "not part of a walled garden"? >>>>=20 >>>> - Ralph >>>>=20 >>>>>=20 >>>>> Gr=FC=DFe, Carsten >>>>>=20 >>>>> *) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP, >>>>> TLS, TCP. >>>>>=20 >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>>=20 >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace From nobody Mon Mar 10 02:00:51 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F261A03FA for ; Mon, 10 Mar 2014 02:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPQF7cMFMAPs for ; Mon, 10 Mar 2014 02:00:49 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BF3881A03FD for ; Mon, 10 Mar 2014 02:00:48 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-64-531d7f3aeee4 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 75.09.04249.A3F7D135; Mon, 10 Mar 2014 10:00:42 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 10:00:42 +0100 From: =?Windows-1252?Q?G=F6ran_Selander?= To: Michael Richardson , "ace@ietf.org" Thread-Topic: [Ace] Scope of the ACE Charter Thread-Index: AQHPOH/Ac8HmUR+Qg0a24PkLLktiB5rVbeoAgAHZSYCAAsY6gA== Date: Mon, 10 Mar 2014 09:00:42 +0000 Message-ID: References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> <7540.1394293121@sandelman.ca> In-Reply-To: <7540.1394293121@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <77C5320D0AAFDA4E887D7A9A619BA421@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvja5VvWywwZ9Oc4vv33qYLXoO9bM7 MHksWfKTyaNlzh7mAKYoLpuU1JzMstQifbsEroyXH1eyFdwTrVh8WLuB8TRvFyMnh4SAicSG 6UuYIWwxiQv31rN1MXJxCAkcYZToPzWbBcJZwijxevkeNpAqNgF3icc9G1lAbBEBX4kFZ3cz djFycAgLaEs0vtODCOtIXDqwkh3CdpL4e/8CE4jNIqAq0XdoIpjNK2Au8e32V7CRQgJVEq8b poLZnEBjFl55xApiMwId9P3UGrB6ZgFxiVtP5jNBHCogsWTPeaijRSVePv4HVi8qoCdx79Fc Foi4osTOs+3MEL0GEu/PzYeyrSV2PZ4KNVNbYtnC18wQ9whKnJz5hGUCo/gsJOtmIWmfhaR9 FpL2WUjaFzCyrmLkKE4tTspNNzLYxAiMqYNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGAtW2ayO91q28q9RdePRtC7ta6lVhb+Wbi9cE6H8/OTTV7Er VwteTG26L87GnsLdpKv8KnmKrOwOK7fIW24nZFNmiK/5sfbUrj4V80KbU/1tuj0NQiLr1foz 1ZZO15mUUpX06oLRNrd18+anu3Pzb85dZzR59p+Vvxy/HXyZM2O7YtrPScrvLZRYijMSDbWY i4oTASeAg0p3AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fNiBnF8C903Dpa_5PousshN-qRE Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 09:00:50 -0000 Hi Michael Just on untrusted intermediaries: Since the AS needs to protect certain information end-to-end =8B e.g. authorisation information to be consumed by the RS, key management information to be consumed by the Client =8B hop-by-hop transport layer security would not be sufficient. This case could be handled with object secure information (some sort of ticket/access token) integrity protected or encrypted on application layer. As the secure object can't be changed by an intermediary, it need to be formatted for transfer to the intended consumer already by the AS, which in particular may need to take into account a constrained environment. G=F6ran On 08/03/14 16:38, "Michael Richardson" wrote: > >This is what I understand about the concern about scope. >(Gotta love emacs picture-mode... outlook users will need a fixed font) > > > +---------------+ > | Authorization | > +------------------+-------->| Server | > | (I) / +---------------+ > | authz / ^ > | / | > /--------\ / | > (IV) | oauth | / | III > | proxy | / | authz > \--------/ / | > |----------/ | > v v > +-----------+ (access) +-----+-----+ > | | /------\ (II) | Resource | > | Client | <...|https/|.......>| Server | > +-----------+ | coap | +-----------+ > | dtls | > |proxy | (V) > \------/ > >=3D=3D=3D=3D > >IV - is some kind of translator that can take/process OAUTH2 (or some > other system!) requests into our authorization protocol. It might > be that teaching the authorization server itself to speak OAUTH2 > is really the only answer, and that would be fine with me. > >V - this is an HTTPS(with OAUTH2 token) to COAP/DTLS (with ACE token) >proxy. > >It would be nice if (V) did not have to have god/superuser access to the >authorization server. I.e. it would be nice if that proxy could be >untrusted >by both the client and the authorization server. > >Does this diagram match what others have been asking about? >(I have intentionally left out the SEP2.0 stuff out of this diagram, as I >have no idea what it uses for authorization) > >--=20 >Michael Richardson >-on the road- > > > > > > > From nobody Mon Mar 10 04:05:16 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60C71A041B for ; Mon, 10 Mar 2014 04:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umz2EXWPnJcw for ; Mon, 10 Mar 2014 04:05:12 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 659DA1A041F for ; Mon, 10 Mar 2014 04:05:12 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so6772732qgd.1 for ; Mon, 10 Mar 2014 04:05:07 -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; bh=2kOjcnqWHjDxNPwbsBUs4YVFL+SaPzi5fw1MgYshbmY=; b=GcXATIA244RnelXZ+LrDie77gWSrQrJ/ZRjZV8GtjYz8PfLcR4Zb7KDzaBkwUep18T jOjLhrgbcg3rT0Gsfp3xq4X8dC14PYxQgLi6Ld4K4VR5nLbUDNlrCjsBB3qsKb5QiQ18 ADdbvseojs3g2SXNtxz9opSKohZ+VJpXSOmt/thaGhYeNmUTOB8Ots5qybHfF3xvbFNX gqk3whxaFV0mAmj44AIa6GDE6e3P70XkJQdSaiJ6Qq7/pOBdV3zLzP6JhHa81KJB+8eh O4z4IzD0qgp2y/55GGOZcy4PlmBAbKIGR2nygMGa0TaEQ1qDwZB0n8ItXdpdNuV6Gx9E zYow== X-Received: by 10.140.34.231 with SMTP id l94mr6498383qgl.85.1394449506928; Mon, 10 Mar 2014 04:05:06 -0700 (PDT) Received: from new-host-2.home (pool-108-7-235-60.bstnma.fios.verizon.net. [108.7.235.60]) by mx.google.com with ESMTPSA id h46sm25743609qgd.10.2014.03.10.04.05.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 04:05:06 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Wasserman In-Reply-To: <5317357B.6020407@gmx.net> Date: Mon, 10 Mar 2014 07:05:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5317357B.6020407@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fKpF4eMaUea17f30-jaYos7XRyc Cc: "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 11:05:15 -0000 I am thinking that we should design/select an authentication and = authorization solution that is suitable for the situation where = interface II is using CoAP/DTLS. The solution should work well the = Client communicates to the Resource Server using CoAP/DTLS. It should = also work well when the Resource Server is a constrained node, the = Client is a constrained node, or both the Resource Server and Client are = constrained nodes. I do not think that we should assume that interface I or III will use = CoAP/DTLS, just that the protocols used on those interfaces should be = chosen or designed to be complementary with CoAP/DTLS. One example = might be RADIUS with a new EAP Method that uses DTLS (similar to the = current TEAP method's use of TLS) and a profile that limits the required = crypto algorithms to those that are already required for CoAP/DTLS. = Another example could be a constrained Kerberos profile that restricts = the encryption algorithms available to the list that is required for = CoAP/DTLS. I don't know how to give the same sort of example for PKI or = OAUTH solutions, but they probably exist. I think that requiring CoAP/DTLS to be used on interface I or III overly = constrains the situation and effectively requires us to create anew = authorization and authentication protocol. I think we should avoid = doing that, if at all possible. Please note that implementing CoAP/DTLS on the Client and Resource = Server DOES NOT PREVENT those nodes from ALSO implementing other = protocols. For instance an unconstrained Client, such as a building = control unit, may implement CoAP/DTLS (plus whatever auth solution we = choose/design) to talk to sensors and actuators AND provide a standard = HTTP/TLS web server as a northbound interface for users to control the = building from anywhere on the Internet. In my thoughts, we would be = expecting the Client and Server to _at least_ implement CoAP/DTLS. They = could also implement other protocols, depending on how resource = constrained they are (or aren't). Margaret On Mar 5, 2014, at 9:32 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > I would like to thank you all for the great discussion today at the = BOF. > There was good feedback and the following scoping aspect showed up. >=20 > In a nutshell there was some disagreement to purely focus on CoAP/DTLS > as part of a future working group. >=20 > There was not enough time to go down to the details during the session > due to lack of time. Hence, I will try to clarify this aspect on the > mailing list. >=20 > Let us have a look at the high level architecture: >=20 > +---------------+ > | Authorization | > +--------------------------->| Server | > | (I) +---------------+ > | ^ > | | > | | > | | III > | | > | | > | | > v v > +-----------+ +-----+-----+ > | | II | Resource | > | Client | <..................>| Server | > +-----------+ +-----------+ >=20 > I: This is the interaction where keying and authorization information = is > provided to the client. >=20 > II: This is the resource access. >=20 > III: This is a potential exchange necessary for having the resource > server interacting with the authorization server for authenticating = the > client and for authorizing the client. >=20 > (The exact details of the interaction depend on the specific solution, > of course.) >=20 > As you can see in the figure, there are various places where DTLS and > CoAP should or shouldn't be used. >=20 > A few persons said that they want to use other protocols besides CoAP > and DTLS. >=20 > Please explain me where you would like to other protocols being taken > into consideration. What protocols are you considering in which of = these > interfaces? >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Mar 10 07:04:14 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EB11A0434 for ; Mon, 10 Mar 2014 07:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRmsMX_HQZhf for ; Mon, 10 Mar 2014 07:04:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 255FD1A043E for ; Mon, 10 Mar 2014 07:04:09 -0700 (PDT) Received: from [192.168.131.133] ([80.92.123.72]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MdaCy-1WWrcd1RGO-00PPBS for ; Mon, 10 Mar 2014 15:04:03 +0100 Message-ID: <531DC1BA.4050305@gmx.net> Date: Mon, 10 Mar 2014 14:44:26 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MvLvDRadtWIDo5fdJsfDjFSmLVKwAv1KP" X-Provags-ID: V03:K0:GqVqRKRvKr/QJaYNIOFUUK5cW20w8Lx6Rz2UNtePUfUfO1enJpG HnjVz+Vwr2Bh9CvKIJmHyAjNJMGAei5QesvoPZffmeBwjhOHsM/5nFCjR3oHDvIxycAbpds lXH0nYMM878rBWzVy5Hu3u725elLkAO6WPBD5pGiVJGR64Ua+tJ9si5xWlz6bMFvc9mjKK9 OxzAmZzLU5FadjX/Qj9sA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/739r-Be3s2ApF81OI90Cl_ux-GY Subject: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:04:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MvLvDRadtWIDo5fdJsfDjFSmLVKwAv1KP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, here are the meeting minutes: http://www.ietf.org/proceedings/89/minutes/minutes-89-ace Please have a look at them to see whether your comment has correctly been captured and whether there are other bugs. Ciao Hannes PS: Thanks to Bert for taking notes. --MvLvDRadtWIDo5fdJsfDjFSmLVKwAv1KP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTHcG6AAoJEGhJURNOOiAtOhIH/0o5VQqPfuQh9ghFX8bJ33A4 s7OF+wVdvaCyppD2tdsoy3m/aseLFqJRj3+JVAh2sdqa8U43ASFx7L+0WFnT/3bT 1PbZgcgAwVorgB0reNNwyriOF1P6XVdrzZxP3Wa69BuNJ2uHWXBhKIbAWc7d3na8 azS1WtJu+U73SJC+76S4Bgkub7OwMMf9yyLFwf+FlfrAy9iJ9bctK7XARMgFAlUA zZZY2RhRjlXDx3RAcQgdXcUFJwMrmqxbCxvQGfj1K9VTdw/KlCLcK2yVFRvFuofz /uTj5aCEBGguzYvgduhlOp+/mYraJi+ljcmPc1RIRiW31VEcOMi/+yeCT+yl1h4= =aurn -----END PGP SIGNATURE----- --MvLvDRadtWIDo5fdJsfDjFSmLVKwAv1KP-- From nobody Mon Mar 10 08:34:36 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059AC1A04A2 for ; Mon, 10 Mar 2014 08:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmweGq7vMIJ3 for ; Mon, 10 Mar 2014 08:34:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 453311A04A7 for ; Mon, 10 Mar 2014 08:34:20 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2AFY7fD026459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Mar 2014 15:34:07 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2AFY60d020322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Mar 2014 15:34:06 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2AFY5Oq020299; Mon, 10 Mar 2014 15:34:05 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Mar 2014 08:34:05 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: Date: Mon, 10 Mar 2014 15:33:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6E4F9595-A3E3-4963-90FE-D7C9EA3979E7@oracle.com> References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> To: =?windows-1252?Q?G=F6ran_Selander?= X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/ace/8ZPTOfYlgur6-AgvIwM2sH4Nehs Cc: Carsten Bormann , Hannes Tschofenig , Ralph Droms , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 15:34:26 -0000 I agree. Though while the AS might not actually be constrained, both the = client and resource may well be. That would mean the AS has to support CoAP/DTLS correct? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-03-10, at 5:55 AM, G=F6ran Selander = wrote: > Hi Phil >=20 > On 07/03/14 14:51, "Phil Hunt" wrote: >=20 >> Agreed. However I can see cases where RS and authz are both = constrained >> because they are on same server. In this case i would suspect = "policy" is >> largely driven by basic func of the device. >>=20 >> I mention this because as/rs on one server occurs frequently on web, = not >> sure constrained would never have this. >=20 > I would like to see the AS as optional functionality, in cases where = the > RS does not have the authz info it requires to decide on grant or deny = an > access request. In use cases where it suffices with configured access > policies in the RS (corresponding to what you call =93basic fund=94?) = there is > no need for an AS at all. >=20 > With this in mind I would like to assume that the AS, when present, is = not > a constrained device. Does that make sense or are there still other > options to consider? >=20 > Thanks > G=F6ran >=20 >>=20 >> Phil >>=20 >>> On Mar 7, 2014, at 13:30, G=F6ran Selander = >>> wrote: >>>=20 >>> Hi Phil >>>=20 >>>> On 07/03/14 11:26, "Phil Hunt" wrote: >>>>=20 >>>> While a 100% constrained case is foundational I think you need to >>>> consider dual protocol and mixed protocol cases. >>>>=20 >>>> Eg. A web server contacting a constrained resource. That server = might >>>> obtain a token from an http authz server for use against a = constrained >>>> resource. Or it might obtain one from a constrained authz server = too. >>>=20 >>> I agree with your statement to consider mixed protocol cases, but = just >>> want to point out that one reason for introducing the authz server = is >>> for >>> offloading a constrained resource server with policy management and >>> decision. So I would like to to assume that at least the authz = server is >>> less constrained. >>>=20 >>> G=F6ran >>>=20 >>>=20 >>>=20 >>>>=20 >>>> All permutations seem likely to me. So much so, I think a = constrained >>>> only charter would be problematic. >>>>=20 >>>>=20 >>>> Phil >>>>=20 >>>>> On Mar 7, 2014, at 11:00, Ralph Droms = wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>> On Mar 7, 2014, at 10:53 AM, Carsten Bormann = wrote: >>>>>>>=20 >>>>>>> On 05 Mar 2014, at 14:32, Hannes Tschofenig >>>>>>> wrote: >>>>>>>=20 >>>>>>> In a nutshell there was some disagreement to purely focus on >>>>>>> CoAP/DTLS >>>>>>> as part of a future working group. >>>>>>=20 >>>>>> Yes, and (for some reason I don=B9t understand) nobody said aloud = why >>>>>> that focus might be a problem (while, e.g., Sam very clearly said = why >>>>>> *not* having that focus might be a problem). >>>>>>=20 >>>>>> It seems to me there is a false choice being presented here. >>>>>>=20 >>>>>> If we define a solution that is good for CoAP/DTLS, we would = actively >>>>>> have to go out of our way to make that useless for HTTP/TLS. >>>>>=20 >>>>> Where is that conclusion assured in the ACE charter or otherwise >>>>> documented? >>>>>=20 >>>>>>=20 >>>>>> So the legacy SEP2.0*) support that seems to be the issue behind = this >>>>>> disagreement can easily be accommodated without the WG losing its >>>>>> focus. >>>>>=20 >>>>> By "legacy" do you mean "not part of a walled garden"? >>>>>=20 >>>>> - Ralph >>>>>=20 >>>>>>=20 >>>>>> Gr=FC=DFe, Carsten >>>>>>=20 >>>>>> *) Smart Energy Profile 2.0, based on a custom XML vocabulary, = HTTP, >>>>>> TLS, TCP. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ace mailing list >>>>>> Ace@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ace >>>>>=20 >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>>=20 >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Mar 10 08:48:55 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8A11A04AC for ; Mon, 10 Mar 2014 08:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0RaCV2PGM0D for ; Mon, 10 Mar 2014 08:48:49 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2F1A04AF for ; Mon, 10 Mar 2014 08:48:48 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Mon, 10 Mar 2014 15:48:42 +0000 Received: from usa-sjc-gw2.usa.Arm.com (10.72.50.52) by usa-sjc-gw1.usa.Arm.com (10.72.50.51) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 10 Mar 2014 08:48:48 -0700 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Mon, 10 Mar 2014 08:48:48 -0700 From: Zach Shelby To: Phil Hunt Date: Mon, 10 Mar 2014 08:48:43 -0700 Thread-Topic: [Ace] Scope of the ACE Charter Thread-Index: Ac88eDmRWFWXx/cDSsKxb1xpCgcZIg== Message-ID: <33775287-1182-468A-8759-69A947B7C419@arm.com> References: <5317357B.6020407@gmx.net> <31F51278-ED16-4A1F-9BA3-C305C7AC5ECB@gmail.com> <6E4F9595-A3E3-4963-90FE-D7C9EA3979E7@oracle.com> In-Reply-To: <6E4F9595-A3E3-4963-90FE-D7C9EA3979E7@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114031015484203102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ace/FeYUcWqOlV6eBT9_sS1OSncMOlE Cc: Hannes Tschofenig , Carsten Bormann , =?Windows-1252?Q?G=F6ran_Selander?= , Ralph Droms , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 15:48:54 -0000 On Mar 10, 2014, at 3:33 PM, Phil Hunt wrote: > I agree. Though while the AS might not actually be constrained, both the = client and resource may well be. That is correct. And the client and resource might be deep in a challenging= 6LoWPAN NAN network with 1000s of nodes sharing a 250 kbps channel (many S= mart City related applications). In those kinds of deployments communicati= on with the AS really needs to be efficient. > That would mean the AS has to support CoAP/DTLS correct? Yes. Although there will be non-constrained devices and less challenging ne= tworks where HTTP/TLS would be just fine. Zach > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On 2014-03-10, at 5:55 AM, G=F6ran Selander = wrote: > >> Hi Phil >> >> On 07/03/14 14:51, "Phil Hunt" wrote: >> >>> Agreed. However I can see cases where RS and authz are both constrained >>> because they are on same server. In this case i would suspect "policy" = is >>> largely driven by basic func of the device. >>> >>> I mention this because as/rs on one server occurs frequently on web, no= t >>> sure constrained would never have this. >> >> I would like to see the AS as optional functionality, in cases where the >> RS does not have the authz info it requires to decide on grant or deny a= n >> access request. In use cases where it suffices with configured access >> policies in the RS (corresponding to what you call =93basic fund=94?) th= ere is >> no need for an AS at all. >> >> With this in mind I would like to assume that the AS, when present, is n= ot >> a constrained device. Does that make sense or are there still other >> options to consider? >> >> Thanks >> G=F6ran >> >>> >>> Phil >>> >>>> On Mar 7, 2014, at 13:30, G=F6ran Selander >>>> wrote: >>>> >>>> Hi Phil >>>> >>>>> On 07/03/14 11:26, "Phil Hunt" wrote: >>>>> >>>>> While a 100% constrained case is foundational I think you need to >>>>> consider dual protocol and mixed protocol cases. >>>>> >>>>> Eg. A web server contacting a constrained resource. That server might >>>>> obtain a token from an http authz server for use against a constraine= d >>>>> resource. Or it might obtain one from a constrained authz server too. >>>> >>>> I agree with your statement to consider mixed protocol cases, but just >>>> want to point out that one reason for introducing the authz server is >>>> for >>>> offloading a constrained resource server with policy management and >>>> decision. So I would like to to assume that at least the authz server = is >>>> less constrained. >>>> >>>> G=F6ran >>>> >>>> >>>> >>>>> >>>>> All permutations seem likely to me. So much so, I think a constrained >>>>> only charter would be problematic. >>>>> >>>>> >>>>> Phil >>>>> >>>>>> On Mar 7, 2014, at 11:00, Ralph Droms wrote: >>>>>> >>>>>> >>>>>> >>>>>>>> On Mar 7, 2014, at 10:53 AM, Carsten Bormann wrote: >>>>>>>> >>>>>>>> On 05 Mar 2014, at 14:32, Hannes Tschofenig >>>>>>>> wrote: >>>>>>>> >>>>>>>> In a nutshell there was some disagreement to purely focus on >>>>>>>> CoAP/DTLS >>>>>>>> as part of a future working group. >>>>>>> >>>>>>> Yes, and (for some reason I don=B9t understand) nobody said aloud w= hy >>>>>>> that focus might be a problem (while, e.g., Sam very clearly said w= hy >>>>>>> *not* having that focus might be a problem). >>>>>>> >>>>>>> It seems to me there is a false choice being presented here. >>>>>>> >>>>>>> If we define a solution that is good for CoAP/DTLS, we would active= ly >>>>>>> have to go out of our way to make that useless for HTTP/TLS. >>>>>> >>>>>> Where is that conclusion assured in the ACE charter or otherwise >>>>>> documented? >>>>>> >>>>>>> >>>>>>> So the legacy SEP2.0*) support that seems to be the issue behind th= is >>>>>>> disagreement can easily be accommodated without the WG losing its >>>>>>> focus. >>>>>> >>>>>> By "legacy" do you mean "not part of a walled garden"? >>>>>> >>>>>> - Ralph >>>>>> >>>>>>> >>>>>>> Gr=FC=DFe, Carsten >>>>>>> >>>>>>> *) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP= , >>>>>>> TLS, TCP. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ace mailing list >>>>>>> Ace@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ace >>>>>> >>>>>> _______________________________________________ >>>>>> Ace mailing list >>>>>> Ace@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ace >>>>> >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Mon Mar 10 09:14:52 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FB01A056D for ; Mon, 10 Mar 2014 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGVTWP5Z6jLc for ; Mon, 10 Mar 2014 09:14:39 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 30B8E1A04E8 for ; Mon, 10 Mar 2014 09:14:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B09CE206B1 for ; Mon, 10 Mar 2014 12:09:28 -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 x7zc-RFq73WF for ; Mon, 10 Mar 2014 12:09:28 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (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 ; Mon, 10 Mar 2014 12:09:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 99BC883F8E; Mon, 10 Mar 2014 12:14:07 -0400 (EDT) From: Sam Hartman To: ace@ietf.org Date: Mon, 10 Mar 2014 12:14:07 -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 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1CRypjJ1dfzmySUlk9dbBj5eHJs Subject: [Ace] Balancing How Tightly Coupled against Reasonable Options X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:14:48 -0000 At the BOF I was a strong proponent of scoping the solution only to COAP+DTLS. I've thought more about that. I still favor that. However, I've realized that I had a bunch of complex reasoning behind that. In the broader Internet, interoperability tends to be more important than optimization. It's more important to have fewer solutions than to have solutions exactly matched to the environment. The solution needs to bmeet the requirements, but extra options, complexity, code size, etc is preferable to having multiple solutions that do not interoperate. As several people pointed out, you need a trusted element to convert one authentication scheme into another; same is true for authorization schemes. However, in the constrained environment, it's often more important that a solution work within the constraints than it is to re-use technology. I would strongly object to chartering work here that's going to effectively be another generic authentication mechanism that doesn't have inherent properties that strongly bind it to the constrained space. So, I've thought about this in terms of the COAP+DTLS question and come up with the following. The point of doing this seems to be to minimize code size and complexity and re-use DICE work across ACE. So, you could design a system where DTLS was the only crypto you needed, where cipher and hash selection was optimized between your COAP security and your authentication. You could solve challenges with DTLS and re-use the work. This sort of inherently binds the problem to COAP speakers including constrained devices, software written explicitly for constrained devices and for trusted security proxies that interface with the rest of the world. Examples of work I'd support with this scoping: * For ABFAB: ** An EAP method that worked well with DICE/DTLS ** Removing unnecessary EAP round trips ** RADIUS over DTLS with DICE constraints if you want to put an authorization server on a constrained device. ** Compression/better encodings of authorization information. Alternatively, we could look at things that proxies can do without being trusted. Ways of reversably transforming other authentication technologies for use in constrained environments more broadly than COAP+DTLS. Examples include: * For ABFAB: ** Reversable ways of removing EAP round trips: avoiding EAP request/identity; taking success indications from a method to avoid need for eap failure and eap success messages * For OAUTH: ** a losless compression of signed tokens that can represent anything, but hapeens to be very efficient if the token generator is constrained-device friendly ** more efficient encoding of the HTTP parts of OAUTH that do not impact signature validity What I would not support is something that was OAUTH-like or ABFAB-like or PKI-like but was neither tied to COAP+DTLS nor transformable by an untrusted proxy without keys. I think that work would strike an inappropriate balance with technology re-use and interoperability across the wider Internet. If we need a more efficient OAUTH or EAP, do that work in the OAUTH or EMU workings groups, not here. Actually get the right people in the room to balance that tradeoff well. --Sam From nobody Mon Mar 10 18:02:55 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85521A067E for ; Mon, 10 Mar 2014 18:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyGeHj1UQlxV for ; Mon, 10 Mar 2014 18:02:50 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 181131A0671 for ; Mon, 10 Mar 2014 18:02:49 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 518BA2002A; Mon, 10 Mar 2014 22:21:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AF01B647C9; Mon, 10 Mar 2014 21:02:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 985E5647C8; Mon, 10 Mar 2014 21:02:42 -0400 (EDT) From: Michael Richardson To: Margaret Wasserman In-Reply-To: References: <5317357B.6020407@gmx.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/PSLOufcOaAz9G1UNxpT8rvVSXSA Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 01:02:52 -0000 --=-=-= Margaret Wasserman wrote: > I think that requiring CoAP/DTLS to be used on interface I or III > overly constrains the situation and effectively requires us to create > anew authorization and authentication protocol. I think we should > avoid doing that, if at all possible. How would you feel if CoAP/DTLS was a MAY for I/III, but that HTTP/TLS was also a MAY? (Perhaps both are MTI, but the I/III interaction MAY use either) > Please note that implementing CoAP/DTLS on the Client and Resource > Server DOES NOT PREVENT those nodes from ALSO implementing other > protocols. For instance an unconstrained Client, such as a building > control unit, may implement CoAP/DTLS (plus whatever auth solution we > choose/design) to talk to sensors and actuators AND provide a standard > HTTP/TLS web server as a northbound interface for users to control the > building from anywhere on the Internet. In my thoughts, we would be > expecting the Client and Server to _at least_ implement CoAP/DTLS. > They could also implement other protocols, depending on how resource > constrained they are (or aren't). Agreed... Or to put it another way: It's okay if my coffee maker also makes toast. As long as it makes coffee. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUx5gsoqHRg3pndX9AQKKZwQA4cnam/68r5mlN/lK7Se0faxNaXtxxk2H XcDI5lSbMpuusyI0J9nyfYoGDfFG2yep6ZaEtor7k3AN9k+JQJs6qNdFQarP1xjf VYNHJQZMhqHmj9vniJCszfeFtVnwvFTRb3J8nT//r/1yXBUYMQoWblX2OxSBRiBk jIFq37JZ968= =3EKo -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 11 00:46:11 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217A71A027F for ; Tue, 11 Mar 2014 00:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d04DGJ-wSgkf for ; Tue, 11 Mar 2014 00:46:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77C1A024B for ; Tue, 11 Mar 2014 00:46:07 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MF5C3-1WP8mh3beF-00GE0P for ; Tue, 11 Mar 2014 08:46:01 +0100 Message-ID: <531EBEDE.4050702@gmx.net> Date: Tue, 11 Mar 2014 08:44:30 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nenSV02peoGIXp1Kr65QgkwbRUxaFW1d6" X-Provags-ID: V03:K0:4xKW6UDECB22Szue3Ma4shu5M8bclb+Trfgr8nKbpSLvFnozCWk wzjWm7ZcYJ2uB46wsIOqBcd1kY0GWQB2LkuaBfLR6gW9270r3vT/RRA00AcCbY7Qv2a/Rw0 czcJTELplIGOPsVnZDEfRdCS14WMDOLnOJcGwUJQfmed0+QST0vJAySRbocYpVRlvAglKKu eO8ENskGMEm33Tjq2yj7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/9D0IDPnNr9ZK8xQufaDcX2TxQlc Subject: [Ace] Your Charter Scoping Feedback X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 07:46:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nenSV02peoGIXp1Kr65QgkwbRUxaFW1d6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, thanks for the feedback on the charter scoping discussion. I just read through the various remarks sent to the list. Looking at the diagram again I believe I hear the following feedback. +---------------+ | Authorization | +--------------------------->| Server | | (I) +---------------+ | ^ | | | | | | III | | | | | | v v +-----------+ +-----+-----+ | | II | Resource | | Client | <..................>| Server | +-----------+ +-----------+ For II we would start our work on a solution that re-uses CoAP and DTLS since the client and the resource server are likely going to be constrained. We would, however, add text to the charter that the outcome of that work has to also work for a not-so-much constrained environment that uses HTTP/TLS on interface II. Various people raised the question of proxies and, in further discussions, it appears to me that those proxies are used for protocol translation to interface existing deployment. Following the suggestion Michael provided I think we should also put text in the charter that we will look into the proxying case once we have an initial solution approach selected to determine how the interworking would be accomplished. It is a bit premature to answer that question at this point in time. Michael even went one step further and suggested running code and that indeed sounds like an interesting idea. Concerning interfaces I and III I got a mixed reaction. I believe that this is partially caused by the nature of different solutions you all have in mind. For some solutions there is no interface III, for example. In other cases there is no interface I. My suggestion is to avoid mandating a specific approach in the charter right now and rather wait for a solution preference to emerge in the group. How does this sound? Is this a reasonable compromise? In my subsequent mail I will make a proposal for the updated charter text= =2E Ciao Hannes --nenSV02peoGIXp1Kr65QgkwbRUxaFW1d6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTHr7fAAoJEGhJURNOOiAtuJUH/iaXOHRFrv8xBRiIzSe8HiRP WM+hVZIUBOZtM2nYGvMStFQytMBA3bqDomthUdT/1V7tkK4wQa8scpByRRufrzcX Bf3YMavzi/qQMcJiANbLRk7JhdrRMoKMvyCYhwVAcFrQZp+fQhg47weWlm5k0Tni IOycty46BbZBtC4gGYhnPe6X+t748VqUMYfsHurY9rg6iQLtX+Kzw97xdMS/2Lga usPhS1AA35p4PdUQiUQAvVCiuu/MhLAB3hPjFDjlBv6yoUw5NGMFNxizlb/VnqFQ pKGqQBcR5DD7ntaca6rnAwSqiGvK4jqmfbpTrUVz+RCXzrslgomgS8+nLB4jveQ= =CLsH -----END PGP SIGNATURE----- --nenSV02peoGIXp1Kr65QgkwbRUxaFW1d6-- From nobody Tue Mar 11 00:52:55 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B6C1A02A0 for ; Tue, 11 Mar 2014 00:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gxvfEHkqzyi for ; Tue, 11 Mar 2014 00:52:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 673331A0139 for ; Tue, 11 Mar 2014 00:52:41 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MC3zg-1WW7By2LSK-008pIv for ; Tue, 11 Mar 2014 08:52:34 +0100 Message-ID: <531EC063.3000903@gmx.net> Date: Tue, 11 Mar 2014 08:50:59 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9J9b4e3CmvlwlWv0FiS5rp6r3IRfWucXv" X-Provags-ID: V03:K0:5sOhvzOeSnc4PcgIsSssxZ/Z7qeXhkZm47717+umODRb1qK5EO0 tJbiSWKZ6rzjUMBti8gDaCjrCwsrbwV+Z/zraem4ooWMzjpFrylo9bGpnU47nlOLOWzmd2F gB/W1EyOuVELsIajoh05i2rrZU8MeEuEZdd4DKlR3QHfIoKd2lb/ypB1nlhJ7oAnVp7SNMH SSnddXBPouXa0/1Zj3RNQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/D3xL85-ESQCLfla5b20VlTZbSGY Subject: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 07:52:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9J9b4e3CmvlwlWv0FiS5rp6r3IRfWucXv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I have taken the feedback from the meeting and the recent discussions on the mailing list and produced a new strawman proposal. The changes include: * Added the focus on DTLS/CoAP with an indication that we will check a candidate solution for suitability with HTTP/TLS. * Added text to indicate that we will also verify the suitability of the solution for use with protocol translation proxies. * Simplified the task list by removing solution specific items. * Merged several items on the task list (use cases, requirements, and protocol design guidelines). Followed the suggestion to use of a Wiki for capturing those. What do you think? ----- Draft Charter V0.5 - Authentication and Authorization for Constrained Environment (ACE) The IETF has recently developed protocols for use in environments where network nodes are limited in CPU, memory, and power. It was observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained devices and networks. An example of such a protocol is the Constrained Application Protocol (CoAP). components As in other environments, authentication and authorization question also arise in environments with constrained nodes and networks. For example, a door lock has to authorize the person seeking access using a "digital key". Where are the authorization decisions stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be granted to other persons temporarily? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside the constrained environment. But in constrained environment, additional requirements pose challenges for the use of various security protocols. The IETF has a long history in developing three party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization, and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences are motivated by the main deployment use cases they were designed for. Requirements derived from use cases indicate the suitability of already existing work, such as OAuth, as a solution for constrained environments. These protocols were, however, not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface for obtaining the consent of the user and the inability of embedded devices to contact an authorization server in real-time with every access request due to intermittent connectivity, etc. This working group therefore aims for a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments. As a starting point, the working group will assume that access to resources offered by a resource server by a client devices takes place using CoAP and is protected by DTLS. Both resource server and client may be resource constraint. This access will be mediated by an authorization server, which does not suffer from the same resource limitations. Existing authentication and authorization protocols are used and re-applied for use with constrained devices, where applicable. This requires relevant specifications to be reviewed for suitability, selecting a subset of them, restricting the options within each of the specifications. Some functionalities may, however, not be available in existing protocols and for those cases new functionality has to be standardized. Thus, existing work can be leveraged and the group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of IoT devices offering increased security. Once progress in identifying suitable candidate solutions has been made the working group will verify whether the same mechanism are also applicable beyond the use of CoAP and DTLS. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Furthermore, to guarantee smooth transition the integration with existing deployment will be studied. This particularly concerns the use of protocol translation proxies. To be successful this working group requires expertise in security, privacy, and a good understanding of usability in the constrained environment space. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. The working group has the following tasks (in this order): 1) The working group Wiki pages will be used to document use cases, requirements, and protocol design criteria. This work will guide the identification of suitable protocol mechanisms. 2) Selection of an authentication and authorization protocol for constrained environments. 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy deployments. ----- Ciao Hannes --9J9b4e3CmvlwlWv0FiS5rp6r3IRfWucXv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTHsBjAAoJEGhJURNOOiAtZo4H/iFHnkRo3bCv7Rm/kopVrSlD y/+TQv+JP9Bu/zcVa5HIJefQFuA8fTCzUut5+cV1sSEVFALj+Y40wUihwbr/5Cyp tdcp4YBkEk0FMXDVPrWpxMd9PjCuMvp7DM+HhaxpwFLtjb96x3csljA1WjT+5RvV wvLlpGz42vC/z8TaFhP1ilketNI9qZw1vFd2h0Qqg8ShlqifGW+ltEUOkB/Wnmlv vYk2SoCfStx+48JJsyOPcH/IMWdw3ByqzHTKNkmfSG9/tLFWPkD+LtxIvJWsztIt WIwXlla43HnJ2Ao/5TmgSVLXEOOaNnukAaBPkzAXtQOUd3U/CxmNttiWx5fI2B8= =Hf5q -----END PGP SIGNATURE----- --9J9b4e3CmvlwlWv0FiS5rp6r3IRfWucXv-- From nobody Tue Mar 11 02:26:34 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4660A1A03E2 for ; Tue, 11 Mar 2014 02:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InRMVd9_QMfF for ; Tue, 11 Mar 2014 02:26:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B1DD81A0381 for ; Tue, 11 Mar 2014 02:26:29 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-36-531ed6bff29f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 59.86.10875.FB6DE135; Tue, 11 Mar 2014 10:26:23 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 11 Mar 2014 10:26:23 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "ace@ietf.org" Thread-Topic: ACE Charter - connectivity assumptions Thread-Index: AQHPPQv384KEX3YIRUSd5/kxwiLycQ== Date: Tue, 11 Mar 2014 09:26:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje7+a3LBBscWqVt8/9bD7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPv7X7EXfOWr+Px9N3sDYxdPFyMHh4SAicTcfqkuRk4gU0zi wr31bF2MXBxCAocYJe5/v8YO4SxhlDh0ZyEbSBWbgKvEgQfvmECaRQQUJa4/SgQJCwvoS/x5 vpwRxBYBmrlqzldmCFtP4uH8Y+wgNouAqsSuP4eYQGxeAXOJzg+vwUYyAi3+fmoNWJxZQFzi 1pP5TBAHCUgs2XOeGcIWlXj5+B8riC0KNPPeo7ksEHEliRXbLzFC9OpJ3Jg6hQ3kNGYBa4m/ LdEQYW2JZQtfM0OsFZQ4OfMJywRG0VlIts1C0j0LoXsWku5ZSLoXMLKuYmTPTczMSS833MQI jISDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhNNk9K kvnRl/Fm3kWduqvm09856qieaajrMcxJCtTwl7d76RZbsMSEff/Gc/FFb5++ePBgobpYgLNY Yaqwv2pkSIvChJ5NJ5wOyk9ce+Ilf4np4djucjU/jXM3ApJSKxa1/qrfbM+tdnL7m3VumXWH 4k7Pf83Qe6uH0+KDy8HU2qxbRZnymUosxRmJhlrMRcWJAAHaYipSAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/10hhM1S55v6nCVtBdpDQSPEcFvU Subject: [Ace] ACE Charter - connectivity assumptions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 09:26:33 -0000 During the BOF it was requested to be more specific about the connectivity assumptions of the various nodes, more specifically whether it could be assumed that the RS or the Client could connect to the AS. The discussion was very focused on the particular use case presented at the BOF. Here are some starting points for further discussion. 1. The discussion relates to Client or RS connectivity to the AS for obtaining relevant authorization information. If valid authorization info is already available to the RS, it should not be necessary to connect to the AS.=20 2. It was acknowledged that in the particular use case (container transport at sea) Internet connectivity could not be assumed. Even if this hadn=B9t been the case, e.g. truck/train transport or other use case, we should not take for granted that billions of devices are always connected just because it is theoretically possible. Internet connectivity has a cost and low cost is one of the reasons why constrained devices are at all used. There may be some need for configuration needed to secure connectivity, which may be missing if the environment changes as was illustrated by the use case. Etc. . With this in mind, we should assume that for certain use cases the constrained Client or RS may be disconnected from the Internet for periods of time. 3. Even if the AS is not a constrained device it may be disconnected from time to other. For some use cases, AS functionality may be implemented in devices which are not always available, e.g. the Resource Owner=B9s smartphone, home server or some other device which may be occasionally switched off or disconnected. In general we should assume that Client and RS may have intermittent connectivity with the AS, and in particular that it cannot be guaranteed that there is connectivity to the AS at the time of the access request. G=F6ran From nobody Tue Mar 11 08:49:40 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1A51A0772 for ; Tue, 11 Mar 2014 08:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK2o8xnUkYuX for ; Tue, 11 Mar 2014 08:49:29 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id EE6241A076F for ; Tue, 11 Mar 2014 08:49:27 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Tue, 11 Mar 2014 15:49:20 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Tue, 11 Mar 2014 08:49:28 -0700 From: Zach Shelby To: Hannes Tschofenig Date: Tue, 11 Mar 2014 08:49:19 -0700 Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: Ac89QXuWodwZ5oOzT0ya7A3XuBxgPg== Message-ID: <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> References: <531EC063.3000903@gmx.net> In-Reply-To: <531EC063.3000903@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114031115492105702 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ace/VPphMlM_3yFmgpe8cZodAvXd9P8 Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:49:33 -0000 Hannes, I am happy with this charter with one exception. The proxy item here seems = to be more of a distraction than anything else, and will probably result in= increased complexity. Was proxy support maybe just a misunderstanding? Do = we really see the need for a proxy in the middle of I or III? I think what we really want here is to make sure that e.g. even through I i= s based on HTTP/TLS, II and III for example can run CoAP/DTLS. In other wor= ds, some interfaces can be constrained while others are not. I think the ch= arter already covers this fine. So my proposal would be to remove the mention of protocol translation proxi= es. If we really see the need for this some day in the future, it could be = tackled then. Zach On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig = wrote: > Hi all, > > I have taken the feedback from the meeting and the recent discussions on > the mailing list and produced a new strawman proposal. > > The changes include: > * Added the focus on DTLS/CoAP with an indication that we will check a > candidate solution for suitability with HTTP/TLS. > * Added text to indicate that we will also verify the suitability of > the solution for use with protocol translation proxies. > * Simplified the task list by removing solution specific items. > * Merged several items on the task list (use cases, requirements, and > protocol design guidelines). Followed the suggestion to use of a Wiki > for capturing those. > > What do you think? > > ----- > > Draft Charter V0.5 - Authentication and Authorization for Constrained > Environment (ACE) > > The IETF has recently developed protocols for use in environments where > network nodes are limited in CPU, memory, and power. It was observed > that Internet protocols can be applied to these constrained > environments, often only requiring minor tweaking and profiling. In > other cases, new protocols have been defined to address the specific > requirements of constrained devices and networks. An example of such a > protocol is the Constrained Application Protocol (CoAP). > components > As in other environments, authentication and authorization question also > arise in environments with constrained nodes and networks. For example, > a door lock has to authorize the person seeking access using a "digital > key". Where are the authorization decisions stored? How does the digital > key communicate with the lock? Does the lock interact with an > authorization server to obtain authorization information? How can access > be granted to other persons temporarily? How can access be revoked? > These types of questions have been answered by existing protocols for > use cases outside the constrained environment. But in constrained > environment, additional requirements pose challenges for the use of > various security protocols. > > The IETF has a long history in developing three party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > Authorization, and Accounting (AAA) infrastructure, and the Web > Authorization Protocol (OAuth). All these protocols enjoy widespread > deployment on the Internet. Although they all aim to solve a similar > goal, at an abstract level, they offer quite different functions and > utilize different message exchanges. These differences are motivated by > the main deployment use cases they were designed for. > > Requirements derived from use cases indicate the suitability of already > existing work, such as OAuth, as a solution for constrained > environments. These protocols were, however, not optimized for > constrained environments. Additional requirements that need to be taken > into account are the lack of a suitable user-interface for obtaining the > consent of the user and the inability of embedded devices to contact an > authorization server in real-time with every access request due to > intermittent connectivity, etc. > > This working group therefore aims for a standardized solution for > authentication and authorization to enable authorized access to > resources in constrained environments. As a starting point, the working > group will assume that access to resources offered by a resource server > by a client devices takes place using CoAP and is protected by DTLS. > Both resource server and client may be resource constraint. This access > will be mediated by an authorization server, which does not suffer from > the same resource limitations. > > Existing authentication and authorization protocols are used and > re-applied for use with constrained devices, where applicable. This > requires relevant specifications to be reviewed for suitability, > selecting a subset of them, restricting the options within each of the > specifications. Some functionalities may, however, not be available in > existing protocols and for those cases new functionality has to be > standardized. Thus, existing work can be leveraged and the group > benefits from available security analysis, implementation, and > deployment experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of IoT devices offering increased security. > > Once progress in identifying suitable candidate solutions has been made > the working group will verify whether the same mechanism are also > applicable beyond the use of CoAP and DTLS. In particular, the ability > to use the developed solution over HTTP and TLS will be investigated. > Furthermore, to guarantee smooth transition the integration with > existing deployment will be studied. This particularly concerns the use > of protocol translation proxies. > > To be successful this working group requires expertise in security, > privacy, and a good understanding of usability in the constrained > environment space. This work does not make the assumption that the party > offering application layer services is always the same party offering > network access services. > > The working group has the following tasks (in this order): > > 1) The working group Wiki pages will be used to document use cases, > requirements, and protocol design criteria. This work will guide the > identification of suitable protocol mechanisms. > > 2) Selection of an authentication and authorization protocol for > constrained environments. > > 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy > deployments. > > ----- > > Ciao > Hannes > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Tue Mar 11 11:55:41 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355C31A07B5; Tue, 11 Mar 2014 11:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf9j4uqAPInM; Tue, 11 Mar 2014 11:55:36 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 1138A1A077D; Tue, 11 Mar 2014 11:55:33 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7933B23E24C2; Tue, 11 Mar 2014 18:55:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRhVMWAAjeSJ; Tue, 11 Mar 2014 19:55:21 +0100 (CET) Received: from kopoli (g226057108.adsl.alicedsl.de [92.226.57.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 298AD23E24BC; Tue, 11 Mar 2014 19:55:21 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Tue, 11 Mar 2014 19:55:19 +0100 Message-ID: <00f101cf3d5b$736152b0$5a23f810$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac89W3Ggj+VLatgRRfeVFuptbnG7TA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/ace/oZGutxBZ_IVqz0xMAZq3W-5hzsU Cc: secauth@ietf.org Subject: [Ace] a possible solution candidate? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 18:55:38 -0000 Hi, I just get to know this WG during IETF in London. Since I am also working in secure authentication and authorization in a non-WG group (CC), but in general and not only for constrained devices. In other words, the scope of your mailinglist is a small part of that. The outcome of secauth will be an API that allows the application layers' services or other layers' services to use this API for authentication purposes. Based on the needs, one can also integrate it with other approaches an duse it for securer authentication and at the same time avoid IP spoofing. This is why the work of this mailinglist grabbed my attention. Before IETF I was in a process of preparing a requirement document for using a network layer approach for authentication in other layers and still working on it (probably you can read more about my purpose there). One of the solution space approach that I thought might be useful for the start was one of my draft that is called SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ). -----The new version of this draft will be coming soon (I know the current version is messy.. :-| )------ I thought maybe you also find it useful as a candidate solution for your authentication purposes. I try to explain how SSAS can be helpful General advantages - Prevent IP spoofing (binding between the public key and the IP address) - The authentication can be only based on IP address (or one can also integrate it with other approaches) - Since IP spoofing can prevents other attacks such as MITM, TCP/UDP amplifications, - It uses a short key size algorithm so that it avoids the use of large memories Some of other advantages: - It is enough that the two communication nodes only know the IP address of each other, then they can ensure that there is no MITM. - It does not need to check the keys up to certain level to ensure that this key belongs to this node with this IP address (like what is needed for TLS if one wants to ensure about the key authorization). - It doesn't need to buy a certificate for each single nodes in order to provide the node with a secure TLS or SSL authentication etc. At the moment I integrated this approach for DNS confidentiality, data integrity and secure authentication (please refer to these slides http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-2.pdf ). I also saw a paper that integrated SSAS as a secure authentication purposes in SIP protocol. This is because in SIP, an attacker can easily spoof the identity of the two ends of communication nodes. Since SSAS prevents IP spoofing, this prevents identity spoofing as well (if the identity is the IP address). One disadvantage of this approach was that it only supports iPv6, I also tried to cover it (Please check the approach in the slides for CGA-TSIG). So, the support of IPv4 will appear in the next version of draft. If you have any question, do not hesitate to ask. Thanks, Best, Hosnieh From nobody Tue Mar 11 12:06:03 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8F51A07E9 for ; Tue, 11 Mar 2014 12:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7_QhkbSmBwZ for ; Tue, 11 Mar 2014 12:05:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 775731A07E7 for ; Tue, 11 Mar 2014 12:05:59 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MWCKz-1Wgupj3ZGb-00XLZP; Tue, 11 Mar 2014 20:05:51 +0100 Message-ID: <531F5B7C.40101@gmx.net> Date: Tue, 11 Mar 2014 19:52:44 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hosnieh Rafiee , Ace@ietf.org References: <00f101cf3d5b$736152b0$5a23f810$@rozanak.com> In-Reply-To: <00f101cf3d5b$736152b0$5a23f810$@rozanak.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2sfPS8UbdswDvO1hxrho8HCUKCIkRbOnD" X-Provags-ID: V03:K0:fEPR/yFKtjzGltb/qwZYN2swgsWcj7eVY+NPjH6Yi152mp0Udrm vzU2EU8KGpoM2Xb/4eksoO5VJbYaiCN3hwrrMBKWDEEg8B8lkCBYG7KNTOCSVt0wfDecexD 157oLPZjL8Ecmk5iqbqZUkBTpJh42TtUgQx9J7qfCrNt1Gdph1jWS55X+9T3ZcGZoQQRXHR NpCR3oiW5p6+as6bZ+wSA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/qM1mqZ_oWe-B0Y1jfTNEEgvZDhQ Subject: Re: [Ace] a possible solution candidate? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:06:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2sfPS8UbdswDvO1hxrho8HCUKCIkRbOnD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hosnieh my initial reaction is that those are two separate efforts since we are focusing on application layer authentication and authorization. If you take a quick look at the updated charter text you will see the different focus: https://www.ietf.org/mail-archive/web/ace/current/msg00346.html Ciao Hannes On 03/11/2014 07:55 PM, Hosnieh Rafiee wrote: > Hi, >=20 > I just get to know this WG during IETF in London. Since I am also worki= ng in > secure authentication and authorization in a non-WG group (CC), but in > general and not only for constrained devices. In other words, the scope= of > your mailinglist is a small part of that. The outcome of secauth will b= e an > API that allows the application layers' services or other layers' servi= ces > to use this API for authentication purposes. Based on the needs, one ca= n > also integrate it with other approaches an duse it for securer > authentication and at the same time avoid IP spoofing. This is why the = work > of this mailinglist grabbed my attention. Before IETF I was in a proces= s of > preparing a requirement document for using a network layer approach for= > authentication in other layers and still working on it (probably you ca= n > read more about my purpose there). One of the solution space approach t= hat I > thought might be useful for the start was one of my draft that is calle= d > SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ). > -----The new version of this draft will be coming soon (I know the curr= ent > version is messy.. :-| )------ >=20 > I thought maybe you also find it useful as a candidate solution for you= r > authentication purposes. I try to explain how SSAS can be helpful >=20 > General advantages > - Prevent IP spoofing (binding between the public key and the IP addre= ss) > - The authentication can be only based on IP address (or one can also > integrate it with other approaches) > - Since IP spoofing can prevents other attacks such as MITM, TCP/UDP > amplifications,=20 > - It uses a short key size algorithm so that it avoids the use of large= > memories >=20 > Some of other advantages: > - It is enough that the two communication nodes only know the IP addres= s of > each other, then they can ensure that there is no MITM. > - It does not need to check the keys up to certain level to ensure that= this > key belongs to this node with this IP address (like what is needed for = TLS > if one wants to ensure about the key authorization). > - It doesn't need to buy a certificate for each single nodes in order = to > provide the node with a secure TLS or SSL authentication > etc. >=20 >=20 >=20 > At the moment I integrated this approach for DNS confidentiality, data > integrity and secure authentication (please refer to these slides > http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-2.pdf ). I al= so > saw a paper that integrated SSAS as a secure authentication purposes in= SIP > protocol. This is because in SIP, an attacker can easily spoof the iden= tity > of the two ends of communication nodes. Since SSAS prevents IP spoofing= , > this prevents identity spoofing as well (if the identity is the IP addr= ess). >=20 > One disadvantage of this approach was that it only supports iPv6, I als= o > tried to cover it (Please check the approach in the slides for CGA-TSIG= ). > So, the support of IPv4 will appear in the next version of draft.=20 >=20 > If you have any question, do not hesitate to ask. >=20 > Thanks, > Best, > Hosnieh >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --2sfPS8UbdswDvO1hxrho8HCUKCIkRbOnD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTH1t8AAoJEGhJURNOOiAt9b4H/RWYAAIxETqNz2ovgsd0s25r 472tJEWSTBDXeV9sCzkJhHH8fbV5SNlssjlbzZvuvmzJPKR07XTyEL+Suq8+7SME 9O2RKd7RqDV1O5d87cWS6/gvlhGoXQGgqLL6LZb/5Lx2A0I/afiWarbmnKkMuy5w 1DD7uPQ5lWLkr/64ZxOIXNfNYLy7KCKWf9+DrP41UlhqggC9PPbEKit+ROtxd/sf PL8Z0Q41CX8chuPX7sSyDsV3P3+BJZBogE5hmRC4Mb0XJPwIqiJ0mHghvEogjTmF pce48gj5HiQsoMTWRNJYpYiS1PVEAGuSV/XWbFrTKtIHWqcj9tQ5NELpHDOQy9k= =Xjzu -----END PGP SIGNATURE----- --2sfPS8UbdswDvO1hxrho8HCUKCIkRbOnD-- From nobody Tue Mar 11 12:22:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E994D1A07C5 for ; Tue, 11 Mar 2014 12:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyEiZxrtkN8z for ; Tue, 11 Mar 2014 12:22:35 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 910481A07B9 for ; Tue, 11 Mar 2014 12:22:35 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id CC1B423E24C2; Tue, 11 Mar 2014 19:22:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlafhQ7yQHxr; Tue, 11 Mar 2014 20:22:25 +0100 (CET) Received: from kopoli (g226057108.adsl.alicedsl.de [92.226.57.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id B138123E24BC; Tue, 11 Mar 2014 20:22:25 +0100 (CET) From: "Hosnieh Rafiee" To: "'Hannes Tschofenig'" , References: <00f101cf3d5b$736152b0$5a23f810$@rozanak.com> <531F5B7C.40101@gmx.net> In-Reply-To: <531F5B7C.40101@gmx.net> Date: Tue, 11 Mar 2014 20:22:24 +0100 Message-ID: <010401cf3d5f$3bb26c10$b3174430$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNO+RZCuMSzNq65zUwJN+zsSn372wJ1ln1Xl8kcB+A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/ace/EwAHIEBY7cVN1roZyj2tGE47mUE Subject: Re: [Ace] a possible solution candidate? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:22:38 -0000 Hi Hannes, Thanks for your quick response. I know it is application layer authentication. The purpose of secauth isn't also to merge the application layer protocols with network layer protocols but only use the parameters used to secure network layer in other layers. However, as I explained earlier, secauth is not only for CoAP devices. In other words, if an application wants to use this approach, it only carries the parameters used in network layer for security purposes in the TCP or UDP messages for authentication purposes. This is the same way as I've integrated it with DNS. DNS is also application layer service. It only uses a cached data available to the service that supports authentication. This is why I thought it might be useful here too. In any case, I am also working in secauth on authentication and authorization purposes for application layer and other layer and make this or any similar approach as a API available for this purpose. Best, Hosnieh > > Hi Hosnieh > > my initial reaction is that those are two separate efforts since we are focusing > on application layer authentication and authorization. > > If you take a quick look at the updated charter text you will see the different > focus: > https://www.ietf.org/mail-archive/web/ace/current/msg00346.html > > Ciao > Hannes From nobody Tue Mar 11 12:32:00 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7EE1A07C3 for ; Tue, 11 Mar 2014 12:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F98jt2KfSw2d for ; Tue, 11 Mar 2014 12:31:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9AE1A04AB for ; Tue, 11 Mar 2014 12:31:55 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MhMg2-1Wa3bl3Sb4-00MftD; Tue, 11 Mar 2014 20:31:48 +0100 Message-ID: <531F6177.5040704@gmx.net> Date: Tue, 11 Mar 2014 20:18:15 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Dr. Corinna Schmitt" , ace@ietf.org References: <53086642.5050609@gmx.net> <53134E58.20608@ifi.uzh.ch> In-Reply-To: <53134E58.20608@ifi.uzh.ch> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ahRgTev595FLwL9vJTGseqMswveqkGxCR" X-Provags-ID: V03:K0:SMowy18k8CLJh+4smRqh8Mcxcyep6rDaN76sSQL2NqYFTSb94np /BFxlbXhjimZuRRqP+KU90vjBbaJZQbN0EJ0OWEIUNrNZTiQclijWr4GYa2sfrBRt8bZIaK adbJI1IcVUHrld31WjQwimHWdTZGtAohOMhzUjDd5f5VhbS4XRbyuD+34+9+5cEr3VwBqu3 Xzw7URfp6YLhvlo7es+Mg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/I1TSjGQnjh5o3mtRFaMiFVvQHM8 Cc: Burkhard Stiller Subject: Re: [Ace] draft-schmitt-two-way-authentication-for-iot-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:31:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ahRgTev595FLwL9vJTGseqMswveqkGxCR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Corinna, thanks for the response. My suggestion would be to produce a write-up that is of generic use (independent from your specific implementation and your EU funded project= ). However, given the charter discussions and the BOF I have my doubts whether the work would meet many of the requirements outlined in https://tools.ietf.org/html/draft-seitz-ace-usecases-00. Ciao Hannes On 03/02/2014 04:29 PM, Dr. Corinna Schmitt wrote: > Dear Hannes, >> Hi Corinna, Hi Burkhard, >> >> thanks for your document. I have read through it and I ran into a few >> questions. Your response would help me to better understand the propos= ed >> idea. > Thanks for reading the draft and make comments to it to improve it. Som= e > comments can be answered right away. >> 1) Why do you assume IEEE 802.15.4? Currently it seems that the 15.4 >> radio will mostly be used in specialized industry segments only. Is >> there anything in the document that would make the idea less suitable >> for other radio technologies, for example BTLE? > Potentially the proposed solution can work on every stack you like. So > you can do an implementation independently of IEEE 802.15.4. > We put IEEE 802.15.4 there, because our used stack (BLIP) uses it. >> 2) The assumed network stack does not show 6lowpan. Was this intention= al? > Same as above. You can use the stack you want. So also 6lowpan can be > used. It depends n you what you require and what you want to support. >> 3) You show RPL in the stack and I was wondering whether you assume it= >> being mandatory to implement for your assumed architecture? It does no= t >> seem to show up elsewhere in the document. It appears to be irrelevant= >> for your design. > RPL was just mentioned due to our other publications. Currently our pla= n > is to change to RPL (CoAP) in the future. >> 4) Subscriber identity: You write -- >> " >> The identity of a default subscriber is usually preconfigured on a >> publisher before it is deployed. >> " >> >> Could you explain more what you assume is pre-configured and where it = is >> preconfigured? > Here pre-configures means that our devices are equipped with the > certification during compiling and programming them before deployment. > This is due to the application scenario we support at the moment. Befor= e > deploying the device you have to run to steps: First creation of > certificate, and second compiling code and play it on the device. >> I would also suggest to avoid the term subscriber since it has two oth= er >> meanings that might confuse: >> a) The term subscriber is often used in context of telecommunication = as >> the user who has a contract with a telecommunication operator. >> b) The second use is in context of protocols that use asynchronous >> communication (like XMPP). >> >> I believe your notion of subscriber does not relate to those two >> existing uses. I guess you are more using the term subscriber to refer= >> to a device that wants some data from a sensor. Is this correct? > Thanks for the hint. Yes you are right. The subscriber should be a > device that wants data from the sensor. > Usually this is one outside of the WSN. Do you have a suggestion for ne= w > name? >> 5) Roles in your architecture. >> >> It seems that you assume that the IoT devices are publishers and that >> there are subscribers who talk to these publishers. In some other case= s >> I have seen architectures where the IoT devices (sensors) upload the >> data to some servers without having to act as servers themselves. In >> your architecture it feels like the sensor nodes implement the >> server-side functionality > That was not our intention. > Our network has push characteristics up to the server. Data publishing > runs over server, because it has more resources and, therefore, can > handle requests better. It is the gate to the world. > Pull is only performed if you require data (measurements) at a time tha= t > is not pre-defined. >> In Section 4.2.2 you write that you recommend an OpenSSL implementatio= n >> on the server side but the server-side would be the IoT device. While = it >> would be inappropriate to recommend a specific implementation in an IE= TF >> draft/RFC it also raises the questions about the expectations on the >> server-side. > Thanks for the hint. > We use OpenSSL on the server but not within the WSN. OpenSSL is used > especially for managing rights, requests, and certificates. >> 6. Certificate content >> >> In Section 4.2.2 you describe the content of a certificate and you >> indicate that the commonName is set to "localhost". It seems to be >> useless to include this in the certificate since a CA would not be abl= e >> to verify this identity information nor would any party verifying it b= e >> able to use it in a meaningful way. > Localhost in our case is a special IP address (here: sink). You are > right, we should rename it and make clear that it is an IP address. So > you can set is like you want. >> It also seems to be in violation of what you write in Section 5.2 wher= e >> you state that "every publisher in the network MUST have an unique >> identity.". >> >> You also indicated more complete information for inclusion in the >> certificate but it is not clear to me what purpose it serves. Could yo= u >> explain? > Will do it asap. >> 7. Privacy >> >> In Section 5 you indicate some privacy related aspects and you hint to= " >> access regulations based on legal and regulative implications". Could >> you briefly explain what those requirements are? > This part we put in due to the deployment and project relations we are > running at the moment. > Here it means that not every device can be able to access the data, for= > example, due to legal issues in the region (EU, CH, US rights). > This has to be stored central in the network and it has to be checked > before giving access and creating the corresponding access ticket. > Here we refer to the following publications: >=20 > Radhika Garg, Corinna Schmitt, Burkhard Stiller: /Investigating > Regulative Implications for User-generated Content and a Design > Proposal/; Degruyter, PIK-Praxis der Informationsverarbeitung und > Kommunikation, Vol. 36, No. 4, December 2013, ISSN 0930-5157, pp 1=9611= =2E > doi:10.1515/pik-2013-0042 URL= : > http://www.degruyter.com/view/j/piko.ahead-of-print/pik-2013-0042/pik-2= 013-0042.xml >=20 > Radhika Garg, Christos Tsiaras, Burkhard Stiller, Corinna Schmitt, > Daniel D=F6nni: /Deliverable D7.1 - Basics, Requirements, Scenarios, an= d > Architecture: In FLAMINGO/; Radhika Garg (Edt.), Z=FCrich, Switzerland,= > October 2013 >> 8. Use Cases. >> >> I suggest to omit the use cases from the document since the descriptio= n >> is too brief to be useful. A small remark: From my work in the emergen= cy >> services environment I had gotten the impression that there are no pla= ns >> to take sensor input directly when initiating alerts. In fact, sensor >> alerts do rarely even get directly to the emergency services authoriti= es >> but are rather pre-processed by an intermediate organization (by >> humans). Maybe you have spoken with other people, who have different >> plans. Where did you got your information from? > This section is based on discussion with our project partners within > SmartenIT (www.smartenit.eu) and Flamingo ( http://www.fp7-flamingo.eu)= =2E > >=20 >> 9. Architecture >> >> Figure 3 shows the architecture but it is a bit confusing since it is >> not clear what the boxes and the lines mean. The publisher is a box >> separate from the sensors and from the earlier description I thought >> that the sensors are actually the publishers. Furthermore, the gateway= >> was not discussed as a role up to that point in the document. The >> gateway shows up in Section 5.3 and its role confuses me. You write: >> >> " A sensor node has published its data, which is transmitted in >> direction to the global sink (cf. Figure 3 where global sink is >> located in the gateway component). >> " >> >> Does the sensor publish the data at the gateway? From the earlier >> sections I thought that the subscriber talks to the publisher instead.= >> Is the gateway the subscriber? Why doesn't the sensor uploads the data= >> to some server instead (which is frequently done in today's IoT >> deployments). > Lots of comments. > I will address and clarify them asap. > Furthermore, I will add a legend to the Figure and perhaps modify it > based on you aforementioned comments. >> Why do you call the entire document "two-way authentication" when the >> the two way authentication is just one small part of the overall >> authentication procedure. In fact the two-way authentication is used >> between the subscriber and the access control server (as shown in Figu= re >> 4), and between the publisher and the gateway. Furthermore, there has = to >> be some authentication between the subscriber and the publisher as wel= l >> (at least I hope so). >> >> What is the purpose of the access ticket? It shows up in Section 5.3 a= nd >> I wonder why there is a need for an access ticket when the two parties= >> (subscriber and publisher) already have a certificate. Why cannot you >> use the certificate for authentication with the publisher right away? >> >> Where do you see the access control server being deployed? Is this an >> entity in the local network or something you would have on the Interne= t? >> >> Why does the publisher have to authenticate to the gateway? From Figur= e >> 4 it is not clear whether the gateway is just an optional component or= >> an integral part of the architecture. >> >> The document does not explain what the access token is and how it is >> exchanged between the subscriber and the publisher. >> >> Btw, the term CA standards for Certification Authority rather than >> Certificate Authority. >=20 > Will be addressed soon. >> 10. Hardware requirements. >> >> Hardware requirements typically are not appropriate for IETF documents= =2E >> While you make the argument that an RSA-based public key cryptosystem = is >> good enough from a performance point of view the currently mandatory >> ciphersuites used in CoAP are based on ECC (for those that rely on >> asymmetric crypto). While having hardware support for key storage is a= >> great idea I was wondering how much your architecture actually relies = on >> it. My impression that it would work fine just without a TPM chip. But= >> you might have more hardware experience than I have. Could you point m= e >> to some hardware that you have in mind using? >> > We put this section for completeness and to show that an implementation= > exists. > Concerning sensor nodes and TPM we are using OPAL from CSIRO. Trusting > Computing becomes relevant nowadays when thinking about securing data. > Drawback is that if the TPM chip is broken or you change something > during booting everything is lost. Advantage is that the storage root > key is stored safely and only derivates are used for your applications.= >=20 > Hope to answer most important questions or comments now. Others will be= > addressed soon. > You can also talk to me during IETF in London. >=20 > Regards, > Corinna >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --ahRgTev595FLwL9vJTGseqMswveqkGxCR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTH2F3AAoJEGhJURNOOiAtM6MH/RyE335DHiCg5EFWH7HTTbHT QUW8/f4TEVIl8UaBaz+yZ6zkp6TVX7jewsrJPRm6bQzfWtc5sJWJ1nccpyC8VNh0 I/06JFVu3dSk0/v20Kc6Cw0E/tjuPsT65hFzuhLn8F3qHDGuD4j5qDJgwRtRSMCk bBpLV4MayViVnarH3ZWScMl16Oz0ew8+cYVrnwxy5yoVsWCqBYolA+DdK2FrbtYN 0aau1NBvrfXETXCU4EBQqCtrHhAov+ylHQONWF8anJ/XQOFfl0w9NZvxNVnDdN+H iq24w0gkmzGP3TNDSPhDVbqHHUcDNST0+39RRHwn2hbrsjMx9kx7G55xiDSaHIg= =BwiA -----END PGP SIGNATURE----- --ahRgTev595FLwL9vJTGseqMswveqkGxCR-- From nobody Tue Mar 11 12:39:30 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E298B1A07CC for ; Tue, 11 Mar 2014 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrUIuf8prXTc for ; Tue, 11 Mar 2014 12:39:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id A578E1A07D2 for ; Tue, 11 Mar 2014 12:39:18 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M6SE3-1X6vOD1Yp1-00ySmw; Tue, 11 Mar 2014 20:39:06 +0100 Message-ID: <531F6326.2050403@gmx.net> Date: Tue, 11 Mar 2014 20:25:26 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hosnieh Rafiee , Ace@ietf.org References: <00f101cf3d5b$736152b0$5a23f810$@rozanak.com> <531F5B7C.40101@gmx.net> <010401cf3d5f$3bb26c10$b3174430$@rozanak.com> In-Reply-To: <010401cf3d5f$3bb26c10$b3174430$@rozanak.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pNPPhd87WlMvDuaGPJI9SVQcjiXGKgOEc" X-Provags-ID: V03:K0:UvM5NkGcDioKwnO5lJaUKh5WqjiJrBcQ6K6glO2PR1XF/qMmsiG 4TvdsCpGdR/6+a/zKqO8Sp83F4PuWrIF6s1I58gQ04Im/+or8HKPy+CSkwdtB3cbH2ObLFY GyjAw1Fslz2+kDAbhZOYOXyf647Rh97Ap17ICP/Kj2jWGjdQ52RFzs5I/mhc9z2YYuija9K caJlXyRaufohgsKf4jxew== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/z4AJAtqEfpMmUn0ZotYhvIfIe0E Subject: Re: [Ace] a possible solution candidate? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:39:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pNPPhd87WlMvDuaGPJI9SVQcjiXGKgOEc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hosnieh, the challenge I see is to support the requirements and use cases outlined in http://tools.ietf.org/html/draft-seitz-ace-usecases-00 I have a hard time to see how that would work. There are a number of other, already deployed IETF security protocols* we looked at and even there we identified various gaps. Ciao Hannes *: http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 On 03/11/2014 08:22 PM, Hosnieh Rafiee wrote: > Hi Hannes, >=20 > Thanks for your quick response. I know it is application layer > authentication. The purpose of secauth isn't also to merge the applica= tion > layer protocols with network layer protocols but only use the parameter= s > used to secure network layer in other layers. However, as I explained > earlier, secauth is not only for CoAP devices. In other words, if an > application wants to use this approach, it only carries the parameters = used > in network layer for security purposes in the TCP or UDP messages for > authentication purposes. This is the same way as I've integrated it wit= h > DNS. DNS is also application layer service. It only uses a cached data > available to the service that supports authentication.=20 > This is why I thought it might be useful here too. In any case, I am al= so > working in secauth on authentication and authorization purposes for > application layer and other layer and make this or any similar approach= as a > API available for this purpose. >=20 >=20 > Best, > Hosnieh >=20 >=20 >=20 >> >> Hi Hosnieh >> >> my initial reaction is that those are two separate efforts since we ar= e > focusing >> on application layer authentication and authorization. >> >> If you take a quick look at the updated charter text you will see the > different >> focus: >> https://www.ietf.org/mail-archive/web/ace/current/msg00346.html >> >> Ciao >> Hannes >=20 --pNPPhd87WlMvDuaGPJI9SVQcjiXGKgOEc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTH2MnAAoJEGhJURNOOiAtC3MH+gJi+NtQLSWoOCGFhQqO2FkG UQF3/waEt3WFPedlB0GXaoun7epqieaj00I6N7C3/ignAdtB9cEZa55xWT+iSh22 cUpegEkF1EcUc627W6FJBNy7EEhVWwSKaAnJFMQja1dxpuWveqwnaFe0mUGdJE4b kr/2ZE4bUpS0b5Y2Q+USLWTORSSnotCCKn1G7dBeC/wfEorvIU2WPUixTOYKHI+l 3fXc8rWdiY5ymcRE23WgGGF2/WhlxJRqzhwheVAxG4elET5qPlPc+LswqdNXy61Q OORBF/edjiu20Gr5ROUof3QWh5j+pe7OnBdlMVBlDGj1pJrEgvj1VURCB8HYLN0= =YOxC -----END PGP SIGNATURE----- --pNPPhd87WlMvDuaGPJI9SVQcjiXGKgOEc-- From nobody Tue Mar 11 13:05:59 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7E1A063A for ; Tue, 11 Mar 2014 13:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxYh-c6EQlBi for ; Tue, 11 Mar 2014 13:05:55 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan13.extendcp.co.uk [79.170.45.22]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE81A0538 for ; Tue, 11 Mar 2014 13:05:55 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WNSvt-0008F1-3Y for ace@ietf.org; Tue, 11 Mar 2014 20:05:49 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WNSvp-0004ag-VO for ace@ietf.org; Tue, 11 Mar 2014 20:05:49 +0000 Received: from host86-149-120-43.range86-149.btcentralplus.com ([86.149.120.43] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WNSvp-0007AT-5y for ace@ietf.org; Tue, 11 Mar 2014 20:05:45 +0000 Message-ID: <531F6CBF.2000600@gridmerge.com> Date: Tue, 11 Mar 2014 20:06:23 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ace@ietf.org References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> <7540.1394293121@sandelman.ca> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000107000504060505060601" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/oN1LdxkoGn0Kf4Oh25CEUthadOw Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:05:58 -0000 This is a cryptographically signed message in MIME format. --------------ms000107000504060505060601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable My view is generally that interface II will typically be CoAP/DTLS but=20 could easily be HTTP/TLS and from the point of view of provisioning=20 credentials and access right information, I can't see there would be a=20 huge difference. I am ambivalent regarding I and III from a=20 transfer/transaction/transport protocol point of view but I echo G=F6ran'= s=20 view on considering object security to achieve end-to-end security=20 through proxies, plus it would of course still work if directly=20 connected. An alternative approach which could be considered for proxies = is the ability to tunnel through proxies. This might be useful for=20 reusing existing auth/z protocols through proxies. Robert On 10/03/2014 9:00 AM, G=F6ran Selander wrote: > Hi Michael > > Just on untrusted intermediaries: > > Since the AS needs to protect certain information end-to-end =8B e.g. > authorisation information to be consumed by the RS, key management > information to be consumed by the Client =8B hop-by-hop transport layer= > security would not be sufficient. This case could be handled with objec= t > secure information (some sort of ticket/access token) integrity protect= ed > or encrypted on application layer. As the secure object can't be change= d > by an intermediary, it need to be formatted for transfer to the intende= d > consumer already by the AS, which in particular may need to take into > account a constrained environment. > > > G=F6ran > > > > On 08/03/14 16:38, "Michael Richardson" wrote: > >> This is what I understand about the concern about scope. >> (Gotta love emacs picture-mode... outlook users will need a fixed font= ) >> >> >> +---------------+ >> | Authorization | >> +------------------+-------->| Server | >> | (I) / +---------------+ >> | authz / ^ >> | / | >> /--------\ / | >> (IV) | oauth | / | III >> | proxy | / | authz >> \--------/ / | >> |----------/ | >> v v >> +-----------+ (access) +-----+-----+ >> | | /------\ (II) | Resource | >> | Client | <...|https/|.......>| Server | >> +-----------+ | coap | +-----------+ >> | dtls | >> |proxy | (V) >> \------/ >> >> =3D=3D=3D=3D >> >> IV - is some kind of translator that can take/process OAUTH2 (or some >> other system!) requests into our authorization protocol. It migh= t >> be that teaching the authorization server itself to speak OAUTH2 >> is really the only answer, and that would be fine with me. >> >> V - this is an HTTPS(with OAUTH2 token) to COAP/DTLS (with ACE token) >> proxy. >> >> It would be nice if (V) did not have to have god/superuser access to t= he >> authorization server. I.e. it would be nice if that proxy could be >> untrusted >> by both the client and the authorization server. >> >> Does this diagram match what others have been asking about? >> (I have intentionally left out the SEP2.0 stuff out of this diagram, a= s I >> have no idea what it uses for authorization) >> >> --=20 >> Michael Richardson >> -on the road- >> >> >> >> >> >> >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --------------ms000107000504060505060601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMTEyMDA2MjNaMCMGCSqGSIb3DQEJBDEWBBRoae0uIQmTuIg7sfjp+p8KVNZZXDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBABVgrKezv1YRKAM014UEl/ORNCo/wGU+wSDpaJSfh5OVgwdg rbsYJMsNvehe06HpvO3Ya4wEnSC5vxmKdImbsA17Rd1ELVgsMhzAzvUC4cOQPTc/yl+s84rB QQhAJj9tg/a1KHxBHT8ChK3E2SYpJ4T7xeckMDCYFXfhZlC7PAfSND65l/mo/E3KhpRbkiWg JR8PRd4bJkquavN2Lo1p9uEY8ZtA/BDNHPxLpBoMbep/Ax7WrgEC5XE3Uzpi2Mw4g2GLpUk9 x/lQhmLr8gFXOExLX5e1q7UEN3AmhjnG5kiujvEw5TsDoIXaWTJkm6/61pDXOHMMT4Fzm2en LDXRtx0AAAAAAAA= --------------ms000107000504060505060601-- From nobody Tue Mar 11 14:37:01 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8810A1A0827 for ; Tue, 11 Mar 2014 14:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do3a5ZqtgGQr for ; Tue, 11 Mar 2014 14:36:55 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 13D5E1A063F for ; Tue, 11 Mar 2014 14:36:55 -0700 (PDT) X-ASG-Debug-ID: 1394573807-06daaa24ac267e00001-Yzt3Th Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 5huPILBsWqOOtxju for ; Tue, 11 Mar 2014 17:36:47 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Mar 2014 17:37:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Mar 2014 17:37:29 -0400 X-ASG-Orig-Subj: RE: [Ace] ACE Charter Proposal v0.5 Message-ID: In-Reply-To: <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: Ac89QXuWodwZ5oOzT0ya7A3XuBxgPgAMFS9w References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 11 Mar 2014 21:37:30.0788 (UTC) FILETIME=[1B230640:01CF3D72] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1394573807 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.3798 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/ace/TVlIxEIB7Nb8QXIbNQ1wJkg9jnk Cc: Hannes Tschofenig , ace@ietf.org Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:36:58 -0000 Hi Zach, Don't we need to consider Proxies even for the CoAP/DTLS case? As you know, the base CoAP spec has extensive support for Proxies (both forward and reverse). So I for one think that we should support Proxy even for the CoAP/DTLS scenario. Best Regards, Akbar =20 -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Tuesday, March 11, 2014 11:49 AM To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] ACE Charter Proposal v0.5 Hannes, I am happy with this charter with one exception. The proxy item here seems to be more of a distraction than anything else, and will probably result in increased complexity. Was proxy support maybe just a misunderstanding? Do we really see the need for a proxy in the middle of I or III? I think what we really want here is to make sure that e.g. even through I is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In other words, some interfaces can be constrained while others are not. I think the charter already covers this fine. So my proposal would be to remove the mention of protocol translation proxies. If we really see the need for this some day in the future, it could be tackled then. Zach On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig wrote: > Hi all, > > I have taken the feedback from the meeting and the recent discussions=20 > on the mailing list and produced a new strawman proposal. > > The changes include: > * Added the focus on DTLS/CoAP with an indication that we will check a > candidate solution for suitability with HTTP/TLS. > * Added text to indicate that we will also verify the suitability of=20 > the solution for use with protocol translation proxies. > * Simplified the task list by removing solution specific items. > * Merged several items on the task list (use cases, requirements, and=20 > protocol design guidelines). Followed the suggestion to use of a Wiki=20 > for capturing those. > > What do you think? > > ----- > > Draft Charter V0.5 - Authentication and Authorization for Constrained=20 > Environment (ACE) > > The IETF has recently developed protocols for use in environments=20 > where network nodes are limited in CPU, memory, and power. It was=20 > observed that Internet protocols can be applied to these constrained=20 > environments, often only requiring minor tweaking and profiling. In=20 > other cases, new protocols have been defined to address the specific=20 > requirements of constrained devices and networks. An example of such a > protocol is the Constrained Application Protocol (CoAP). > components > As in other environments, authentication and authorization question=20 > also arise in environments with constrained nodes and networks. For=20 > example, a door lock has to authorize the person seeking access using=20 > a "digital key". Where are the authorization decisions stored? How=20 > does the digital key communicate with the lock? Does the lock interact > with an authorization server to obtain authorization information? How=20 > can access be granted to other persons temporarily? How can access be revoked? > These types of questions have been answered by existing protocols for=20 > use cases outside the constrained environment. But in constrained=20 > environment, additional requirements pose challenges for the use of=20 > various security protocols. > > The IETF has a long history in developing three party authentication=20 > and authorization protocols for distributed environments. Examples=20 > include Kerberos, the Public Key Infrastructure (PKI), the=20 > Authentication, Authorization, and Accounting (AAA) infrastructure,=20 > and the Web Authorization Protocol (OAuth). All these protocols enjoy=20 > widespread deployment on the Internet. Although they all aim to solve=20 > a similar goal, at an abstract level, they offer quite different=20 > functions and utilize different message exchanges. These differences=20 > are motivated by the main deployment use cases they were designed for. > > Requirements derived from use cases indicate the suitability of=20 > already existing work, such as OAuth, as a solution for constrained=20 > environments. These protocols were, however, not optimized for=20 > constrained environments. Additional requirements that need to be=20 > taken into account are the lack of a suitable user-interface for=20 > obtaining the consent of the user and the inability of embedded=20 > devices to contact an authorization server in real-time with every=20 > access request due to intermittent connectivity, etc. > > This working group therefore aims for a standardized solution for=20 > authentication and authorization to enable authorized access to=20 > resources in constrained environments. As a starting point, the=20 > working group will assume that access to resources offered by a=20 > resource server by a client devices takes place using CoAP and is protected by DTLS. > Both resource server and client may be resource constraint. This=20 > access will be mediated by an authorization server, which does not=20 > suffer from the same resource limitations. > > Existing authentication and authorization protocols are used and=20 > re-applied for use with constrained devices, where applicable. This=20 > requires relevant specifications to be reviewed for suitability,=20 > selecting a subset of them, restricting the options within each of the > specifications. Some functionalities may, however, not be available in > existing protocols and for those cases new functionality has to be=20 > standardized. Thus, existing work can be leveraged and the group=20 > benefits from available security analysis, implementation, and=20 > deployment experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of IoT devices offering increased security. > > Once progress in identifying suitable candidate solutions has been=20 > made the working group will verify whether the same mechanism are also > applicable beyond the use of CoAP and DTLS. In particular, the ability > to use the developed solution over HTTP and TLS will be investigated. > Furthermore, to guarantee smooth transition the integration with=20 > existing deployment will be studied. This particularly concerns the=20 > use of protocol translation proxies. > > To be successful this working group requires expertise in security,=20 > privacy, and a good understanding of usability in the constrained=20 > environment space. This work does not make the assumption that the=20 > party offering application layer services is always the same party=20 > offering network access services. > > The working group has the following tasks (in this order): > > 1) The working group Wiki pages will be used to document use cases,=20 > requirements, and protocol design criteria. This work will guide the=20 > identification of suitable protocol mechanisms. > > 2) Selection of an authentication and authorization protocol for=20 > constrained environments. > > 3) Evaluation of the candidate solution for use with HTTP/TLS and=20 > proxy deployments. > > ----- > > Ciao > Hannes > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Tue Mar 11 14:53:28 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464411A081D for ; Tue, 11 Mar 2014 14:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTXxgfMg4U7J for ; Tue, 11 Mar 2014 14:53:24 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 971AF1A063F for ; Tue, 11 Mar 2014 14:53:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id AF03B23E24C2; Tue, 11 Mar 2014 21:53:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOa4G3uwwzR6; Tue, 11 Mar 2014 22:53:16 +0100 (CET) Received: from kopoli (g226057108.adsl.alicedsl.de [92.226.57.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 6D44723E24BC; Tue, 11 Mar 2014 22:53:16 +0100 (CET) From: "Hosnieh Rafiee" To: "'Hannes Tschofenig'" , References: <00f101cf3d5b$736152b0$5a23f810$@rozanak.com> <531F5B7C.40101@gmx.net> <010401cf3d5f$3bb26c10$b3174430$@rozanak.com> <531F6326.2050403@gmx.net> In-Reply-To: <531F6326.2050403@gmx.net> Date: Tue, 11 Mar 2014 22:53:15 +0100 Message-ID: <013801cf3d74$4e60ef70$eb22ce50$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNO+RZCuMSzNq65zUwJN+zsSn372wJ1ln1XAVh9XOQCOZv/25esuDVw Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/ace/NC2yqY9FWVLXYhG5QWEhu8KODmY Subject: Re: [Ace] a possible solution candidate? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:53:27 -0000 Hi again, > the challenge I see is to support the requirements and use cases outlined in > http://tools.ietf.org/html/draft-seitz-ace-usecases-00 > I have a hard time to see how that would work. As far as I understand, you are going to use TLS as a part of security approach. To eliminate the need for having certificates for keys, one *possible* solution is the approach I explained. Thanks, Best, Hosnieh From nobody Tue Mar 11 14:58:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A8E1A0852 for ; Tue, 11 Mar 2014 14:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exmIP6SrX4uh for ; Tue, 11 Mar 2014 14:58:34 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB911A0827 for ; Tue, 11 Mar 2014 14:58:34 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id 10so6132275lbg.11 for ; Tue, 11 Mar 2014 14:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kLz4Shmwh3acv44wB1O+1YpGtyZcSUshe4ZDc6o8LXo=; b=X7RANRsKV2N8ZCczhM8rveMfeDFuFzcYHRX1tRJynICEkh1diIdwAZLf195ubyQHCJ tlDi1MxGsf2xPxsL0VT7FfXpkmp01Mf03YbUXMYEiZpnKPS/6Kr8HILokE7wyujQMTi9 p0fRKLHcgiFz4cuaBT2bcHyOOzGMdtvPPlpgnDOR6fH7DBMhGCIYIuB2CNiF5SMuMj5G jOf1cyAEoCJYSQbqlrba4QwY+pORxIHGlLmvU1tqQ1bTwCx9K+Cnj+Zdhy6+uRcHSDGn 5P5C1U4aGcBWKnVcW6NNpG1xYw/aVh1FfpY4fcqC9oTQ1PDRR6aAnI7DCb/F5Qza/lDk F3jw== MIME-Version: 1.0 X-Received: by 10.152.120.168 with SMTP id ld8mr17484246lab.12.1394575107826; Tue, 11 Mar 2014 14:58:27 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Tue, 11 Mar 2014 14:58:27 -0700 (PDT) In-Reply-To: <531EC063.3000903@gmx.net> References: <531EC063.3000903@gmx.net> Date: Tue, 11 Mar 2014 16:58:27 -0500 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e012281a4ea286904f45bd188 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/s-PZn6xPelxxApj07vM2VVVY19I Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:58:37 -0000 --089e012281a4ea286904f45bd188 Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes, Is there an architecture for the proposed work? I think that it could help to come up with a simple architecture. Regards, Behcet On Tue, Mar 11, 2014 at 2:50 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > I have taken the feedback from the meeting and the recent discussions on > the mailing list and produced a new strawman proposal. > > The changes include: > * Added the focus on DTLS/CoAP with an indication that we will check a > candidate solution for suitability with HTTP/TLS. > * Added text to indicate that we will also verify the suitability of > the solution for use with protocol translation proxies. > * Simplified the task list by removing solution specific items. > * Merged several items on the task list (use cases, requirements, and > protocol design guidelines). Followed the suggestion to use of a Wiki > for capturing those. > > What do you think? > > ----- > > Draft Charter V0.5 - Authentication and Authorization for Constrained > Environment (ACE) > > The IETF has recently developed protocols for use in environments where > network nodes are limited in CPU, memory, and power. It was observed > that Internet protocols can be applied to these constrained > environments, often only requiring minor tweaking and profiling. In > other cases, new protocols have been defined to address the specific > requirements of constrained devices and networks. An example of such a > protocol is the Constrained Application Protocol (CoAP). > components > As in other environments, authentication and authorization question also > arise in environments with constrained nodes and networks. For example, > a door lock has to authorize the person seeking access using a "digital > key". Where are the authorization decisions stored? How does the digital > key communicate with the lock? Does the lock interact with an > authorization server to obtain authorization information? How can access > be granted to other persons temporarily? How can access be revoked? > These types of questions have been answered by existing protocols for > use cases outside the constrained environment. But in constrained > environment, additional requirements pose challenges for the use of > various security protocols. > > The IETF has a long history in developing three party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > Authorization, and Accounting (AAA) infrastructure, and the Web > Authorization Protocol (OAuth). All these protocols enjoy widespread > deployment on the Internet. Although they all aim to solve a similar > goal, at an abstract level, they offer quite different functions and > utilize different message exchanges. These differences are motivated by > the main deployment use cases they were designed for. > > Requirements derived from use cases indicate the suitability of already > existing work, such as OAuth, as a solution for constrained > environments. These protocols were, however, not optimized for > constrained environments. Additional requirements that need to be taken > into account are the lack of a suitable user-interface for obtaining the > consent of the user and the inability of embedded devices to contact an > authorization server in real-time with every access request due to > intermittent connectivity, etc. > > This working group therefore aims for a standardized solution for > authentication and authorization to enable authorized access to > resources in constrained environments. As a starting point, the working > group will assume that access to resources offered by a resource server > by a client devices takes place using CoAP and is protected by DTLS. > Both resource server and client may be resource constraint. This access > will be mediated by an authorization server, which does not suffer from > the same resource limitations. > > Existing authentication and authorization protocols are used and > re-applied for use with constrained devices, where applicable. This > requires relevant specifications to be reviewed for suitability, > selecting a subset of them, restricting the options within each of the > specifications. Some functionalities may, however, not be available in > existing protocols and for those cases new functionality has to be > standardized. Thus, existing work can be leveraged and the group > benefits from available security analysis, implementation, and > deployment experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of IoT devices offering increased security. > > Once progress in identifying suitable candidate solutions has been made > the working group will verify whether the same mechanism are also > applicable beyond the use of CoAP and DTLS. In particular, the ability > to use the developed solution over HTTP and TLS will be investigated. > Furthermore, to guarantee smooth transition the integration with > existing deployment will be studied. This particularly concerns the use > of protocol translation proxies. > > To be successful this working group requires expertise in security, > privacy, and a good understanding of usability in the constrained > environment space. This work does not make the assumption that the party > offering application layer services is always the same party offering > network access services. > > The working group has the following tasks (in this order): > > 1) The working group Wiki pages will be used to document use cases, > requirements, and protocol design criteria. This work will guide the > identification of suitable protocol mechanisms. > > 2) Selection of an authentication and authorization protocol for > constrained environments. > > 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy > deployments. > > ----- > > Ciao > Hannes > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --089e012281a4ea286904f45bd188 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

Is there an ar= chitecture for the proposed work?

I think that it could help = to come up with a simple architecture.

Regards,

Behcet


On Tue, Mar 11, 2014 at 2:50 AM, Hannes Tschofenig <= ;hannes.tsch= ofenig@gmx.net> wrote:
Hi all,

I have taken the feedback from the meeting and the recent discussions on the mailing list and produced a new strawman proposal.

The changes include:
=A0* Added the focus on DTLS/CoAP with an indication that we will check a candidate solution for suitability with HTTP/TLS.
=A0* Added text to indicate that we will also verify the suitability of
the solution for use with protocol translation proxies.
=A0* Simplified the task list by removing solution specific items.
=A0* Merged several items on the task list (use cases, requirements, and protocol design guidelines). Followed the suggestion to use of a Wiki
for capturing those.

What do you think?

-----

Draft Charter V0.5 - Authentication and Authorization for Constrained
Environment (ACE)

The IETF has recently developed protocols for use in environments where
network nodes are limited in CPU, memory, and power. It was observed
that Internet protocols can be applied to these constrained
environments, often only requiring minor tweaking and profiling. In
other cases, new protocols have been defined to address the specific
requirements of constrained devices and networks. An example of such a
protocol is the Constrained Application Protocol (CoAP).
components
As in other environments, authentication and authorization question also arise in environments with constrained nodes and networks. For example,
a door lock has to authorize the person seeking access using a "digita= l
key". Where are the authorization decisions stored? How does the digit= al
key communicate with the lock? Does the lock interact with an
authorization server to obtain authorization information? How can access be granted to other persons temporarily? How can access be revoked?
These types of questions have been answered by existing protocols for
use cases outside the constrained environment. But in constrained
environment, additional requirements pose challenges for the use of
various security protocols.

The IETF has a long history in developing three party authentication and authorization protocols for distributed environments. Examples include
Kerberos, the Public Key Infrastructure (PKI), the Authentication,
Authorization, and Accounting (AAA) infrastructure, and the Web
Authorization Protocol (OAuth). All these protocols enjoy widespread
deployment on the Internet. Although they all aim to solve a similar
goal, at an abstract level, they offer quite different functions and
utilize different message exchanges. These differences are motivated by
the main deployment use cases they were designed for.

Requirements derived from use cases indicate the suitability of already
existing work, such as OAuth, as a solution for constrained
environments. These protocols were, however, not optimized for
constrained environments. Additional requirements that need to be taken
into account are the lack of a suitable user-interface for obtaining the consent of the user and the inability of embedded devices to contact an
authorization server in real-time with every access request due to
intermittent connectivity, etc.

This working group therefore aims for a standardized solution for
authentication and authorization to enable authorized access to
resources in constrained environments. As a starting point, the working
group will assume that access to resources offered by a resource server
by a client devices takes place using CoAP and is protected by DTLS.
Both resource server and client may be resource constraint. This access
will be mediated by an authorization server, which does not suffer from
the same resource limitations.

Existing authentication and authorization protocols are used and
re-applied for use with constrained devices, where applicable. This
requires relevant specifications to be reviewed for suitability,
selecting a subset of them, restricting the options within each of the
specifications. Some functionalities may, however, not be available in
existing protocols and for those cases new functionality has to be
standardized. Thus, existing work can be leveraged and the group
benefits from available security analysis, implementation, and
deployment experience. Moreover, a standardized solution for federated
authentication and authorization will help to stimulate the deployment
of IoT devices offering increased security.

Once progress in identifying suitable candidate solutions has been made
the working group will verify whether the same mechanism are also
applicable beyond the use of CoAP and DTLS. In particular, the ability
to use the developed solution over HTTP and TLS will be investigated.
Furthermore, to guarantee smooth transition the integration with
existing deployment will be studied. This particularly concerns the use
of protocol translation proxies.

To be successful this working group requires expertise in security,
privacy, and a good understanding of usability in the constrained
environment space. This work does not make the assumption that the party offering application layer services is always the same party offering
network access services.

The working group has the following tasks (in this order):

1) The working group Wiki pages will be used to document use cases,
requirements, and protocol design criteria. This work will guide the
identification of suitable protocol mechanisms.

2) Selection of an authentication and authorization protocol for
constrained environments.

3) Evaluation of the candidate solution for use with HTTP/TLS and proxy
deployments.

-----

Ciao
Hannes



_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace


--089e012281a4ea286904f45bd188-- From nobody Tue Mar 11 23:38:16 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C000C1A08EC for ; Tue, 11 Mar 2014 23:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tauNxg_SGr6 for ; Tue, 11 Mar 2014 23:38:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 766B11A08EA for ; Tue, 11 Mar 2014 23:38:12 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MMkgl-1WWBNq1PBP-008Ywm; Wed, 12 Mar 2014 07:38:05 +0100 Message-ID: <531F6730.3050604@gmx.net> Date: Tue, 11 Mar 2014 20:42:40 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, ace@ietf.org References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> <7540.1394293121@sandelman.ca> <531F6CBF.2000600@gridmerge.com> In-Reply-To: <531F6CBF.2000600@gridmerge.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Erhgi9WgwjpTqCtBgp5bU3idEVxrjAMFq" X-Provags-ID: V03:K0:YgaprZMNMQNkRU3XMKZj8Xg1XR2Bs1S7C1fPUIJ7ogPeWLgN1L6 Cul4usFZ4WQIuEpNkfdcLFCNpLuPtHW9G/TRKxRMlnOkkO9QSXs9fXDt4mnJp8oORRjWH01 VFOx/uh6wmXTbIuix7ubPoCHIzJ7Rbh14JWw6PLSPm5o+QZKi/48WPFLQADo8GKZ5w1L4iw fp7qOe7Ygprc8Kc8SbN8w== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/IDss1NS9VUkI0WwpJaUfSmwPWyY Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:38:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Erhgi9WgwjpTqCtBgp5bU3idEVxrjAMFq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Goeran, Robert, Here is the challenge (based on my experience from OAuth): 1) You need to tie the application layer security to the channel security since otherwise you introduce attacks. 2) You need to tie the application layer security to the actual request. Doing protocol translation in-between makes this somewhat challenging. My fear is that while it sounds like a nice idea to do this protocol translation it makes the entire security story brittle and more complex. I am fine with investigating these proxy cases but we shouldn't be astonished if they do not work in the way we had hoped. Ciao Hannes PS: The term 'trusted' and 'untrusted' intermediary is somewhat fuzzy. As I stated earlier this year on this mailing list, you have to indicate WHO trust WHOM for WHAT. On 03/11/2014 09:06 PM, Robert Cragie wrote: > My view is generally that interface II will typically be CoAP/DTLS but > could easily be HTTP/TLS and from the point of view of provisioning > credentials and access right information, I can't see there would be a > huge difference. >=20 > I am ambivalent regarding I and III from a > transfer/transaction/transport protocol point of view but I echo G=F6ra= n's > view on considering object security to achieve end-to-end security > through proxies, plus it would of course still work if directly > connected. An alternative approach which could be considered for proxie= s > is the ability to tunnel through proxies. This might be useful for > reusing existing auth/z protocols through proxies. >=20 > Robert >=20 > On 10/03/2014 9:00 AM, G=F6ran Selander wrote: >> Hi Michael >> >> Just on untrusted intermediaries: >> >> Since the AS needs to protect certain information end-to-end =8B e.g.= >> authorisation information to be consumed by the RS, key management >> information to be consumed by the Client =8B hop-by-hop transport laye= r >> security would not be sufficient. This case could be handled with obje= ct >> secure information (some sort of ticket/access token) integrity protec= ted >> or encrypted on application layer. As the secure object can't be chang= ed >> by an intermediary, it need to be formatted for transfer to the intend= ed >> consumer already by the AS, which in particular may need to take into >> account a constrained environment. >> >> >> G=F6ran >> >> >> >> On 08/03/14 16:38, "Michael Richardson" wrote:= >> >>> This is what I understand about the concern about scope. >>> (Gotta love emacs picture-mode... outlook users will need a fixed fon= t) >>> >>> >>> +---------------+ >>> | Authorization | >>> +------------------+-------->| Server | >>> | (I) / +---------------+ >>> | authz / ^ >>> | / | >>> /--------\ / | >>> (IV) | oauth | / | III >>> | proxy | / | authz >>> \--------/ / | >>> |----------/ | >>> v v >>> +-----------+ (access) +-----+-----+ >>> | | /------\ (II) | Resource | >>> | Client | <...|https/|.......>| Server | >>> +-----------+ | coap | +-----------+ >>> | dtls | >>> |proxy | (V) >>> \------/ >>> >>> =3D=3D=3D=3D >>> >>> IV - is some kind of translator that can take/process OAUTH2 (or some= >>> other system!) requests into our authorization protocol. It mig= ht >>> be that teaching the authorization server itself to speak OAUTH2= >>> is really the only answer, and that would be fine with me. >>> >>> V - this is an HTTPS(with OAUTH2 token) to COAP/DTLS (with ACE token)= >>> proxy. >>> >>> It would be nice if (V) did not have to have god/superuser access to = the >>> authorization server. I.e. it would be nice if that proxy could be >>> untrusted >>> by both the client and the authorization server. >>> >>> Does this diagram match what others have been asking about? >>> (I have intentionally left out the SEP2.0 stuff out of this diagram, >>> as I >>> have no idea what it uses for authorization) >>> >>> --=20 >>> Michael Richardson >>> -on the road- >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --Erhgi9WgwjpTqCtBgp5bU3idEVxrjAMFq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTH2cwAAoJEGhJURNOOiAtO0QH/jsCVznN6vMZbKEhCaDDhy44 Aj8Hai7xXLR59k5s0SxjzO2cJXT8pPYNyyeRJHzsNPHdcghIutdOQ9jaovqp+yEo Rj+2T2LNVqy6bnWqPFQjw4wyv6IxsCDdHwq72dyGzfZfHXUP8dv8YrrTpVNJV31V Ty9q23Cl7rch+08zmuPi6407AGtRngXbXd/z/NfvwLQFxCLzcppb0blaZ8bedPOA bFJrm4DVxmVYNaAp9ISoK6+CjXxkMMmIe46bXz+1NxFeZM6mjkehKVpKUZfojal+ mBAey+9lpJ2skcUb0cOUh/VOVM5ilCQo677IOHkWq7XW5Ypbu4CwdnpNyYKL9XI= =kVdo -----END PGP SIGNATURE----- --Erhgi9WgwjpTqCtBgp5bU3idEVxrjAMFq-- From nobody Tue Mar 11 23:42:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EE1A08EF for ; Tue, 11 Mar 2014 23:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng9s8GK1TSfD for ; Tue, 11 Mar 2014 23:42:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id F36EC1A08EC for ; Tue, 11 Mar 2014 23:42:07 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LlDx4-1WycIz3c8M-00b38B; Wed, 12 Mar 2014 07:42:00 +0100 Message-ID: <531F6816.1040100@gmx.net> Date: Tue, 11 Mar 2014 20:46:30 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <531EC063.3000903@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fgrdv61OQGqxoqc5Gvw7FfCdbmv1vvB3C" X-Provags-ID: V03:K0:MtJhOcLubdc4WgQspypsrTyEA1rMUAu+Y44mEu1B/rNlJEdqq8O vIvdPi0jrhFNfFCq50Ra8a+CbccVojoxM+qNtj4iyJ3PmNB0F7f8BuWxD2Jkv4j8I0Z3Ar+ phCqS8o6B8RbPCFJsMV4ZIXttAUNcSRaThDC6fImTCz5gogmneKqN25mlTM4M269a0/CB0b yAdm6P0rjmyoJS1uIdb5g== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/-oTJahGfJR1uzNCdg_SW6LfX5_g Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:42:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fgrdv61OQGqxoqc5Gvw7FfCdbmv1vvB3C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. The architecture is part of the solution description. The question you are asking is whether it should be in a separate document or combined with the actual solution. My experience from other working groups is that there will be all sorts of arguments for having various different profiles for use case X and use case Y. In that case it makes sense to come up with a separate architecture document that gives the reader the overview. Luckily, we are not yet at that point. So, let's worry about the document management later. Ciao Hannes On 03/11/2014 10:58 PM, Behcet Sarikaya wrote: > Hi Hannes, >=20 > Is there an architecture for the proposed work? >=20 > I think that it could help to come up with a simple architecture. >=20 > Regards, >=20 > Behcet >=20 >=20 > On Tue, Mar 11, 2014 at 2:50 AM, Hannes Tschofenig > > wrote: >=20 > Hi all, >=20 > I have taken the feedback from the meeting and the recent discussio= ns on > the mailing list and produced a new strawman proposal. >=20 > The changes include: > * Added the focus on DTLS/CoAP with an indication that we will che= ck a > candidate solution for suitability with HTTP/TLS. > * Added text to indicate that we will also verify the suitability = of > the solution for use with protocol translation proxies. > * Simplified the task list by removing solution specific items. > * Merged several items on the task list (use cases, requirements, = and > protocol design guidelines). Followed the suggestion to use of a Wi= ki > for capturing those. >=20 > What do you think? >=20 > ----- >=20 > Draft Charter V0.5 - Authentication and Authorization for Constrain= ed > Environment (ACE) >=20 > The IETF has recently developed protocols for use in environments w= here > network nodes are limited in CPU, memory, and power. It was observe= d > that Internet protocols can be applied to these constrained > environments, often only requiring minor tweaking and profiling. In= > other cases, new protocols have been defined to address the specifi= c > requirements of constrained devices and networks. An example of suc= h a > protocol is the Constrained Application Protocol (CoAP). > components > As in other environments, authentication and authorization question= also > arise in environments with constrained nodes and networks. For exam= ple, > a door lock has to authorize the person seeking access using a "dig= ital > key". Where are the authorization decisions stored? How does the di= gital > key communicate with the lock? Does the lock interact with an > authorization server to obtain authorization information? How can a= ccess > be granted to other persons temporarily? How can access be revoked?= > These types of questions have been answered by existing protocols f= or > use cases outside the constrained environment. But in constrained > environment, additional requirements pose challenges for the use of= > various security protocols. >=20 > The IETF has a long history in developing three party authenticatio= n and > authorization protocols for distributed environments. Examples incl= ude > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > Authorization, and Accounting (AAA) infrastructure, and the Web > Authorization Protocol (OAuth). All these protocols enjoy widesprea= d > deployment on the Internet. Although they all aim to solve a simila= r > goal, at an abstract level, they offer quite different functions an= d > utilize different message exchanges. These differences are motivate= d by > the main deployment use cases they were designed for. >=20 > Requirements derived from use cases indicate the suitability of alr= eady > existing work, such as OAuth, as a solution for constrained > environments. These protocols were, however, not optimized for > constrained environments. Additional requirements that need to be t= aken > into account are the lack of a suitable user-interface for obtainin= g the > consent of the user and the inability of embedded devices to contac= t an > authorization server in real-time with every access request due to > intermittent connectivity, etc. >=20 > This working group therefore aims for a standardized solution for > authentication and authorization to enable authorized access to > resources in constrained environments. As a starting point, the wor= king > group will assume that access to resources offered by a resource se= rver > by a client devices takes place using CoAP and is protected by DTLS= =2E > Both resource server and client may be resource constraint. This ac= cess > will be mediated by an authorization server, which does not suffer = from > the same resource limitations. >=20 > Existing authentication and authorization protocols are used and > re-applied for use with constrained devices, where applicable. This= > requires relevant specifications to be reviewed for suitability, > selecting a subset of them, restricting the options within each of = the > specifications. Some functionalities may, however, not be available= in > existing protocols and for those cases new functionality has to be > standardized. Thus, existing work can be leveraged and the group > benefits from available security analysis, implementation, and > deployment experience. Moreover, a standardized solution for federa= ted > authentication and authorization will help to stimulate the deploym= ent > of IoT devices offering increased security. >=20 > Once progress in identifying suitable candidate solutions has been = made > the working group will verify whether the same mechanism are also > applicable beyond the use of CoAP and DTLS. In particular, the abil= ity > to use the developed solution over HTTP and TLS will be investigate= d. > Furthermore, to guarantee smooth transition the integration with > existing deployment will be studied. This particularly concerns the= use > of protocol translation proxies. >=20 > To be successful this working group requires expertise in security,= > privacy, and a good understanding of usability in the constrained > environment space. This work does not make the assumption that the = party > offering application layer services is always the same party offeri= ng > network access services. >=20 > The working group has the following tasks (in this order): >=20 > 1) The working group Wiki pages will be used to document use cases,= > requirements, and protocol design criteria. This work will guide th= e > identification of suitable protocol mechanisms. >=20 > 2) Selection of an authentication and authorization protocol for > constrained environments. >=20 > 3) Evaluation of the candidate solution for use with HTTP/TLS and p= roxy > deployments. >=20 > ----- >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 >=20 --fgrdv61OQGqxoqc5Gvw7FfCdbmv1vvB3C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTH2gWAAoJEGhJURNOOiAtsrIH/0O0jr3mx0l9y9TwgEVeIYHc GtTnGDScuAgd0mPL4HE6B8fE0iAxVwgMIYtQvOiAyzlsMvI/P6R9tQIfQE//KNpk VIhULgtB+WGGZp6/z0DdnoKoVcF00lg3HYqFjLSnnFkW35vDKm6yLkTBEyRog6xi /U40IQz7w6+Ow2kCRSAEDytKLdPVlB2RJJ4+zxsoC9+0a/XF6E39PLUEBdCDSvpH Mcegr5CQHufSKXkupVFnVX8jLrWjx7ntAos70UdLf5CmYanMCPPpyR7/z8CDx02w 3yYRrlARFkYMCuelabIKT7PKuvEoPqfOoZvIlWBrPnLYlBcMwlBpLbCqyD9JU5c= =c04B -----END PGP SIGNATURE----- --fgrdv61OQGqxoqc5Gvw7FfCdbmv1vvB3C-- From nobody Tue Mar 11 23:46:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9909F1A08EF for ; Tue, 11 Mar 2014 23:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF11R-T5cvre for ; Tue, 11 Mar 2014 23:46:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 784E41A0641 for ; Tue, 11 Mar 2014 23:46:48 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LgMCe-1WtiZf1uvE-00neU9; Wed, 12 Mar 2014 07:46:39 +0100 Message-ID: <531F6929.4080102@gmx.net> Date: Tue, 11 Mar 2014 20:51:05 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Rahman, Akbar" , Zach Shelby References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fbAb7kiVb1PXww8xa0IM2EiBfWwVs0Svk" X-Provags-ID: V03:K0:tF0CCSuUOwl6IdUzz3lbAPFLd4oPHa+PyjVQBdu5rzI3x3WQcqT GKrsxh7NksbagUghn+xShL2hD9tXO/IUH6JYNvMd9ShjelZYsgFq/GE794LbRCe9X0naKqH D7SsjzMDB0r8P8Z+hFMhkkzffB4cd4xjanV6fLQIo0RQbjFIlmSvyBojTRnlQtAT119HEXg GySPp44y5mxqdnkeOIZFA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/PmILj4LQo3l2kYde3uxgFgKZ5-s Cc: ace@ietf.org Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:46:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fbAb7kiVb1PXww8xa0IM2EiBfWwVs0Svk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interesting question and I let Zach and other CoAP experts respond to it.= In the BOF, however, we have only spoken about protocol translation proxies in the context of allowing protocols other than CoAP to be supported. So, you are bringing up another topic in the charter discussion, which is almost a question to the CORE working group about their ideas for using DTLS with proxies in general. Ciao Hannes On 03/11/2014 10:37 PM, Rahman, Akbar wrote: > Hi Zach, >=20 >=20 > Don't we need to consider Proxies even for the CoAP/DTLS case? As you > know, the base CoAP spec has extensive support for Proxies (both forwar= d > and reverse). So I for one think that we should support Proxy even for= > the CoAP/DTLS scenario. >=20 >=20 > Best Regards, >=20 >=20 >=20 > Akbar >=20 > =20 >=20 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Zach Shelby > Sent: Tuesday, March 11, 2014 11:49 AM > To: Hannes Tschofenig > Cc: ace@ietf.org > Subject: Re: [Ace] ACE Charter Proposal v0.5 >=20 > Hannes, >=20 > I am happy with this charter with one exception. The proxy item here > seems to be more of a distraction than anything else, and will probably= > result in increased complexity. Was proxy support maybe just a > misunderstanding? Do we really see the need for a proxy in the middle o= f > I or III? >=20 > I think what we really want here is to make sure that e.g. even through= > I is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In > other words, some interfaces can be constrained while others are not. I= > think the charter already covers this fine. >=20 > So my proposal would be to remove the mention of protocol translation > proxies. If we really see the need for this some day in the future, it > could be tackled then. >=20 > Zach >=20 > On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig > wrote: >=20 >> Hi all, >> >> I have taken the feedback from the meeting and the recent discussions = >> on the mailing list and produced a new strawman proposal. >> >> The changes include: >> * Added the focus on DTLS/CoAP with an indication that we will check a= >=20 >> candidate solution for suitability with HTTP/TLS. >> * Added text to indicate that we will also verify the suitability of=20 >> the solution for use with protocol translation proxies. >> * Simplified the task list by removing solution specific items. >> * Merged several items on the task list (use cases, requirements, and = >> protocol design guidelines). Followed the suggestion to use of a Wiki = >> for capturing those. >> >> What do you think? >> >> ----- >> >> Draft Charter V0.5 - Authentication and Authorization for Constrained = >> Environment (ACE) >> >> The IETF has recently developed protocols for use in environments=20 >> where network nodes are limited in CPU, memory, and power. It was=20 >> observed that Internet protocols can be applied to these constrained=20 >> environments, often only requiring minor tweaking and profiling. In=20 >> other cases, new protocols have been defined to address the specific=20 >> requirements of constrained devices and networks. An example of such a= >=20 >> protocol is the Constrained Application Protocol (CoAP). >> components >> As in other environments, authentication and authorization question=20 >> also arise in environments with constrained nodes and networks. For=20 >> example, a door lock has to authorize the person seeking access using = >> a "digital key". Where are the authorization decisions stored? How=20 >> does the digital key communicate with the lock? Does the lock interact= >=20 >> with an authorization server to obtain authorization information? How = >> can access be granted to other persons temporarily? How can access be > revoked? >> These types of questions have been answered by existing protocols for = >> use cases outside the constrained environment. But in constrained=20 >> environment, additional requirements pose challenges for the use of=20 >> various security protocols. >> >> The IETF has a long history in developing three party authentication=20 >> and authorization protocols for distributed environments. Examples=20 >> include Kerberos, the Public Key Infrastructure (PKI), the=20 >> Authentication, Authorization, and Accounting (AAA) infrastructure,=20 >> and the Web Authorization Protocol (OAuth). All these protocols enjoy = >> widespread deployment on the Internet. Although they all aim to solve = >> a similar goal, at an abstract level, they offer quite different=20 >> functions and utilize different message exchanges. These differences=20 >> are motivated by the main deployment use cases they were designed for.= >> >> Requirements derived from use cases indicate the suitability of=20 >> already existing work, such as OAuth, as a solution for constrained=20 >> environments. These protocols were, however, not optimized for=20 >> constrained environments. Additional requirements that need to be=20 >> taken into account are the lack of a suitable user-interface for=20 >> obtaining the consent of the user and the inability of embedded=20 >> devices to contact an authorization server in real-time with every=20 >> access request due to intermittent connectivity, etc. >> >> This working group therefore aims for a standardized solution for=20 >> authentication and authorization to enable authorized access to=20 >> resources in constrained environments. As a starting point, the=20 >> working group will assume that access to resources offered by a=20 >> resource server by a client devices takes place using CoAP and is > protected by DTLS. >> Both resource server and client may be resource constraint. This=20 >> access will be mediated by an authorization server, which does not=20 >> suffer from the same resource limitations. >> >> Existing authentication and authorization protocols are used and=20 >> re-applied for use with constrained devices, where applicable. This=20 >> requires relevant specifications to be reviewed for suitability,=20 >> selecting a subset of them, restricting the options within each of the= >=20 >> specifications. Some functionalities may, however, not be available in= >=20 >> existing protocols and for those cases new functionality has to be=20 >> standardized. Thus, existing work can be leveraged and the group=20 >> benefits from available security analysis, implementation, and=20 >> deployment experience. Moreover, a standardized solution for federated= >=20 >> authentication and authorization will help to stimulate the deployment= >=20 >> of IoT devices offering increased security. >> >> Once progress in identifying suitable candidate solutions has been=20 >> made the working group will verify whether the same mechanism are also= >=20 >> applicable beyond the use of CoAP and DTLS. In particular, the ability= >=20 >> to use the developed solution over HTTP and TLS will be investigated. >> Furthermore, to guarantee smooth transition the integration with=20 >> existing deployment will be studied. This particularly concerns the=20 >> use of protocol translation proxies. >> >> To be successful this working group requires expertise in security,=20 >> privacy, and a good understanding of usability in the constrained=20 >> environment space. This work does not make the assumption that the=20 >> party offering application layer services is always the same party=20 >> offering network access services. >> >> The working group has the following tasks (in this order): >> >> 1) The working group Wiki pages will be used to document use cases,=20 >> requirements, and protocol design criteria. This work will guide the=20 >> identification of suitable protocol mechanisms. >> >> 2) Selection of an authentication and authorization protocol for=20 >> constrained environments. >> >> 3) Evaluation of the candidate solution for use with HTTP/TLS and=20 >> proxy deployments. >> >> ----- >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > Zach Shelby > Director of Technology > ARM Internet of Things BU > www.arm.com > mobile: +1 (408) 203-9434 > Skype: zdshelby > LinkedIn: fi.linkedin.com/in/zachshelby/ >=20 >=20 > -- IMPORTANT NOTICE: The contents of this email and any attachments are= > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the= > contents to any other person, use it for any purpose, or store or copy > the information in any medium. Thank you. >=20 > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 ARM Holdings plc, > Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in > England & Wales, Company No: 2548782 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --fbAb7kiVb1PXww8xa0IM2EiBfWwVs0Svk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTH2kpAAoJEGhJURNOOiAt1M8H/0wkQEhj0tdrKGWsvMhZav1y CzeQ+BGPpYTfxetWlP+P6fHU4WnEM0ZJUFuldGrn+Of1vhwPrtOz8YQofIAA7Oml /Wn6kw5pQYw9fBq6bOUsTu8oCwazjSudgjp/KlaWV85N5EsZN3Jb0VmztbUvYNpL XxpgpWR9LfL9DdRHqgbTdtAx0bf6AgMdc3ksKbzxeBpZhpsTQM+3J6Ydj8lMlXMY MDan1zh8/nzGqacnLSHtGzd89JIyG++EspmsJdnM3DK5nufZMhxsDSYPfDoBh62/ O8A65cWlsUHBELbT+NvINOwQo2ViNC/8YWHcuFCBIQybgMaCzEU8kYcEnXUPX3Y= =JjiQ -----END PGP SIGNATURE----- --fbAb7kiVb1PXww8xa0IM2EiBfWwVs0Svk-- From nobody Tue Mar 11 23:53:48 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3785B1A08F1 for ; Tue, 11 Mar 2014 23:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWHeXdqDI4nj for ; Tue, 11 Mar 2014 23:53:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id DCC061A0641 for ; Tue, 11 Mar 2014 23:53:45 -0700 (PDT) Received: from [192.168.131.134] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MPIvU-1WS2t82WZc-004Vun; Wed, 12 Mar 2014 07:53:38 +0100 Message-ID: <531F6AC3.90309@gmx.net> Date: Tue, 11 Mar 2014 20:57:55 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hosnieh Rafiee , Ace@ietf.org References: <00f101cf3d5b$736152b0$5a23f810$@rozanak.com> <531F5B7C.40101@gmx.net> <010401cf3d5f$3bb26c10$b3174430$@rozanak.com> <531F6326.2050403@gmx.net> <013801cf3d74$4e60ef70$eb22ce50$@rozanak.com> In-Reply-To: <013801cf3d74$4e60ef70$eb22ce50$@rozanak.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8H8pRTrg9UmbxHM7nMD9SpPcClOSkixrh" X-Provags-ID: V03:K0:ar8juRB4Kv/t1ew/15buocDV4fo7yXu/W53RLDoElxi9/f3CLjs JLlSJzrT2z3tpZ7SCly/3cT3SdRkSB4MG5IZzxoBCJNyJKvyGblvuCqmBEpX7O7k2a2AINw oTXIlhOax7Y6Mv1fKrcx8s2nNjCPMeKOqV8xnIO64k7k3xX4QdZMARyegR25eRrNwBCXXQg LFUQd2DR/c1PGeDCDpD7g== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/uiaDKOteMSQRMExBaUkv_ojmhBM Subject: Re: [Ace] a possible solution candidate? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:53:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8H8pRTrg9UmbxHM7nMD9SpPcClOSkixrh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hosnieh, the desire to re-use DTLS comes from CoAP since the CORE working group (who developed CoAP) decided to pick DTLS as the security mechanism. For constrained devices there is a benefit of re-using code. So far the group has not decided whether the solution will be based on symmetric keys or asymmetric keys. This is a topic for investigation once we get past the charter discussion. Ciao Hannes On 03/11/2014 10:53 PM, Hosnieh Rafiee wrote: > Hi again, >=20 >> the challenge I see is to support the requirements and use cases outli= ned > in >> http://tools.ietf.org/html/draft-seitz-ace-usecases-00 >> I have a hard time to see how that would work. >=20 > As far as I understand, you are going to use TLS as a part of security > approach. To eliminate the need for having certificates for keys, one > *possible* solution is the approach I explained.=20 >=20 >=20 > Thanks, > Best, > Hosnieh >=20 --8H8pRTrg9UmbxHM7nMD9SpPcClOSkixrh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTH2rDAAoJEGhJURNOOiAtqjUH/17TlWj/zkH314SBQlJPkXtK HPf6dXN3cfmlwQaPLxLEzUUFRA5wExG5mOH4mkgYRniDd7D5rukbY7coH+hNgljj hg44oHsYy+HDYncpwihnjxDHBBB9ZjwpXuvfQA0OBdNtzJrWwU56WWT55eYrA/GE VmiH19uVv4xklvkQ2CcomBBfQFRVTNJorvHVUbzXMTrXGujREUTXMvANbSh7fOhq m7lqTHkOjsDLDmOqPlGaQmlhrkEuSivO8n/WclbGmcnNZiVcCdoRnnJ9PL/eXops F4eY5rz5JMXJ8DTtNDF80NqsEZkC3wYf8IG1jq0CWByycL8VYlzw5wLtt0YoBhY= =Z3Xl -----END PGP SIGNATURE----- --8H8pRTrg9UmbxHM7nMD9SpPcClOSkixrh-- From nobody Wed Mar 12 02:32:51 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC531A0941 for ; Wed, 12 Mar 2014 02:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcryHMytA4zQ for ; Wed, 12 Mar 2014 02:32:45 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 169C41A0940 for ; Wed, 12 Mar 2014 02:32:44 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-49-532029b6dee0 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3E.13.23809.6B920235; Wed, 12 Mar 2014 10:32:38 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Wed, 12 Mar 2014 10:32:37 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Zach Shelby , Hannes Tschofenig Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: AQHPPP7mXnQfvixAoUyrPsxr924da5rb+CuAgAE52AA= Date: Wed, 12 Mar 2014 09:32:36 +0000 Message-ID: References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> In-Reply-To: <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9FBC4016DF10CC4FA384E2B520F6EC60@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje42TYVgg3N3pS2+f+thtli68x6r xaVrT9gdmD3WzFvD6LF40342jyVLfjIFMEdx2aSk5mSWpRbp2yVwZfyZvI6pYG9MxcyrC5kb GO97dzFyckgImEg8utPCCmGLSVy4t56ti5GLQ0jgEKPEr1czmSGcJYwSuyZOYwGpYhNwlTjw 4B0TiC0iECaxf/tWRhCbWUBRYt2cPrC4sICOxPW5F4DqOYBqdCWmvHWBKLeS2Dm/jR3EZhFQ lXh7eAJYK6+AucTPmX/BxgsJhEucaXkBFucUsJbYd/cZG4jNCHTc91NrmCBWiUvcejKfCeJo AYkle84zQ9iiEi8f/wN7RlRAT+Leo7lgJ0gAnba8Xw6iVU/ixtQpbBC2tcTz3jMsELa2xLKF r5khzhGUODnzCcsERolZSLbNQtI+C0n7LCTts5C0L2BkXcXInpuYmZNebrSJERh9B7f8Vt3B eOecyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwNi79sbIlubRn3aKI uuT7eRuWK0n7XDi3c/OGMy90go8vntI8WfOf2J3TcXlPjRse5HVMCtp+t6BsA3+157KE2XvL zzcs9GLgi+J22aKfW/RzyrZPwS5pX1686N4t+6L1aOEk+YAijuriX0GX01fdq7TjWvjV6JVn yd7qL7YrbVcXBdhuPSvgp8RSnJFoqMVcVJwIAEN96ySMAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/H3DiItMmGt-29PYCheHvxQ2O-v8 Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 09:32:50 -0000 Hannes, Zach and all, I must say I don=B9t find the task list of the current charter very helpful= : =B3The working group has the following tasks (in this order): 1) The working group Wiki pages will be used to document use cases, requirements, and protocol design criteria. This work will guide the identification of suitable protocol mechanisms. 2) Selection of an authentication and authorization protocol for constrained environments. 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy deployments.=B2 This list does not give much more details about the work to be conducted than is already given by the title of the WG. To a person not having followed the discussion, the impression is that the work starts from scratch and there is no clear understanding of what to do. If we can=B9t formulate the problem statement and first step towards a solution in some degree of detail before starting the WG that will anyway be the first task to do, so let=B9s try to get something in writing. "1) The working group Wiki pages will be used to document use cases, requirements, and protocol design criteria. This work will guide the identification of suitable protocol mechanisms." This is hiding the fact that there has been 6 months of work on the use case and requirements draft (the first version of this draft was submitted to CoRE in IETF88), which no one has disagreed is setting the stage for this work. Look at parallel threads on this mailing list where people ask whether their particular security-for-IoT draft fits into ACE. The answer Hannes is giving is correctly: the scope of this work is what is outlined by the use case and requirements draft. I don=B9t mind using the Wiki as a working tool but this does not give traceability a year later. And I don=B9= t see the point if copying the use case document into a Wiki page - read the draft and provide your comments! When it comes to protocol design criteria, I agree that more work is needed, for which the Wiki may be suitable. Nevertheless I insist on documenting the design criteria and its rationale since that provides a means for traceability. Make it a milestone to have a draft with assumptions and design criteria (you may include =B3architecture=B2 in thi= s document). This work is anyway a pre-requisite for coming to a solution, and once you have this content, the candidate solutions are much easier evaluated. So, change 1) to state something like "1=B9 ) a) complete the work on use case and requirements b) use Wiki pages for listing assumptions and protocol design criteria, document the result in a draft" Proxy deployment aspects fits well into 1b) [more in separate upcoming mail] 2) Selection of an authentication and authorization protocol for constrained environments. Here I=B9m missing among other things the specific problem statement. The preliminary conclusions from the use case and requirements draft formed the basis for the problem statement as presented in the BOF: We lack a mechanism for dynamic and fine grained access control for constrained environments.=20 The process here should be to: "2=B9) identify suitable protocol mechanisms and match candidate authentication and authorization protocols against requirements and design criteria, in particular addressing dynamic and fine grained access control suitable for CoAP resource access requests in constrained environments." 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy deployments.=B2 As mentioned above, proxy deployments could be considered as part of 1=B9b)= . In 2=B9) it is already stated that in particular we should consider CoAP on interface (II). As for use of other protocols besides CoAP that issue is orthogonal to this so I leave that out from this discussion. G=F6ran On 11/03/14 16:49, "Zach Shelby" wrote: >Hannes, > >I am happy with this charter with one exception. The proxy item here >seems to be more of a distraction than anything else, and will probably >result in increased complexity. Was proxy support maybe just a >misunderstanding? Do we really see the need for a proxy in the middle of >I or III? > >I think what we really want here is to make sure that e.g. even through I >is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In other >words, some interfaces can be constrained while others are not. I think >the charter already covers this fine. > >So my proposal would be to remove the mention of protocol translation >proxies. If we really see the need for this some day in the future, it >could be tackled then. > >Zach > >On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig > wrote: > >> Hi all, >> >> I have taken the feedback from the meeting and the recent discussions on >> the mailing list and produced a new strawman proposal. >> >> The changes include: >> * Added the focus on DTLS/CoAP with an indication that we will check a >> candidate solution for suitability with HTTP/TLS. >> * Added text to indicate that we will also verify the suitability of >> the solution for use with protocol translation proxies. >> * Simplified the task list by removing solution specific items. >> * Merged several items on the task list (use cases, requirements, and >> protocol design guidelines). Followed the suggestion to use of a Wiki >> for capturing those. >> >> What do you think? >> >> ----- >> >> Draft Charter V0.5 - Authentication and Authorization for Constrained >> Environment (ACE) >> >> The IETF has recently developed protocols for use in environments where >> network nodes are limited in CPU, memory, and power. It was observed >> that Internet protocols can be applied to these constrained >> environments, often only requiring minor tweaking and profiling. In >> other cases, new protocols have been defined to address the specific >> requirements of constrained devices and networks. An example of such a >> protocol is the Constrained Application Protocol (CoAP). >> components >> As in other environments, authentication and authorization question also >> arise in environments with constrained nodes and networks. For example, >> a door lock has to authorize the person seeking access using a "digital >> key". Where are the authorization decisions stored? How does the digital >> key communicate with the lock? Does the lock interact with an >> authorization server to obtain authorization information? How can access >> be granted to other persons temporarily? How can access be revoked? >> These types of questions have been answered by existing protocols for >> use cases outside the constrained environment. But in constrained >> environment, additional requirements pose challenges for the use of >> various security protocols. >> >> The IETF has a long history in developing three party authentication and >> authorization protocols for distributed environments. Examples include >> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >> Authorization, and Accounting (AAA) infrastructure, and the Web >> Authorization Protocol (OAuth). All these protocols enjoy widespread >> deployment on the Internet. Although they all aim to solve a similar >> goal, at an abstract level, they offer quite different functions and >> utilize different message exchanges. These differences are motivated by >> the main deployment use cases they were designed for. >> >> Requirements derived from use cases indicate the suitability of already >> existing work, such as OAuth, as a solution for constrained >> environments. These protocols were, however, not optimized for >> constrained environments. Additional requirements that need to be taken >> into account are the lack of a suitable user-interface for obtaining the >> consent of the user and the inability of embedded devices to contact an >> authorization server in real-time with every access request due to >> intermittent connectivity, etc. >> >> This working group therefore aims for a standardized solution for >> authentication and authorization to enable authorized access to >> resources in constrained environments. As a starting point, the working >> group will assume that access to resources offered by a resource server >> by a client devices takes place using CoAP and is protected by DTLS. >> Both resource server and client may be resource constraint. This access >> will be mediated by an authorization server, which does not suffer from >> the same resource limitations. >> >> Existing authentication and authorization protocols are used and >> re-applied for use with constrained devices, where applicable. This >> requires relevant specifications to be reviewed for suitability, >> selecting a subset of them, restricting the options within each of the >> specifications. Some functionalities may, however, not be available in >> existing protocols and for those cases new functionality has to be >> standardized. Thus, existing work can be leveraged and the group >> benefits from available security analysis, implementation, and >> deployment experience. Moreover, a standardized solution for federated >> authentication and authorization will help to stimulate the deployment >> of IoT devices offering increased security. >> >> Once progress in identifying suitable candidate solutions has been made >> the working group will verify whether the same mechanism are also >> applicable beyond the use of CoAP and DTLS. In particular, the ability >> to use the developed solution over HTTP and TLS will be investigated. >> Furthermore, to guarantee smooth transition the integration with >> existing deployment will be studied. This particularly concerns the use >> of protocol translation proxies. >> >> To be successful this working group requires expertise in security, >> privacy, and a good understanding of usability in the constrained >> environment space. This work does not make the assumption that the party >> offering application layer services is always the same party offering >> network access services. >> >> The working group has the following tasks (in this order): >> >> 1) The working group Wiki pages will be used to document use cases, >> requirements, and protocol design criteria. This work will guide the >> identification of suitable protocol mechanisms. >> >> 2) Selection of an authentication and authorization protocol for >> constrained environments. >> >> 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy >> deployments. >> >> ----- >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > >Zach Shelby >Director of Technology >ARM Internet of Things BU >www.arm.com >mobile: +1 (408) 203-9434 >Skype: zdshelby >LinkedIn: fi.linkedin.com/in/zachshelby/ > > >-- IMPORTANT NOTICE: The contents of this email and any attachments are >confidential and may also be privileged. If you are not the intended >recipient, please notify the sender immediately and do not disclose the >contents to any other person, use it for any purpose, or store or copy >the information in any medium. Thank you. > >ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >Registered in England & Wales, Company No: 2557590 >ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >Registered in England & Wales, Company No: 2548782 > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Wed Mar 12 08:59:22 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8D1A09CA for ; Wed, 12 Mar 2014 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7WpvYMWCd2T for ; Wed, 12 Mar 2014 08:59:17 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1A21A09C3 for ; Wed, 12 Mar 2014 08:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1394639948; l=1643; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=a31uuaJWKvXIE8LVa6zQ8Wc+/Qc=; b=EMcfCiquODxDMHjL99+zDUWZ2o112RNa7loxi7bbjvyo8HtbSHLAaCzlPRWbklJv5zm KCycsTeGJEhercpuO9SNanFHkDaRqL8u3HKk2jDlFSUNvWR3aZtNYRJbcZVIkV4vUcgR9 WHnG0xTiPpADxAPQY6gIWVYT4USGYzqzOXw= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSE4QZmtmQ X-RZG-CLASS-ID: mo00 Received: from mail-qc0-f173.google.com ([209.85.216.173]) by smtp.strato.de (RZmta 32.27 AUTH) with ESMTPSA id d01722q2CFx5tPy (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - certificate not trusted)) (Client hostname not verified) for ; Wed, 12 Mar 2014 16:59:05 +0100 (CET) Received: by mail-qc0-f173.google.com with SMTP id r5so11323611qcx.4 for ; Wed, 12 Mar 2014 08:59:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kEHz2syk7bIUgsT+UI8x7LmkyythOuppmRqYo0YlX1g=; b=i/O9XI1PC9nV8zqg40espbNPtz2FaZoYj1kHZ1Z44RalxiXtkjiSsvlhKWRdwrvLPn 13V0aBuAAWA6c5vy8vJJxJdOmgpMxHqxkbXFj0tlZFqyX5KDGxB7dumDevpqdyRB+3vl +w4FevbRmhhbjXIbX3UL218UhnK5EbIYVAAyaX5gsqTm9bwZfWZ8FepxoYRE2sLdt8w3 aJL8N+rUGQeObUp4kTQduJdge0YGth19HMuab7yRyumQDE35GEXUQFqfD6qYcKzmAbAG 0kGK2wD1OVbmy5JLQxADgaJb3HJLpRxbI2WFOodk0EKHbXp7OFi0t+Cua9k23HH5hKl4 0m1g== MIME-Version: 1.0 X-Received: by 10.229.172.4 with SMTP id j4mr49770078qcz.6.1394639944307; Wed, 12 Mar 2014 08:59:04 -0700 (PDT) Received: by 10.224.31.80 with HTTP; Wed, 12 Mar 2014 08:59:04 -0700 (PDT) In-Reply-To: <531F6730.3050604@gmx.net> References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> <7540.1394293121@sandelman.ca> <531F6CBF.2000600@gridmerge.com> <531F6730.3050604@gmx.net> Date: Wed, 12 Mar 2014 16:59:04 +0100 Message-ID: From: Sandeep Kumar To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c33d8078774e04f46aeadd Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3RT1TOjbc80lXEwwbIr7fS_nq5Y Cc: "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:59:21 -0000 --001a11c33d8078774e04f46aeadd Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes On Tue, Mar 11, 2014 at 8:42 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > > 1) You need to tie the application layer security to the channel > security since otherwise you introduce attacks. > > Are you referring to the authorization tokens being tied to the (DTLS) channel rather than to the device identity. Can you clarify what you mean by the above statement and what attacks are you referring to? regards Sandeep --001a11c33d8078774e04f46aeadd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes


On Tue, Mar 11, 2014= at 8:42 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net><= /span> wrote:

1) You need to tie the application layer security to the channel
security since otherwise you introduce attacks.


Are you referring to the authorizati= on tokens being tied to the (DTLS) channel rather than to the device identi= ty.
Can you clarify what you mean by the above statement and what attack= s are you referring to?

regards
Sandeep
<= /div> --001a11c33d8078774e04f46aeadd-- From nobody Thu Mar 13 00:29:11 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42A71A08F3 for ; Thu, 13 Mar 2014 00:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwjyy60koM92 for ; Thu, 13 Mar 2014 00:29:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B34F51A03BD for ; Thu, 13 Mar 2014 00:29:05 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M3i8r-1XEanD0Zg9-00rGEP; Thu, 13 Mar 2014 08:28:58 +0100 Message-ID: <5320C03E.7020607@gmx.net> Date: Wed, 12 Mar 2014 21:14:54 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sandeep Kumar References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> <7540.1394293121@sandelman.ca> <531F6CBF.2000600@gridmerge.com> <531F6730.3050604@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7riqCoWvmuenijpfpjHR8K2TW7AKRexqV" X-Provags-ID: V03:K0:uM9dlfhovEhnEvAwn16E7eSLrJvH2MtkFd6/RIVzlbrtk1nb2t8 OqT4w0dNmVvNf8keaMm0ceLSVspQt0jiCjomV/zdH9n6M5q9jS0NUEBZNvlmYpz1u5QyRHA 0nKUQkw5LMFC3NrmMrnRQPADL9ETg7El0t7dDC81++1L6xWzxZ5uZNsy3HP2l0Qcn5wLb1s IhQRqurUjEB6OMfyEOjDg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/otEk8Iidwj5RiXZRn_2HPLi3LeE Cc: "ace@ietf.org" Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 07:29:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7riqCoWvmuenijpfpjHR8K2TW7AKRexqV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This might be a bit too much into the solution space but in this specific case you might recall that some deployments either use TLS proxies that do a MITM (enterprise networks etc.) or terminate TLS servers at the edge of the network. Without TLS end-to-end you obviously don't get the security benefits from it at the application layer. Ciao Hannes On 03/12/2014 04:59 PM, Sandeep Kumar wrote: > Hi Hannes >=20 >=20 > On Tue, Mar 11, 2014 at 8:42 PM, Hannes Tschofenig > > wrote: >=20 >=20 > 1) You need to tie the application layer security to the channel > security since otherwise you introduce attacks. >=20 >=20 > Are you referring to the authorization tokens being tied to the (DTLS) > channel rather than to the device identity. > Can you clarify what you mean by the above statement and what attacks > are you referring to? >=20 > regards > Sandeep --7riqCoWvmuenijpfpjHR8K2TW7AKRexqV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIMA+AAoJEGhJURNOOiAt8BsH/j+gSEMEIzgmDD8+mPUP+1nK +bm+pnNXYOzwcsB3c7UXW161DVYjX2rwB+0/AKYp+AvhH5y2nEqcWy9YVsCr4ZFu 1PKDLk0EBdvoQD/7a11IqZ4elSpP+YFZyu6Rf9BwkwEl6vTMpUvD4txgHW+Z5AZe 08vX8Bypsa+EITGFlmto2k1gZkJVpzPeu+M/M5NESydhiTMhL6fgTUQYl+0Ki8bW vHQAuwzXVC/zhDE9UV8NZw7Bj8yb1ijkviLjDxj/qWyz/Zjd3cbuCIZa6N163fwi F7EH98egJoP57BoBStvIK1a4C9eQ3Q9SHNvN31tK0xeT1LIjxFeVGnqTqQvhWWw= =bExR -----END PGP SIGNATURE----- --7riqCoWvmuenijpfpjHR8K2TW7AKRexqV-- From nobody Thu Mar 13 00:47:44 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2961A0953 for ; Thu, 13 Mar 2014 00:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv5loxwpUYyP for ; Thu, 13 Mar 2014 00:47:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BB1A094B for ; Thu, 13 Mar 2014 00:47:38 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LjuR3-1WzH3b2RXl-00bpmx; Thu, 13 Mar 2014 08:47:30 +0100 Message-ID: <5320C480.9070609@gmx.net> Date: Wed, 12 Mar 2014 21:33:04 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=F6ran_Selander?= , Zach Shelby References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jhNaAOmC3Uu9sWiWh2OOMlgqMMMao6vam" X-Provags-ID: V03:K0:UPHQvaLlMUnk+P/qdZk6lekIGARiDoGnOXI1+oZjVAVV14zERgW 9rVn8kHlW0sTiBvOv2gtmwIVhlc9bGhvPadCvsgumLlbRseyh+WHp/h0tX7qzNTzxup9ON2 sVjCJ3ytfDKOmjzGoENM6a53TNlQrzJT1dEM/3vlD9NhceNCOU8EqpRAEHhxOYO26yk32ep A2O9nns0tt/cmnGRi+tSw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Os3jFhCuRsflL-VcMLod1oTDnIU Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 07:47:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jhNaAOmC3Uu9sWiWh2OOMlgqMMMao6vam Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Goeran, I read a little bit between the lines of your mail and your main concern is that you want to have an RFC published with your name on it. A wiki page to document the requirements, and use cases is not good enough for you. For you putting the draft text on a WG wiki feels like wasted time. It is just a different form of documenting the work. My experience with use cases and requirements has not been great in the IETF. In essence everyone quickly moves on once the group decides about a particular solution direction. It then becomes very hard (for the chairs) to finish the requirements work since nobody wants to review or look at them anymore. Use cases and requirements are great during the initial part of the work to get an understanding of the main challenges. Having said that I will leave it to the group to decide what they want to do: RFCs or Wiki page Ciao Hannes PS: Regarding your other comment about pointing to the constraint nature to every item. We can do that if you feel better but the entire charter page already says 10 times that we are focusing on the constraint space. I am sure that the reader will have understood that when they get to the task list. On 03/12/2014 10:32 AM, G=F6ran Selander wrote: > Hannes, Zach and all, >=20 > I must say I don=B9t find the task list of the current charter very hel= pful: >=20 > =B3The working group has the following tasks (in this order): >=20 > 1) The working group Wiki pages will be used to document use cases, > requirements, and protocol design criteria. This work will guide the > identification of suitable protocol mechanisms. >=20 > 2) Selection of an authentication and authorization protocol for > constrained environments. >=20 > 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy= > deployments.=B2 >=20 > This list does not give much more details about the work to be conducte= d > than is already given by the title of the WG. To a person not having > followed the discussion, the impression is that the work starts from > scratch and there is no clear understanding of what to do. >=20 > If we can=B9t formulate the problem statement and first step towards a > solution in some degree of detail before starting the WG that will anyw= ay > be the first task to do, so let=B9s try to get something in writing. >=20 >=20 > "1) The working group Wiki pages will be used to document use cases, > requirements, and protocol design criteria. This work will guide the > identification of suitable protocol mechanisms." >=20 > This is hiding the fact that there has been 6 months of work on the use= > case and requirements draft (the first version of this draft was submit= ted > to CoRE in IETF88), which no one has disagreed is setting the stage for= > this work. Look at parallel threads on this mailing list where people a= sk > whether their particular security-for-IoT draft fits into ACE. The answ= er > Hannes is giving is correctly: the scope of this work is what is outlin= ed > by the use case and requirements draft. I don=B9t mind using the Wiki a= s a > working tool but this does not give traceability a year later. And I do= n=B9t > see the point if copying the use case document into a Wiki page - read = the > draft and provide your comments! >=20 > When it comes to protocol design criteria, I agree that more work is > needed, for which the Wiki may be suitable. Nevertheless I insist on > documenting the design criteria and its rationale since that provides a= > means for traceability. Make it a milestone to have a draft with > assumptions and design criteria (you may include =B3architecture=B2 in= this > document). This work is anyway a pre-requisite for coming to a solution= , > and once you have this content, the candidate solutions are much easier= > evaluated. >=20 > So, change 1) to state something like >=20 > "1=B9 ) > a) complete the work on use case and requirements > b) use Wiki pages for listing assumptions and protocol design criteria,= > document the result in a draft" >=20 > Proxy deployment aspects fits well into 1b) [more in separate upcoming= > mail] >=20 >=20 > 2) Selection of an authentication and authorization protocol for > constrained environments. >=20 > Here I=B9m missing among other things the specific problem statement. T= he > preliminary conclusions from the use case and requirements draft formed= > the basis for the problem statement as presented in the BOF: We lack a > mechanism for dynamic and fine grained access control for constrained > environments.=20 >=20 > The process here should be to: > "2=B9) identify suitable protocol mechanisms and match candidate > authentication and authorization protocols against requirements and des= ign > criteria, in particular addressing dynamic and fine grained access cont= rol > suitable for CoAP resource access requests in constrained environments.= " >=20 >=20 >=20 > 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy= > deployments.=B2 >=20 >=20 > As mentioned above, proxy deployments could be considered as part of 1=B9= b). > In 2=B9) it is already stated that in particular we should consider CoA= P on > interface (II). As for use of other protocols besides CoAP that issue i= s > orthogonal to this so I leave that out from this discussion. >=20 >=20 >=20 > G=F6ran >=20 >=20 >=20 >=20 >=20 > On 11/03/14 16:49, "Zach Shelby" wrote: >=20 >> Hannes, >> >> I am happy with this charter with one exception. The proxy item here >> seems to be more of a distraction than anything else, and will probabl= y >> result in increased complexity. Was proxy support maybe just a >> misunderstanding? Do we really see the need for a proxy in the middle = of >> I or III? >> >> I think what we really want here is to make sure that e.g. even throug= h I >> is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In oth= er >> words, some interfaces can be constrained while others are not. I thin= k >> the charter already covers this fine. >> >> So my proposal would be to remove the mention of protocol translation >> proxies. If we really see the need for this some day in the future, it= >> could be tackled then. >> >> Zach >> >> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig >> wrote: >> >>> Hi all, >>> >>> I have taken the feedback from the meeting and the recent discussions= on >>> the mailing list and produced a new strawman proposal. >>> >>> The changes include: >>> * Added the focus on DTLS/CoAP with an indication that we will check = a >>> candidate solution for suitability with HTTP/TLS. >>> * Added text to indicate that we will also verify the suitability of >>> the solution for use with protocol translation proxies. >>> * Simplified the task list by removing solution specific items. >>> * Merged several items on the task list (use cases, requirements, and= >>> protocol design guidelines). Followed the suggestion to use of a Wiki= >>> for capturing those. >>> >>> What do you think? >>> >>> ----- >>> >>> Draft Charter V0.5 - Authentication and Authorization for Constrained= >>> Environment (ACE) >>> >>> The IETF has recently developed protocols for use in environments whe= re >>> network nodes are limited in CPU, memory, and power. It was observed >>> that Internet protocols can be applied to these constrained >>> environments, often only requiring minor tweaking and profiling. In >>> other cases, new protocols have been defined to address the specific >>> requirements of constrained devices and networks. An example of such = a >>> protocol is the Constrained Application Protocol (CoAP). >>> components >>> As in other environments, authentication and authorization question a= lso >>> arise in environments with constrained nodes and networks. For exampl= e, >>> a door lock has to authorize the person seeking access using a "digit= al >>> key". Where are the authorization decisions stored? How does the digi= tal >>> key communicate with the lock? Does the lock interact with an >>> authorization server to obtain authorization information? How can acc= ess >>> be granted to other persons temporarily? How can access be revoked? >>> These types of questions have been answered by existing protocols for= >>> use cases outside the constrained environment. But in constrained >>> environment, additional requirements pose challenges for the use of >>> various security protocols. >>> >>> The IETF has a long history in developing three party authentication = and >>> authorization protocols for distributed environments. Examples includ= e >>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>> Authorization, and Accounting (AAA) infrastructure, and the Web >>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>> deployment on the Internet. Although they all aim to solve a similar >>> goal, at an abstract level, they offer quite different functions and >>> utilize different message exchanges. These differences are motivated = by >>> the main deployment use cases they were designed for. >>> >>> Requirements derived from use cases indicate the suitability of alrea= dy >>> existing work, such as OAuth, as a solution for constrained >>> environments. These protocols were, however, not optimized for >>> constrained environments. Additional requirements that need to be tak= en >>> into account are the lack of a suitable user-interface for obtaining = the >>> consent of the user and the inability of embedded devices to contact = an >>> authorization server in real-time with every access request due to >>> intermittent connectivity, etc. >>> >>> This working group therefore aims for a standardized solution for >>> authentication and authorization to enable authorized access to >>> resources in constrained environments. As a starting point, the worki= ng >>> group will assume that access to resources offered by a resource serv= er >>> by a client devices takes place using CoAP and is protected by DTLS. >>> Both resource server and client may be resource constraint. This acce= ss >>> will be mediated by an authorization server, which does not suffer fr= om >>> the same resource limitations. >>> >>> Existing authentication and authorization protocols are used and >>> re-applied for use with constrained devices, where applicable. This >>> requires relevant specifications to be reviewed for suitability, >>> selecting a subset of them, restricting the options within each of th= e >>> specifications. Some functionalities may, however, not be available i= n >>> existing protocols and for those cases new functionality has to be >>> standardized. Thus, existing work can be leveraged and the group >>> benefits from available security analysis, implementation, and >>> deployment experience. Moreover, a standardized solution for federate= d >>> authentication and authorization will help to stimulate the deploymen= t >>> of IoT devices offering increased security. >>> >>> Once progress in identifying suitable candidate solutions has been ma= de >>> the working group will verify whether the same mechanism are also >>> applicable beyond the use of CoAP and DTLS. In particular, the abilit= y >>> to use the developed solution over HTTP and TLS will be investigated.= >>> Furthermore, to guarantee smooth transition the integration with >>> existing deployment will be studied. This particularly concerns the u= se >>> of protocol translation proxies. >>> >>> To be successful this working group requires expertise in security, >>> privacy, and a good understanding of usability in the constrained >>> environment space. This work does not make the assumption that the pa= rty >>> offering application layer services is always the same party offering= >>> network access services. >>> >>> The working group has the following tasks (in this order): >>> >>> 1) The working group Wiki pages will be used to document use cases, >>> requirements, and protocol design criteria. This work will guide the >>> identification of suitable protocol mechanisms. >>> >>> 2) Selection of an authentication and authorization protocol for >>> constrained environments. >>> >>> 3) Evaluation of the candidate solution for use with HTTP/TLS and pro= xy >>> deployments. >>> >>> ----- >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >> >> Zach Shelby >> Director of Technology >> ARM Internet of Things BU >> www.arm.com >> mobile: +1 (408) 203-9434 >> Skype: zdshelby >> LinkedIn: fi.linkedin.com/in/zachshelby/ >> >> >> -- IMPORTANT NOTICE: The contents of this email and any attachments ar= e >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose th= e >> contents to any other person, use it for any purpose, or store or copy= >> the information in any medium. Thank you. >> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >> Registered in England & Wales, Company No: 2557590 >> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9= NJ, >> Registered in England & Wales, Company No: 2548782 >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --jhNaAOmC3Uu9sWiWh2OOMlgqMMMao6vam Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIMSAAAoJEGhJURNOOiAtoTcIAKQ+f81zhdeqvSixpLX1ZoJ4 jg3z+haQR92Z3r/z1jdTAm1a8mu38iNH7lzldSqQb+P1EmC6pYwIjQhQwxstAtEQ lD5er2gFogUTbHosXk8vcSMfgP8RRgybAyHS/PRUIgy48cvp7R53U9hNwo4BEO5i Cbff0ZmzId0qE82wn9d4gBg9YUleG6Ekt5R+x79ZV/QSJPAd4O4ZGGzAkeoTSp1+ dkKxcUs1opIrtC5HkrxzQdlwxetU/FSJkidUNCu1YOoZ1Oc+UF7j6sAvIyrweDWY MHh7ROJXhvbVQUAO3D6gXNgd2NH74urWy9d5NlBlHRAJWPYri22ra2DC6IaCi5k= =M3be -----END PGP SIGNATURE----- --jhNaAOmC3Uu9sWiWh2OOMlgqMMMao6vam-- From nobody Thu Mar 13 01:24:05 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184A61A096F for ; Thu, 13 Mar 2014 01:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXgH5kquRG8k for ; Thu, 13 Mar 2014 01:23:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50B1A0979 for ; Thu, 13 Mar 2014 01:23:55 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MIyCj-1WPvfm0Sdd-002V0a; Thu, 13 Mar 2014 09:23:47 +0100 Message-ID: <5320CCD5.2040006@gmx.net> Date: Wed, 12 Mar 2014 22:08:37 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=F6ran_Selander?= , "ace@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PsRD0uM7XTvgc911RFeeQGtQsXGr2a0Ob" X-Provags-ID: V03:K0:RXCz7jddWvFtJdxdqhxfDca5dS9Uz84M+ZNS8FgJCz9dr+K1oTH Xyl7CaQzXWgq9Yl5y1yjtw/BQGaitAu2VXDhkeYyLtzK0BSogs/wRrknRaicVPLw6MBYsER fFAspyHL6p/KMBGB8v1V3SQjUqtGj05Z03b3+6QpspQ8+pzsZa1fOwH61a2+8vLp+9uP04a J12t+YN4p4yt9umxMBevA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/6TG5NwlBOuxxDv7NBFN8saiO0zc Subject: Re: [Ace] ACE Charter - connectivity assumptions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 08:24:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PsRD0uM7XTvgc911RFeeQGtQsXGr2a0Ob Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Goeran, thanks for moving this difficult point forward. Comments inline. On 03/11/2014 10:26 AM, G=F6ran Selander wrote: >=20 > During the BOF it was requested to be more specific about the connectiv= ity > assumptions of the various nodes, more specifically whether it could be= > assumed that the RS or the Client could connect to the AS. The discussi= on > was very focused on the particular use case presented at the BOF. Here = are > some starting points for further discussion. >=20 > 1. The discussion relates to Client or RS connectivity to the AS for > obtaining relevant authorization information. If valid authorization in= fo > is already available to the RS, it should not be necessary to connect t= o > the AS.=20 Yes, if the authorization information + keying material is already cached then it does not need to be retrieved again. There is, however, a trade-off when it comes to revocation: the longer you are able to cache the more difficult it will be to quickly revoke. >=20 > 2. It was acknowledged that in the particular use case (container > transport at sea) Internet connectivity could not be assumed. Even if t= his > hadn=B9t been the case, e.g. truck/train transport or other use case, w= e > should not take for granted that billions of devices are always connect= ed > just because it is theoretically possible. Internet connectivity has a > cost and low cost is one of the reasons why constrained devices are at = all > used. There may be some need for configuration needed to secure > connectivity, which may be missing if the environment changes as was > illustrated by the use case. Etc. . With this in mind, we should assume= > that for certain use cases the constrained Client or RS may be > disconnected from the Internet for periods of time. What about having connectivity to an authorization server that is on board the ship? To translate this to the home networking case you it is one thing to assume connectivity to some server on the Internet and a different aspect to assume connectivity to an authorization in the user's home network. Needless to say with your assumption is that if you do not have Internet connectivity then some value of Internet connected devices (e.g., remote monitoring, remote configuration) goes away. >=20 > 3. Even if the AS is not a constrained device it may be disconnected fr= om > time to other. For some use cases, AS functionality may be implemented = in > devices which are not always available, e.g. the Resource Owner=B9s > smartphone, home server or some other device which may be occasionally > switched off or disconnected. Do we accept the side effect that the solution will not work in some of those cases? If there is no information cached at client<->RS then without connectivity to the AS the entire mechanism will not work. > In general we should assume that Client and RS may have intermittent > connectivity with the AS, and in particular that it cannot be guarante= ed > that there is connectivity to the AS at the time of the access request.= You are saying that with some requests you assume there is connectivity and with other requests there isn't. That does not sound right to me. The client / RS needs to obtain authorization information and keying material from the AS. They also need to peridically check the revocation status. They are also likely to require time information. This will not work without some level of connectivity. Ciao Hannes >=20 >=20 > G=F6ran >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --PsRD0uM7XTvgc911RFeeQGtQsXGr2a0Ob Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIMzVAAoJEGhJURNOOiAtkt8H/29Kb/mH63mWxpJkBBv718Tb cJeRx0lbfTmZDnDoNcWon1NZZh0OMQkWaPIZkaALP2nCQQKKYX1NCW8WbHD4hg7b iWsICtAh2z/KcBd9zMn1ikRwNX3d7H5BAC7YLFHl+onnnSlzU/hf+Cm2OKS2oDPq o+fJyN5YkHzvgY6qo7lahPpOrTlPdiNlmoXE2uwx8ADYLhyJz9ZAhfxWVy4B6gTQ /H65pX+z7aDdiyNtTDy0A9vdo1CpK7QsfwsdlEXNhxy9rBiCV41dfz1c5Y8WiwfQ X0awekAfZiWV/gHzMK6Xm1ZjS3Thzxu/c0naok6NC96aZ28FcZLjJy0TSyyCe2A= =U3Xa -----END PGP SIGNATURE----- --PsRD0uM7XTvgc911RFeeQGtQsXGr2a0Ob-- From nobody Thu Mar 13 01:29:13 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B391A0967 for ; Thu, 13 Mar 2014 01:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xS-JgjhbRKJ for ; Thu, 13 Mar 2014 01:29:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 491C61A095A for ; Thu, 13 Mar 2014 01:29:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEN27215; Thu, 13 Mar 2014 08:29:00 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Mar 2014 08:28:05 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Mar 2014 08:28:58 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 16:28:54 +0800 From: Likepeng To: Hannes Tschofenig , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , Zach Shelby Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: AQHPPP7omD28fVgNqkuQ/CK86XiTM5rbgtOAgAEpFACAALiIAIABSmuA Date: Thu, 13 Mar 2014 08:28:54 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B03B5A@SZXEMA501-MBS.china.huawei.com> References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> <5320C480.9070609@gmx.net> In-Reply-To: <5320C480.9070609@gmx.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/TykoR9Y-Drqnt_ArUFHKvkBVg0A Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 08:29:11 -0000 TXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0IHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRz IGRvY3VtZW50IGNhbiBoZWxwIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQga2luZCBvZiBpc3N1 ZXMgd2UgYXJlIHRyeWluZyB0byByZXNvbHZlLg0KDQpJIGNhbiBzZWUgc29tZSB2YWx1ZXMgdG8g cHVibGlzaCBpdCBpbnRvIFJGQ3MuIElmIGl0IGlzIGEgd2lraSBwYWdlLCB3ZSB3aWxsIGhhdmUg bGVzcyBwZW9wbGUgdG8gcmV2aWV3IGl0IG9yIGltcHJvdmUgaXQuIA0KDQpFc3BlY2lhbGx5IHRo ZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnQgZG9jdW1lbnQgaXMgYWxyZWFkeSBpbiBhIGdvb2Qg c2hhcGUgYW5kIGl0IGlzIHJlZmVyZW5jZWQgc2V2ZXJhbCB0aW1lcyBpbiB0aGUgbWFpbGluZyBs aXN0IHRvIGludHJvZHVjZSBvdXIgd29yayB0byBvdXRzaWRlLg0KDQpUaGFua3MsDQoNCktpbmQg UmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6 IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggSGFubmVzIFRzY2hvZmVu aWcNCj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0M+aciDEz5pelIDQ6MzMNCj4g5pS25Lu25Lq6OiBH w7ZyYW4gU2VsYW5kZXI7IFphY2ggU2hlbGJ5DQo+IOaKhOmAgTogYWNlQGlldGYub3JnDQo+IOS4 u+mimDogUmU6IFtBY2VdIEFDRSBDaGFydGVyIFByb3Bvc2FsIHYwLjUNCj4gDQo+IEhpIEdvZXJh biwNCj4gDQo+IEkgcmVhZCBhIGxpdHRsZSBiaXQgYmV0d2VlbiB0aGUgbGluZXMgb2YgeW91ciBt YWlsIGFuZCB5b3VyIG1haW4gY29uY2VybiBpcyB0aGF0DQo+IHlvdSB3YW50IHRvIGhhdmUgYW4g UkZDIHB1Ymxpc2hlZCB3aXRoIHlvdXIgbmFtZSBvbiBpdC4NCj4gQSB3aWtpIHBhZ2UgdG8gZG9j dW1lbnQgdGhlIHJlcXVpcmVtZW50cywgYW5kIHVzZSBjYXNlcyBpcyBub3QgZ29vZCBlbm91Z2gN Cj4gZm9yIHlvdS4NCj4gDQo+IEZvciB5b3UgcHV0dGluZyB0aGUgZHJhZnQgdGV4dCBvbiBhIFdH IHdpa2kgZmVlbHMgbGlrZSB3YXN0ZWQgdGltZS4NCj4gSXQgaXMganVzdCBhIGRpZmZlcmVudCBm b3JtIG9mIGRvY3VtZW50aW5nIHRoZSB3b3JrLg0KPiANCj4gTXkgZXhwZXJpZW5jZSB3aXRoIHVz ZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGhhcyBub3QgYmVlbiBncmVhdCBpbiB0aGUgSUVURi4N Cj4gSW4gZXNzZW5jZSBldmVyeW9uZSBxdWlja2x5IG1vdmVzIG9uIG9uY2UgdGhlIGdyb3VwIGRl Y2lkZXMgYWJvdXQgYQ0KPiBwYXJ0aWN1bGFyIHNvbHV0aW9uIGRpcmVjdGlvbi4gSXQgdGhlbiBi ZWNvbWVzIHZlcnkgaGFyZCAoZm9yIHRoZQ0KPiBjaGFpcnMpIHRvIGZpbmlzaCB0aGUgcmVxdWly ZW1lbnRzIHdvcmsgc2luY2Ugbm9ib2R5IHdhbnRzIHRvIHJldmlldyBvciBsb29rDQo+IGF0IHRo ZW0gYW55bW9yZS4NCj4gDQo+IFVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGFyZSBncmVhdCBk dXJpbmcgdGhlIGluaXRpYWwgcGFydCBvZiB0aGUgd29yayB0byBnZXQNCj4gYW4gdW5kZXJzdGFu ZGluZyBvZiB0aGUgbWFpbiBjaGFsbGVuZ2VzLg0KPiANCj4gSGF2aW5nIHNhaWQgdGhhdCBJIHdp bGwgbGVhdmUgaXQgdG8gdGhlIGdyb3VwIHRvIGRlY2lkZSB3aGF0IHRoZXkgd2FudCB0byBkbzoN Cj4gUkZDcyBvciBXaWtpIHBhZ2UNCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0KPiBQUzogUmVn YXJkaW5nIHlvdXIgb3RoZXIgY29tbWVudCBhYm91dCBwb2ludGluZyB0byB0aGUgY29uc3RyYWlu dCBuYXR1cmUgdG8NCj4gZXZlcnkgaXRlbS4gV2UgY2FuIGRvIHRoYXQgaWYgeW91IGZlZWwgYmV0 dGVyIGJ1dCB0aGUgZW50aXJlIGNoYXJ0ZXIgcGFnZQ0KPiBhbHJlYWR5IHNheXMgMTAgdGltZXMg dGhhdCB3ZSBhcmUgZm9jdXNpbmcgb24gdGhlIGNvbnN0cmFpbnQgc3BhY2UuDQo+IEkgYW0gc3Vy ZSB0aGF0IHRoZSByZWFkZXIgd2lsbCBoYXZlIHVuZGVyc3Rvb2QgdGhhdCB3aGVuIHRoZXkgZ2V0 IHRvIHRoZSB0YXNrDQo+IGxpc3QuDQo+IA0KPiANCj4gT24gMDMvMTIvMjAxNCAxMDozMiBBTSwg R8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPiA+IEhhbm5lcywgWmFjaCBhbmQgYWxsLA0KPiA+DQo+ ID4gSSBtdXN0IHNheSBJIGRvbsK5dCBmaW5kIHRoZSB0YXNrIGxpc3Qgb2YgdGhlIGN1cnJlbnQg Y2hhcnRlciB2ZXJ5IGhlbHBmdWw6DQo+ID4NCj4gPiDCs1RoZSB3b3JraW5nIGdyb3VwIGhhcyB0 aGUgZm9sbG93aW5nIHRhc2tzIChpbiB0aGlzIG9yZGVyKToNCj4gPg0KPiA+IDEpIFRoZSB3b3Jr aW5nIGdyb3VwIFdpa2kgcGFnZXMgd2lsbCBiZSB1c2VkIHRvIGRvY3VtZW50IHVzZSBjYXNlcywN Cj4gPiByZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEuIFRoaXMgd29y ayB3aWxsIGd1aWRlIHRoZQ0KPiA+IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3RvY29s IG1lY2hhbmlzbXMuDQo+ID4NCj4gPiAyKSBTZWxlY3Rpb24gb2YgYW4gYXV0aGVudGljYXRpb24g YW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9yDQo+ID4gY29uc3RyYWluZWQgZW52aXJvbm1l bnRzLg0KPiA+DQo+ID4gMykgRXZhbHVhdGlvbiBvZiB0aGUgY2FuZGlkYXRlIHNvbHV0aW9uIGZv ciB1c2Ugd2l0aCBIVFRQL1RMUyBhbmQNCj4gPiBwcm94eSBkZXBsb3ltZW50cy7Csg0KPiA+DQo+ ID4gVGhpcyBsaXN0IGRvZXMgbm90IGdpdmUgbXVjaCBtb3JlIGRldGFpbHMgYWJvdXQgdGhlIHdv cmsgdG8gYmUNCj4gPiBjb25kdWN0ZWQgdGhhbiBpcyBhbHJlYWR5IGdpdmVuIGJ5IHRoZSB0aXRs ZSBvZiB0aGUgV0cuIFRvIGEgcGVyc29uDQo+ID4gbm90IGhhdmluZyBmb2xsb3dlZCB0aGUgZGlz Y3Vzc2lvbiwgdGhlIGltcHJlc3Npb24gaXMgdGhhdCB0aGUgd29yaw0KPiA+IHN0YXJ0cyBmcm9t IHNjcmF0Y2ggYW5kIHRoZXJlIGlzIG5vIGNsZWFyIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB0byBk by4NCj4gPg0KPiA+IElmIHdlIGNhbsK5dCBmb3JtdWxhdGUgdGhlIHByb2JsZW0gc3RhdGVtZW50 IGFuZCBmaXJzdCBzdGVwIHRvd2FyZHMgYQ0KPiA+IHNvbHV0aW9uIGluIHNvbWUgZGVncmVlIG9m IGRldGFpbCBiZWZvcmUgc3RhcnRpbmcgdGhlIFdHIHRoYXQgd2lsbA0KPiA+IGFueXdheSBiZSB0 aGUgZmlyc3QgdGFzayB0byBkbywgc28gbGV0wrlzIHRyeSB0byBnZXQgc29tZXRoaW5nIGluIHdy aXRpbmcuDQo+ID4NCj4gPg0KPiA+ICIxKSBUaGUgd29ya2luZyBncm91cCBXaWtpIHBhZ2VzIHdp bGwgYmUgdXNlZCB0byBkb2N1bWVudCB1c2UgY2FzZXMsDQo+ID4gcmVxdWlyZW1lbnRzLCBhbmQg cHJvdG9jb2wgZGVzaWduIGNyaXRlcmlhLiBUaGlzIHdvcmsgd2lsbCBndWlkZSB0aGUNCj4gPiBp ZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNoYW5pc21zLiINCj4gPg0KPiA+ IFRoaXMgaXMgaGlkaW5nIHRoZSBmYWN0IHRoYXQgdGhlcmUgaGFzIGJlZW4gNiBtb250aHMgb2Yg d29yayBvbiB0aGUNCj4gPiB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0ICh0aGUgZmly c3QgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHdhcw0KPiA+IHN1Ym1pdHRlZCB0byBDb1JFIGluIElF VEY4OCksIHdoaWNoIG5vIG9uZSBoYXMgZGlzYWdyZWVkIGlzIHNldHRpbmcNCj4gPiB0aGUgc3Rh Z2UgZm9yIHRoaXMgd29yay4gTG9vayBhdCBwYXJhbGxlbCB0aHJlYWRzIG9uIHRoaXMgbWFpbGlu ZyBsaXN0DQo+ID4gd2hlcmUgcGVvcGxlIGFzayB3aGV0aGVyIHRoZWlyIHBhcnRpY3VsYXIgc2Vj dXJpdHktZm9yLUlvVCBkcmFmdCBmaXRzDQo+ID4gaW50byBBQ0UuIFRoZSBhbnN3ZXIgSGFubmVz IGlzIGdpdmluZyBpcyBjb3JyZWN0bHk6IHRoZSBzY29wZSBvZiB0aGlzDQo+ID4gd29yayBpcyB3 aGF0IGlzIG91dGxpbmVkIGJ5IHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0LiBJ DQo+ID4gZG9uwrl0IG1pbmQgdXNpbmcgdGhlIFdpa2kgYXMgYSB3b3JraW5nIHRvb2wgYnV0IHRo aXMgZG9lcyBub3QgZ2l2ZQ0KPiA+IHRyYWNlYWJpbGl0eSBhIHllYXIgbGF0ZXIuIEFuZCBJIGRv bsK5dCBzZWUgdGhlIHBvaW50IGlmIGNvcHlpbmcgdGhlDQo+ID4gdXNlIGNhc2UgZG9jdW1lbnQg aW50byBhIFdpa2kgcGFnZSAtIHJlYWQgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIHlvdXINCj4gY29t bWVudHMhDQo+ID4NCj4gPiBXaGVuIGl0IGNvbWVzIHRvIHByb3RvY29sIGRlc2lnbiBjcml0ZXJp YSwgSSBhZ3JlZSB0aGF0IG1vcmUgd29yayBpcw0KPiA+IG5lZWRlZCwgZm9yIHdoaWNoIHRoZSBX aWtpIG1heSBiZSBzdWl0YWJsZS4gTmV2ZXJ0aGVsZXNzIEkgaW5zaXN0IG9uDQo+ID4gZG9jdW1l bnRpbmcgdGhlIGRlc2lnbiBjcml0ZXJpYSBhbmQgaXRzIHJhdGlvbmFsZSBzaW5jZSB0aGF0IHBy b3ZpZGVzDQo+ID4gYSBtZWFucyBmb3IgdHJhY2VhYmlsaXR5LiBNYWtlIGl0IGEgbWlsZXN0b25l IHRvIGhhdmUgYSBkcmFmdCB3aXRoDQo+ID4gYXNzdW1wdGlvbnMgYW5kIGRlc2lnbiBjcml0ZXJp YSAgKHlvdSBtYXkgaW5jbHVkZSDCs2FyY2hpdGVjdHVyZcKyIGluDQo+ID4gdGhpcyBkb2N1bWVu dCkuIFRoaXMgd29yayBpcyBhbnl3YXkgYSBwcmUtcmVxdWlzaXRlIGZvciBjb21pbmcgdG8gYQ0K PiA+IHNvbHV0aW9uLCBhbmQgb25jZSB5b3UgaGF2ZSB0aGlzIGNvbnRlbnQsIHRoZSBjYW5kaWRh dGUgc29sdXRpb25zIGFyZQ0KPiA+IG11Y2ggZWFzaWVyIGV2YWx1YXRlZC4NCj4gPg0KPiA+IFNv LCBjaGFuZ2UgMSkgdG8gc3RhdGUgc29tZXRoaW5nIGxpa2UNCj4gPg0KPiA+ICIxwrkgKQ0KPiA+ IGEpIGNvbXBsZXRlIHRoZSB3b3JrIG9uIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMNCj4gPiBi KSB1c2UgV2lraSBwYWdlcyBmb3IgbGlzdGluZyBhc3N1bXB0aW9ucyBhbmQgcHJvdG9jb2wgZGVz aWduDQo+ID4gY3JpdGVyaWEsIGRvY3VtZW50IHRoZSByZXN1bHQgaW4gYSBkcmFmdCINCj4gPg0K PiA+IFByb3h5IGRlcGxveW1lbnQgYXNwZWN0cyBmaXRzIHdlbGwgaW50byAxYikgIFttb3JlIGlu IHNlcGFyYXRlDQo+ID4gdXBjb21pbmcgbWFpbF0NCj4gPg0KPiA+DQo+ID4gMikgU2VsZWN0aW9u IG9mIGFuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sIGZvcg0KPiA+ IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCj4gPg0KPiA+IEhlcmUgScK5bSBtaXNzaW5nIGFt b25nIG90aGVyIHRoaW5ncyB0aGUgc3BlY2lmaWMgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+ID4gVGhl IHByZWxpbWluYXJ5IGNvbmNsdXNpb25zIGZyb20gdGhlIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVu dHMgZHJhZnQNCj4gPiBmb3JtZWQgdGhlIGJhc2lzIGZvciB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQg YXMgcHJlc2VudGVkIGluIHRoZSBCT0Y6IFdlDQo+ID4gbGFjayBhIG1lY2hhbmlzbSBmb3IgZHlu YW1pYyBhbmQgZmluZSBncmFpbmVkIGFjY2VzcyBjb250cm9sIGZvcg0KPiA+IGNvbnN0cmFpbmVk IGVudmlyb25tZW50cy4NCj4gPg0KPiA+IFRoZSBwcm9jZXNzIGhlcmUgc2hvdWxkIGJlIHRvOg0K PiA+ICIywrkpIGlkZW50aWZ5IHN1aXRhYmxlIHByb3RvY29sIG1lY2hhbmlzbXMgYW5kIG1hdGNo IGNhbmRpZGF0ZQ0KPiA+IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29s cyBhZ2FpbnN0IHJlcXVpcmVtZW50cyBhbmQNCj4gPiBkZXNpZ24gY3JpdGVyaWEsIGluIHBhcnRp Y3VsYXIgYWRkcmVzc2luZyBkeW5hbWljIGFuZCBmaW5lIGdyYWluZWQNCj4gPiBhY2Nlc3MgY29u dHJvbCBzdWl0YWJsZSBmb3IgQ29BUCByZXNvdXJjZSBhY2Nlc3MgcmVxdWVzdHMgaW4gY29uc3Ry YWluZWQNCj4gZW52aXJvbm1lbnRzLiINCj4gPg0KPiA+DQo+ID4NCj4gPiAzKSBFdmFsdWF0aW9u IG9mIHRoZSBjYW5kaWRhdGUgc29sdXRpb24gZm9yIHVzZSB3aXRoIEhUVFAvVExTIGFuZA0KPiA+ IHByb3h5IGRlcGxveW1lbnRzLsKyDQo+ID4NCj4gPg0KPiA+IEFzIG1lbnRpb25lZCBhYm92ZSwg cHJveHkgZGVwbG95bWVudHMgY291bGQgYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mDQo+IDHCuWIp Lg0KPiA+IEluIDLCuSkgaXQgaXMgYWxyZWFkeSBzdGF0ZWQgdGhhdCBpbiBwYXJ0aWN1bGFyIHdl IHNob3VsZCBjb25zaWRlciBDb0FQDQo+ID4gb24gaW50ZXJmYWNlIChJSSkuIEFzIGZvciB1c2Ug b2Ygb3RoZXIgcHJvdG9jb2xzIGJlc2lkZXMgQ29BUCB0aGF0DQo+ID4gaXNzdWUgaXMgb3J0aG9n b25hbCB0byB0aGlzIHNvIEkgbGVhdmUgdGhhdCBvdXQgZnJvbSB0aGlzIGRpc2N1c3Npb24uDQo+ ID4NCj4gPg0KPiA+DQo+ID4gR8O2cmFuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IE9u IDExLzAzLzE0IDE2OjQ5LCAiWmFjaCBTaGVsYnkiIDxaYWNoLlNoZWxieUBhcm0uY29tPiB3cm90 ZToNCj4gPg0KPiA+PiBIYW5uZXMsDQo+ID4+DQo+ID4+IEkgYW0gaGFwcHkgd2l0aCB0aGlzIGNo YXJ0ZXIgd2l0aCBvbmUgZXhjZXB0aW9uLiBUaGUgcHJveHkgaXRlbSBoZXJlDQo+ID4+IHNlZW1z IHRvIGJlIG1vcmUgb2YgYSBkaXN0cmFjdGlvbiB0aGFuIGFueXRoaW5nIGVsc2UsIGFuZCB3aWxs DQo+ID4+IHByb2JhYmx5IHJlc3VsdCBpbiBpbmNyZWFzZWQgY29tcGxleGl0eS4gV2FzIHByb3h5 IHN1cHBvcnQgbWF5YmUganVzdA0KPiA+PiBhIG1pc3VuZGVyc3RhbmRpbmc/IERvIHdlIHJlYWxs eSBzZWUgdGhlIG5lZWQgZm9yIGEgcHJveHkgaW4gdGhlDQo+ID4+IG1pZGRsZSBvZiBJIG9yIElJ ST8NCj4gPj4NCj4gPj4gSSB0aGluayB3aGF0IHdlIHJlYWxseSB3YW50IGhlcmUgaXMgdG8gbWFr ZSBzdXJlIHRoYXQgZS5nLiBldmVuDQo+ID4+IHRocm91Z2ggSSBpcyBiYXNlZCBvbiBIVFRQL1RM UywgSUkgYW5kIElJSSBmb3IgZXhhbXBsZSBjYW4gcnVuDQo+ID4+IENvQVAvRFRMUy4gSW4gb3Ro ZXIgd29yZHMsIHNvbWUgaW50ZXJmYWNlcyBjYW4gYmUgY29uc3RyYWluZWQgd2hpbGUNCj4gPj4g b3RoZXJzIGFyZSBub3QuIEkgdGhpbmsgdGhlIGNoYXJ0ZXIgYWxyZWFkeSBjb3ZlcnMgdGhpcyBm aW5lLg0KPiA+Pg0KPiA+PiBTbyBteSBwcm9wb3NhbCB3b3VsZCBiZSB0byByZW1vdmUgdGhlIG1l bnRpb24gb2YgcHJvdG9jb2wgdHJhbnNsYXRpb24NCj4gPj4gcHJveGllcy4gSWYgd2UgcmVhbGx5 IHNlZSB0aGUgbmVlZCBmb3IgdGhpcyBzb21lIGRheSBpbiB0aGUgZnV0dXJlLA0KPiA+PiBpdCBj b3VsZCBiZSB0YWNrbGVkIHRoZW4uDQo+ID4+DQo+ID4+IFphY2gNCj4gPj4NCj4gPj4gT24gTWFy IDExLCAyMDE0LCBhdCAxMjo1MCBBTSwgSGFubmVzIFRzY2hvZmVuaWcNCj4gPj4gPGhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gSGkgYWxsLA0KPiA+Pj4NCj4g Pj4+IEkgaGF2ZSB0YWtlbiB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBhbmQgdGhlIHJl Y2VudA0KPiA+Pj4gZGlzY3Vzc2lvbnMgb24gdGhlIG1haWxpbmcgbGlzdCBhbmQgcHJvZHVjZWQg YSBuZXcgc3RyYXdtYW4gcHJvcG9zYWwuDQo+ID4+Pg0KPiA+Pj4gVGhlIGNoYW5nZXMgaW5jbHVk ZToNCj4gPj4+ICogQWRkZWQgdGhlIGZvY3VzIG9uIERUTFMvQ29BUCB3aXRoIGFuIGluZGljYXRp b24gdGhhdCB3ZSB3aWxsIGNoZWNrDQo+ID4+PiBhIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3Igc3Vp dGFiaWxpdHkgd2l0aCBIVFRQL1RMUy4NCj4gPj4+ICogQWRkZWQgdGV4dCB0byBpbmRpY2F0ZSB0 aGF0IHdlIHdpbGwgYWxzbyB2ZXJpZnkgdGhlIHN1aXRhYmlsaXR5IG9mDQo+ID4+PiB0aGUgc29s dXRpb24gZm9yIHVzZSB3aXRoIHByb3RvY29sIHRyYW5zbGF0aW9uIHByb3hpZXMuDQo+ID4+PiAq IFNpbXBsaWZpZWQgdGhlIHRhc2sgbGlzdCBieSByZW1vdmluZyBzb2x1dGlvbiBzcGVjaWZpYyBp dGVtcy4NCj4gPj4+ICogTWVyZ2VkIHNldmVyYWwgaXRlbXMgb24gdGhlIHRhc2sgbGlzdCAodXNl IGNhc2VzLCByZXF1aXJlbWVudHMsDQo+ID4+PiBhbmQgcHJvdG9jb2wgZGVzaWduIGd1aWRlbGlu ZXMpLiBGb2xsb3dlZCB0aGUgc3VnZ2VzdGlvbiB0byB1c2Ugb2YgYQ0KPiA+Pj4gV2lraSBmb3Ig Y2FwdHVyaW5nIHRob3NlLg0KPiA+Pj4NCj4gPj4+IFdoYXQgZG8geW91IHRoaW5rPw0KPiA+Pj4N Cj4gPj4+IC0tLS0tDQo+ID4+Pg0KPiA+Pj4gRHJhZnQgQ2hhcnRlciBWMC41IC0gQXV0aGVudGlj YXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yDQo+ID4+PiBDb25zdHJhaW5lZCBFbnZpcm9ubWVu dCAoQUNFKQ0KPiA+Pj4NCj4gPj4+IFRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJv dG9jb2xzIGZvciB1c2UgaW4gZW52aXJvbm1lbnRzDQo+ID4+PiB3aGVyZSBuZXR3b3JrIG5vZGVz IGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5LCBhbmQgcG93ZXIuIEl0IHdhcw0KPiA+Pj4gb2Jz ZXJ2ZWQgdGhhdCBJbnRlcm5ldCBwcm90b2NvbHMgY2FuIGJlIGFwcGxpZWQgdG8gdGhlc2UgY29u c3RyYWluZWQNCj4gPj4+IGVudmlyb25tZW50cywgb2Z0ZW4gb25seSByZXF1aXJpbmcgbWlub3Ig dHdlYWtpbmcgYW5kIHByb2ZpbGluZy4gSW4NCj4gPj4+IG90aGVyIGNhc2VzLCBuZXcgcHJvdG9j b2xzIGhhdmUgYmVlbiBkZWZpbmVkIHRvIGFkZHJlc3MgdGhlIHNwZWNpZmljDQo+ID4+PiByZXF1 aXJlbWVudHMgb2YgY29uc3RyYWluZWQgZGV2aWNlcyBhbmQgbmV0d29ya3MuIEFuIGV4YW1wbGUg b2Ygc3VjaA0KPiA+Pj4gYSBwcm90b2NvbCBpcyB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24g UHJvdG9jb2wgKENvQVApLg0KPiA+Pj4gY29tcG9uZW50cw0KPiA+Pj4gQXMgaW4gb3RoZXIgZW52 aXJvbm1lbnRzLCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBxdWVzdGlvbg0KPiA+ Pj4gYWxzbyBhcmlzZSBpbiBlbnZpcm9ubWVudHMgd2l0aCBjb25zdHJhaW5lZCBub2RlcyBhbmQg bmV0d29ya3MuIEZvcg0KPiA+Pj4gZXhhbXBsZSwgYSBkb29yIGxvY2sgaGFzIHRvIGF1dGhvcml6 ZSB0aGUgcGVyc29uIHNlZWtpbmcgYWNjZXNzDQo+ID4+PiB1c2luZyBhICJkaWdpdGFsIGtleSIu IFdoZXJlIGFyZSB0aGUgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMgc3RvcmVkPw0KPiA+Pj4gSG93 IGRvZXMgdGhlIGRpZ2l0YWwga2V5IGNvbW11bmljYXRlIHdpdGggdGhlIGxvY2s/IERvZXMgdGhl IGxvY2sNCj4gPj4+IGludGVyYWN0IHdpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0 YWluIGF1dGhvcml6YXRpb24NCj4gPj4+IGluZm9ybWF0aW9uPyBIb3cgY2FuIGFjY2VzcyBiZSBn cmFudGVkIHRvIG90aGVyIHBlcnNvbnMgdGVtcG9yYXJpbHk/DQo+IEhvdyBjYW4gYWNjZXNzIGJl IHJldm9rZWQ/DQo+ID4+PiBUaGVzZSB0eXBlcyBvZiBxdWVzdGlvbnMgaGF2ZSBiZWVuIGFuc3dl cmVkIGJ5IGV4aXN0aW5nIHByb3RvY29scw0KPiA+Pj4gZm9yIHVzZSBjYXNlcyBvdXRzaWRlIHRo ZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudC4gQnV0IGluDQo+ID4+PiBjb25zdHJhaW5lZCBlbnZp cm9ubWVudCwgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvcg0KPiA+ Pj4gdGhlIHVzZSBvZiB2YXJpb3VzIHNlY3VyaXR5IHByb3RvY29scy4NCj4gPj4+DQo+ID4+PiBU aGUgSUVURiBoYXMgYSBsb25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZSBwYXJ0eSBhdXRo ZW50aWNhdGlvbg0KPiA+Pj4gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGZvciBkaXN0cmli dXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzDQo+ID4+PiBpbmNsdWRlIEtlcmJlcm9zLCB0aGUg UHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKSwgdGhlDQo+ID4+PiBBdXRoZW50aWNhdGlv biwgQXV0aG9yaXphdGlvbiwgYW5kIEFjY291bnRpbmcgKEFBQSkgaW5mcmFzdHJ1Y3R1cmUsDQo+ ID4+PiBhbmQgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuIEFsbCB0aGVz ZSBwcm90b2NvbHMNCj4gPj4+IGVuam95IHdpZGVzcHJlYWQgZGVwbG95bWVudCBvbiB0aGUgSW50 ZXJuZXQuIEFsdGhvdWdoIHRoZXkgYWxsIGFpbQ0KPiA+Pj4gdG8gc29sdmUgYSBzaW1pbGFyIGdv YWwsIGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRlDQo+ID4+PiBkaWZmZXJl bnQgZnVuY3Rpb25zIGFuZCB1dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4gVGhl c2UNCj4gPj4+IGRpZmZlcmVuY2VzIGFyZSBtb3RpdmF0ZWQgYnkgdGhlIG1haW4gZGVwbG95bWVu dCB1c2UgY2FzZXMgdGhleSB3ZXJlDQo+IGRlc2lnbmVkIGZvci4NCj4gPj4+DQo+ID4+PiBSZXF1 aXJlbWVudHMgZGVyaXZlZCBmcm9tIHVzZSBjYXNlcyBpbmRpY2F0ZSB0aGUgc3VpdGFiaWxpdHkg b2YNCj4gPj4+IGFscmVhZHkgZXhpc3Rpbmcgd29yaywgc3VjaCBhcyBPQXV0aCwgYXMgYSBzb2x1 dGlvbiBmb3IgY29uc3RyYWluZWQNCj4gPj4+IGVudmlyb25tZW50cy4gVGhlc2UgcHJvdG9jb2xz IHdlcmUsIGhvd2V2ZXIsIG5vdCBvcHRpbWl6ZWQgZm9yDQo+ID4+PiBjb25zdHJhaW5lZCBlbnZp cm9ubWVudHMuIEFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHRoYXQgbmVlZCB0byBiZQ0KPiA+Pj4g dGFrZW4gaW50byBhY2NvdW50IGFyZSB0aGUgbGFjayBvZiBhIHN1aXRhYmxlIHVzZXItaW50ZXJm YWNlIGZvcg0KPiA+Pj4gb2J0YWluaW5nIHRoZSBjb25zZW50IG9mIHRoZSB1c2VyIGFuZCB0aGUg aW5hYmlsaXR5IG9mIGVtYmVkZGVkDQo+ID4+PiBkZXZpY2VzIHRvIGNvbnRhY3QgYW4gYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaW4gcmVhbC10aW1lIHdpdGggZXZlcnkNCj4gPj4+IGFjY2VzcyByZXF1 ZXN0IGR1ZSB0byBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LCBldGMuDQo+ID4+Pg0KPiA+Pj4g VGhpcyB3b3JraW5nIGdyb3VwIHRoZXJlZm9yZSBhaW1zIGZvciBhIHN0YW5kYXJkaXplZCBzb2x1 dGlvbiBmb3INCj4gPj4+IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHRvIGVuYWJs ZSBhdXRob3JpemVkIGFjY2VzcyB0bw0KPiA+Pj4gcmVzb3VyY2VzIGluIGNvbnN0cmFpbmVkIGVu dmlyb25tZW50cy4gQXMgYSBzdGFydGluZyBwb2ludCwgdGhlDQo+ID4+PiB3b3JraW5nIGdyb3Vw IHdpbGwgYXNzdW1lIHRoYXQgYWNjZXNzIHRvIHJlc291cmNlcyBvZmZlcmVkIGJ5IGENCj4gPj4+ IHJlc291cmNlIHNlcnZlciBieSBhIGNsaWVudCBkZXZpY2VzIHRha2VzIHBsYWNlIHVzaW5nIENv QVAgYW5kIGlzIHByb3RlY3RlZA0KPiBieSBEVExTLg0KPiA+Pj4gQm90aCByZXNvdXJjZSBzZXJ2 ZXIgYW5kIGNsaWVudCBtYXkgYmUgcmVzb3VyY2UgY29uc3RyYWludC4gVGhpcw0KPiA+Pj4gYWNj ZXNzIHdpbGwgYmUgbWVkaWF0ZWQgYnkgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdoaWNoIGRv ZXMgbm90DQo+ID4+PiBzdWZmZXIgZnJvbSB0aGUgc2FtZSByZXNvdXJjZSBsaW1pdGF0aW9ucy4N Cj4gPj4+DQo+ID4+PiBFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBw cm90b2NvbHMgYXJlIHVzZWQgYW5kDQo+ID4+PiByZS1hcHBsaWVkIGZvciB1c2Ugd2l0aCBjb25z dHJhaW5lZCBkZXZpY2VzLCB3aGVyZSBhcHBsaWNhYmxlLiBUaGlzDQo+ID4+PiByZXF1aXJlcyBy ZWxldmFudCBzcGVjaWZpY2F0aW9ucyB0byBiZSByZXZpZXdlZCBmb3Igc3VpdGFiaWxpdHksDQo+ ID4+PiBzZWxlY3RpbmcgYSBzdWJzZXQgb2YgdGhlbSwgcmVzdHJpY3RpbmcgdGhlIG9wdGlvbnMg d2l0aGluIGVhY2ggb2YNCj4gPj4+IHRoZSBzcGVjaWZpY2F0aW9ucy4gU29tZSBmdW5jdGlvbmFs aXRpZXMgbWF5LCBob3dldmVyLCBub3QgYmUNCj4gPj4+IGF2YWlsYWJsZSBpbiBleGlzdGluZyBw cm90b2NvbHMgYW5kIGZvciB0aG9zZSBjYXNlcyBuZXcNCj4gPj4+IGZ1bmN0aW9uYWxpdHkgaGFz IHRvIGJlIHN0YW5kYXJkaXplZC4gVGh1cywgZXhpc3Rpbmcgd29yayBjYW4gYmUNCj4gPj4+IGxl dmVyYWdlZCBhbmQgdGhlIGdyb3VwIGJlbmVmaXRzIGZyb20gYXZhaWxhYmxlIHNlY3VyaXR5IGFu YWx5c2lzLA0KPiA+Pj4gaW1wbGVtZW50YXRpb24sIGFuZCBkZXBsb3ltZW50IGV4cGVyaWVuY2Uu IE1vcmVvdmVyLCBhIHN0YW5kYXJkaXplZA0KPiA+Pj4gc29sdXRpb24gZm9yIGZlZGVyYXRlZCBh dXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB3aWxsIGhlbHAgdG8NCj4gPj4+IHN0aW11 bGF0ZSB0aGUgZGVwbG95bWVudCBvZiBJb1QgZGV2aWNlcyBvZmZlcmluZyBpbmNyZWFzZWQgc2Vj dXJpdHkuDQo+ID4+Pg0KPiA+Pj4gT25jZSBwcm9ncmVzcyBpbiBpZGVudGlmeWluZyBzdWl0YWJs ZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuDQo+ID4+PiBtYWRlIHRoZSB3b3JraW5nIGdy b3VwIHdpbGwgdmVyaWZ5IHdoZXRoZXIgdGhlIHNhbWUgbWVjaGFuaXNtIGFyZQ0KPiA+Pj4gYWxz byBhcHBsaWNhYmxlIGJleW9uZCB0aGUgdXNlIG9mIENvQVAgYW5kIERUTFMuIEluIHBhcnRpY3Vs YXIsIHRoZQ0KPiA+Pj4gYWJpbGl0eSB0byB1c2UgdGhlIGRldmVsb3BlZCBzb2x1dGlvbiBvdmVy IEhUVFAgYW5kIFRMUyB3aWxsIGJlDQo+IGludmVzdGlnYXRlZC4NCj4gPj4+IEZ1cnRoZXJtb3Jl LCB0byBndWFyYW50ZWUgc21vb3RoIHRyYW5zaXRpb24gdGhlIGludGVncmF0aW9uIHdpdGgNCj4g Pj4+IGV4aXN0aW5nIGRlcGxveW1lbnQgd2lsbCBiZSBzdHVkaWVkLiBUaGlzIHBhcnRpY3VsYXJs eSBjb25jZXJucyB0aGUNCj4gPj4+IHVzZSBvZiBwcm90b2NvbCB0cmFuc2xhdGlvbiBwcm94aWVz Lg0KPiA+Pj4NCj4gPj4+IFRvIGJlIHN1Y2Nlc3NmdWwgdGhpcyB3b3JraW5nIGdyb3VwIHJlcXVp cmVzIGV4cGVydGlzZSBpbiBzZWN1cml0eSwNCj4gPj4+IHByaXZhY3ksIGFuZCBhIGdvb2QgdW5k ZXJzdGFuZGluZyBvZiB1c2FiaWxpdHkgaW4gdGhlIGNvbnN0cmFpbmVkDQo+ID4+PiBlbnZpcm9u bWVudCBzcGFjZS4gVGhpcyB3b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0 aGUNCj4gPj4+IHBhcnR5IG9mZmVyaW5nIGFwcGxpY2F0aW9uIGxheWVyIHNlcnZpY2VzIGlzIGFs d2F5cyB0aGUgc2FtZSBwYXJ0eQ0KPiA+Pj4gb2ZmZXJpbmcgbmV0d29yayBhY2Nlc3Mgc2Vydmlj ZXMuDQo+ID4+Pg0KPiA+Pj4gVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRoZSBmb2xsb3dpbmcgdGFz a3MgKGluIHRoaXMgb3JkZXIpOg0KPiA+Pj4NCj4gPj4+IDEpIFRoZSB3b3JraW5nIGdyb3VwIFdp a2kgcGFnZXMgd2lsbCBiZSB1c2VkIHRvIGRvY3VtZW50IHVzZSBjYXNlcywNCj4gPj4+IHJlcXVp cmVtZW50cywgYW5kIHByb3RvY29sIGRlc2lnbiBjcml0ZXJpYS4gVGhpcyB3b3JrIHdpbGwgZ3Vp ZGUgdGhlDQo+ID4+PiBpZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNoYW5p c21zLg0KPiA+Pj4NCj4gPj4+IDIpIFNlbGVjdGlvbiBvZiBhbiBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiBwcm90b2NvbCBmb3INCj4gPj4+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50 cy4NCj4gPj4+DQo+ID4+PiAzKSBFdmFsdWF0aW9uIG9mIHRoZSBjYW5kaWRhdGUgc29sdXRpb24g Zm9yIHVzZSB3aXRoIEhUVFAvVExTIGFuZA0KPiA+Pj4gcHJveHkgZGVwbG95bWVudHMuDQo+ID4+ Pg0KPiA+Pj4gLS0tLS0NCj4gPj4+DQo+ID4+PiBDaWFvDQo+ID4+PiBIYW5uZXMNCj4gPj4+DQo+ ID4+PiA8c2lnbmF0dXJlLmFzYz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+Pj4gQWNlIG1haWxpbmcgbGlzdA0KPiA+Pj4gQWNlQGlldGYub3JnDQo+ ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiA+Pg0KPiA+ PiBaYWNoIFNoZWxieQ0KPiA+PiBEaXJlY3RvciBvZiBUZWNobm9sb2d5DQo+ID4+IEFSTSBJbnRl cm5ldCBvZiBUaGluZ3MgQlUNCj4gPj4gd3d3LmFybS5jb20NCj4gPj4gbW9iaWxlOiArMSAoNDA4 KSAyMDMtOTQzNA0KPiA+PiBTa3lwZTogemRzaGVsYnkNCj4gPj4gTGlua2VkSW46IGZpLmxpbmtl ZGluLmNvbS9pbi96YWNoc2hlbGJ5Lw0KPiA+Pg0KPiA+Pg0KPiA+PiAtLSBJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzDQo+ID4+ IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZQ0KPiA+PiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90DQo+ID4+IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvcg0KPiA+PiBzdG9yZSBv ciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiAgVGhhbmsgeW91Lg0KPiA+Pg0K PiA+PiBBUk0gTGltaXRlZCwgUmVnaXN0ZXJlZCBvZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENh bWJyaWRnZSBDQjEgOU5KLA0KPiA+PiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcywgQ29t cGFueSBObzogIDI1NTc1OTAgQVJNIEhvbGRpbmdzIHBsYywNCj4gPj4gUmVnaXN0ZXJlZCBvZmZp Y2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRnZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGluDQo+ ID4+IEVuZ2xhbmQgJiBXYWxlcywgQ29tcGFueSBObzogIDI1NDg3ODINCj4gPj4NCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gQWNlIG1h aWxpbmcgbGlzdA0KPiA+PiBBY2VAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hY2UNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gQWNlIG1haWxpbmcgbGlzdA0KPiA+IEFjZUBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+ID4N Cg0K From nobody Thu Mar 13 03:57:23 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AF81A09D9 for ; Thu, 13 Mar 2014 03:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4aP0P7vGL-q for ; Thu, 13 Mar 2014 03:57:16 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 027DF1A09B3 for ; Thu, 13 Mar 2014 03:57:15 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so2493563qgf.0 for ; Thu, 13 Mar 2014 03:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:cc:reply-to:mime-version :content-type; bh=9i/JnfvPDiuepbrkofbh/LSoumYcRbf7iSdazcZEHCE=; b=tQi0+3fU3pnKsNyLZpWfBgYoaqDOcAgp0ONeb0mE4iTIg7jhhyt2/+GLuuode5iCiI Xs8mvXz5vL93rlzUUNrz9pBmzJaCNUfv954ug/+uSGpuYsbx4DFkvClXBsh1gW8bul4Z 1uaLS8cEA94CuiAFlebPuYXji1MVCUuG/KZF+l8hNQ5N3i5YDWLDrnG4AuHlcfG2UJGu yPzdhV56YROFIiRbvdKnTjeUe0mF1cIR33+nZ1NISCgo6lZ0+lfOquNyViQE/3DZ4muB v8bPzP40/OkbizczcB4V4DblAe/D38G7obwIkn099/8QTnBABo5R6cY+WAFU/HM+vKml 87rA== X-Received: by 10.224.135.132 with SMTP id n4mr1242591qat.97.1394708229350; Thu, 13 Mar 2014 03:57:09 -0700 (PDT) Received: from [192.168.1.9] (pool-108-7-235-60.bstnma.fios.verizon.net. [108.7.235.60]) by mx.google.com with ESMTPSA id n8sm5531035qaz.18.2014.03.13.03.57.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 03:57:08 -0700 (PDT) Date: Thu, 13 Mar 2014 06:55:19 -0400 Message-ID: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> Importance: normal From: Margaret Wasserman To: Likepeng , Hannes Tschofenig , =?ISO-8859-1?Q?G=F6ran_Selander?= , Zach Shelby MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_2589254224154210" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Bo2IrfAnBi8-NaDK93JEYc0LgGw Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Margaret Wasserman List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 10:57:21 -0000 ----_com.android.email_2589254224154210 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UGVyc29uYWxseSwgSSB3b3VsZCBhbHNvIHJhdGhlciBzZWUgdGhlIHVzZSBjYXNlcyBhbmQgcmVx dWlyZW1lbnRzIHB1Ymxpc2hlZCBhcyBpbmZvcm1hdGlvbmFsUkZDcy4gwqBJIHRoaW5rIHRoYXQg YSB3aWtpIG1pZ2h0IGJlIGEgZ29vZCB3YXkgdG8gY29sbGVjdCB0aGVtIGF0IGZpcnN0LCBidXQg SSB3b3VsZCBwcmVmZXIgdG8gYmUgc3VyZSB0aGF0IHdlIGhhdmUgY29uc2Vuc3VzIG9uIHRoZSBw cm9ibGVtKHMpIHdlIGFyZSB0cnlpbmcgdG8gc29sdmUuIMKgSSBhbHNvIHRoaW5rIGl0IHdpbGwg YmUgdXNlZnVsIHRvIGhhdmUgdGhlc2UgdGhpbmdzIGluIGFyY2hpdmFsIGZvcm0gbGF0ZXIuCgpJ IGRvIG5vdCB0aGluayB0aGUgb3RoZXIgd29yayBvZiB0aGUgZ3JvdXAgc2hvdWxkIGJlIGdhdGVk IG9uIHRoZSByZXF1aXJlbWVudHMsIHRob3VnaCwgYXMgSSB0aGluayB0aGF0IGl0IG1ha2VzIHNl bnNlIHRvIGV4cGxvcmUgaG93IGV4aXN0aW5nIHRlY2hub2xvZ2llcyBjb3VsZCBvciBjb3VsZG4n dCBtZWV0IHRoZSByZXF1aXJlbWVudHMgdG8gaW5zdXJlIHRoYXQgb3VyIHJlcXVpcmVtZW50cyBh cmUgcmVhbGl0eS1iYXNlZC4KCk1hcmdhcmV0CgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0t LS0tLS0tCkZyb20gTGlrZXBlbmcgPGxpa2VwZW5nQGh1YXdlaS5jb20+IApEYXRlOiAwMy8xMy8y MDE0ICA0OjI4IEFNICAoR01ULTA1OjAwKSAKVG8gSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ+LEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nz b24uY29tPixaYWNoIFNoZWxieSA8WmFjaC5TaGVsYnlAYXJtLmNvbT4gCkNjIGFjZUBpZXRmLm9y ZyAKU3ViamVjdCBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9zYWwgdjAuNSAKIApNeSBwZXJz b25hbCBvcGluaW9uIGlzIHRoYXQgdGhlIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZG9jdW1l bnQgY2FuIGhlbHAgcGVvcGxlIHRvIHVuZGVyc3RhbmQgd2hhdCBraW5kIG9mIGlzc3VlcyB3ZSBh cmUgdHJ5aW5nIHRvIHJlc29sdmUuCgpJIGNhbiBzZWUgc29tZSB2YWx1ZXMgdG8gcHVibGlzaCBp dCBpbnRvIFJGQ3MuIElmIGl0IGlzIGEgd2lraSBwYWdlLCB3ZSB3aWxsIGhhdmUgbGVzcyBwZW9w bGUgdG8gcmV2aWV3IGl0IG9yIGltcHJvdmUgaXQuIAoKRXNwZWNpYWxseSB0aGUgdXNlIGNhc2Ug YW5kIHJlcXVpcmVtZW50IGRvY3VtZW50IGlzIGFscmVhZHkgaW4gYSBnb29kIHNoYXBlIGFuZCBp dCBpcyByZWZlcmVuY2VkIHNldmVyYWwgdGltZXMgaW4gdGhlIG1haWxpbmcgbGlzdCB0byBpbnRy b2R1Y2Ugb3VyIHdvcmsgdG8gb3V0c2lkZS4KClRoYW5rcywKCktpbmQgUmVnYXJkcwpLZXBlbmcK Cj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQo+IOWPkeS7tuS6ujogQWNlIFttYWlsdG86YWNlLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBIYW5uZXMgVHNjaG9mZW5pZwo+IOWPkemAgeaXtumXtDog MjAxNOW5tDPmnIgxM+aXpSA0OjMzCj4g5pS25Lu25Lq6OiBHw7ZyYW4gU2VsYW5kZXI7IFphY2gg U2hlbGJ5Cj4g5oqE6YCBOiBhY2VAaWV0Zi5vcmcKPiDkuLvpopg6IFJlOiBbQWNlXSBBQ0UgQ2hh cnRlciBQcm9wb3NhbCB2MC41Cj4gCj4gSGkgR29lcmFuLAo+IAo+IEkgcmVhZCBhIGxpdHRsZSBi aXQgYmV0d2VlbiB0aGUgbGluZXMgb2YgeW91ciBtYWlsIGFuZCB5b3VyIG1haW4gY29uY2VybiBp cyB0aGF0Cj4geW91IHdhbnQgdG8gaGF2ZSBhbiBSRkMgcHVibGlzaGVkIHdpdGggeW91ciBuYW1l IG9uIGl0Lgo+IEEgd2lraSBwYWdlIHRvIGRvY3VtZW50IHRoZSByZXF1aXJlbWVudHMsIGFuZCB1 c2UgY2FzZXMgaXMgbm90IGdvb2QgZW5vdWdoCj4gZm9yIHlvdS4KPiAKPiBGb3IgeW91IHB1dHRp bmcgdGhlIGRyYWZ0IHRleHQgb24gYSBXRyB3aWtpIGZlZWxzIGxpa2Ugd2FzdGVkIHRpbWUuCj4g SXQgaXMganVzdCBhIGRpZmZlcmVudCBmb3JtIG9mIGRvY3VtZW50aW5nIHRoZSB3b3JrLgo+IAo+ IE15IGV4cGVyaWVuY2Ugd2l0aCB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBoYXMgbm90IGJl ZW4gZ3JlYXQgaW4gdGhlIElFVEYuCj4gSW4gZXNzZW5jZSBldmVyeW9uZSBxdWlja2x5IG1vdmVz IG9uIG9uY2UgdGhlIGdyb3VwIGRlY2lkZXMgYWJvdXQgYQo+IHBhcnRpY3VsYXIgc29sdXRpb24g ZGlyZWN0aW9uLiBJdCB0aGVuIGJlY29tZXMgdmVyeSBoYXJkIChmb3IgdGhlCj4gY2hhaXJzKSB0 byBmaW5pc2ggdGhlIHJlcXVpcmVtZW50cyB3b3JrIHNpbmNlIG5vYm9keSB3YW50cyB0byByZXZp ZXcgb3IgbG9vawo+IGF0IHRoZW0gYW55bW9yZS4KPiAKPiBVc2UgY2FzZXMgYW5kIHJlcXVpcmVt ZW50cyBhcmUgZ3JlYXQgZHVyaW5nIHRoZSBpbml0aWFsIHBhcnQgb2YgdGhlIHdvcmsgdG8gZ2V0 Cj4gYW4gdW5kZXJzdGFuZGluZyBvZiB0aGUgbWFpbiBjaGFsbGVuZ2VzLgo+IAo+IEhhdmluZyBz YWlkIHRoYXQgSSB3aWxsIGxlYXZlIGl0IHRvIHRoZSBncm91cCB0byBkZWNpZGUgd2hhdCB0aGV5 IHdhbnQgdG8gZG86Cj4gUkZDcyBvciBXaWtpIHBhZ2UKPiAKPiBDaWFvCj4gSGFubmVzCj4gCj4g UFM6IFJlZ2FyZGluZyB5b3VyIG90aGVyIGNvbW1lbnQgYWJvdXQgcG9pbnRpbmcgdG8gdGhlIGNv bnN0cmFpbnQgbmF0dXJlIHRvCj4gZXZlcnkgaXRlbS4gV2UgY2FuIGRvIHRoYXQgaWYgeW91IGZl ZWwgYmV0dGVyIGJ1dCB0aGUgZW50aXJlIGNoYXJ0ZXIgcGFnZQo+IGFscmVhZHkgc2F5cyAxMCB0 aW1lcyB0aGF0IHdlIGFyZSBmb2N1c2luZyBvbiB0aGUgY29uc3RyYWludCBzcGFjZS4KPiBJIGFt IHN1cmUgdGhhdCB0aGUgcmVhZGVyIHdpbGwgaGF2ZSB1bmRlcnN0b29kIHRoYXQgd2hlbiB0aGV5 IGdldCB0byB0aGUgdGFzawo+IGxpc3QuCj4gCj4gCj4gT24gMDMvMTIvMjAxNCAxMDozMiBBTSwg R8O2cmFuIFNlbGFuZGVyIHdyb3RlOgo+ID4gSGFubmVzLCBaYWNoIGFuZCBhbGwsCj4gPgo+ID4g SSBtdXN0IHNheSBJIGRvbsK5dCBmaW5kIHRoZSB0YXNrIGxpc3Qgb2YgdGhlIGN1cnJlbnQgY2hh cnRlciB2ZXJ5IGhlbHBmdWw6Cj4gPgo+ID4gwrNUaGUgd29ya2luZyBncm91cCBoYXMgdGhlIGZv bGxvd2luZyB0YXNrcyAoaW4gdGhpcyBvcmRlcik6Cj4gPgo+ID4gMSkgVGhlIHdvcmtpbmcgZ3Jv dXAgV2lraSBwYWdlcyB3aWxsIGJlIHVzZWQgdG8gZG9jdW1lbnQgdXNlIGNhc2VzLAo+ID4gcmVx dWlyZW1lbnRzLCBhbmQgcHJvdG9jb2wgZGVzaWduIGNyaXRlcmlhLiBUaGlzIHdvcmsgd2lsbCBn dWlkZSB0aGUKPiA+IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3RvY29sIG1lY2hhbmlz bXMuCj4gPgo+ID4gMikgU2VsZWN0aW9uIG9mIGFuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp emF0aW9uIHByb3RvY29sIGZvcgo+ID4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLgo+ID4KPiA+ IDMpIEV2YWx1YXRpb24gb2YgdGhlIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggSFRU UC9UTFMgYW5kCj4gPiBwcm94eSBkZXBsb3ltZW50cy7Csgo+ID4KPiA+IFRoaXMgbGlzdCBkb2Vz IG5vdCBnaXZlIG11Y2ggbW9yZSBkZXRhaWxzIGFib3V0IHRoZSB3b3JrIHRvIGJlCj4gPiBjb25k dWN0ZWQgdGhhbiBpcyBhbHJlYWR5IGdpdmVuIGJ5IHRoZSB0aXRsZSBvZiB0aGUgV0cuIFRvIGEg cGVyc29uCj4gPiBub3QgaGF2aW5nIGZvbGxvd2VkIHRoZSBkaXNjdXNzaW9uLCB0aGUgaW1wcmVz c2lvbiBpcyB0aGF0IHRoZSB3b3JrCj4gPiBzdGFydHMgZnJvbSBzY3JhdGNoIGFuZCB0aGVyZSBp cyBubyBjbGVhciB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgdG8gZG8uCj4gPgo+ID4gSWYgd2UgY2Fu wrl0IGZvcm11bGF0ZSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIGZpcnN0IHN0ZXAgdG93YXJk cyBhCj4gPiBzb2x1dGlvbiBpbiBzb21lIGRlZ3JlZSBvZiBkZXRhaWwgYmVmb3JlIHN0YXJ0aW5n IHRoZSBXRyB0aGF0IHdpbGwKPiA+IGFueXdheSBiZSB0aGUgZmlyc3QgdGFzayB0byBkbywgc28g bGV0wrlzIHRyeSB0byBnZXQgc29tZXRoaW5nIGluIHdyaXRpbmcuCj4gPgo+ID4KPiA+ICIxKSBU aGUgd29ya2luZyBncm91cCBXaWtpIHBhZ2VzIHdpbGwgYmUgdXNlZCB0byBkb2N1bWVudCB1c2Ug Y2FzZXMsCj4gPiByZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEuIFRo aXMgd29yayB3aWxsIGd1aWRlIHRoZQo+ID4gaWRlbnRpZmljYXRpb24gb2Ygc3VpdGFibGUgcHJv dG9jb2wgbWVjaGFuaXNtcy4iCj4gPgo+ID4gVGhpcyBpcyBoaWRpbmcgdGhlIGZhY3QgdGhhdCB0 aGVyZSBoYXMgYmVlbiA2IG1vbnRocyBvZiB3b3JrIG9uIHRoZQo+ID4gdXNlIGNhc2UgYW5kIHJl cXVpcmVtZW50cyBkcmFmdCAodGhlIGZpcnN0IHZlcnNpb24gb2YgdGhpcyBkcmFmdCB3YXMKPiA+ IHN1Ym1pdHRlZCB0byBDb1JFIGluIElFVEY4OCksIHdoaWNoIG5vIG9uZSBoYXMgZGlzYWdyZWVk IGlzIHNldHRpbmcKPiA+IHRoZSBzdGFnZSBmb3IgdGhpcyB3b3JrLiBMb29rIGF0IHBhcmFsbGVs IHRocmVhZHMgb24gdGhpcyBtYWlsaW5nIGxpc3QKPiA+IHdoZXJlIHBlb3BsZSBhc2sgd2hldGhl ciB0aGVpciBwYXJ0aWN1bGFyIHNlY3VyaXR5LWZvci1Jb1QgZHJhZnQgZml0cwo+ID4gaW50byBB Q0UuIFRoZSBhbnN3ZXIgSGFubmVzIGlzIGdpdmluZyBpcyBjb3JyZWN0bHk6IHRoZSBzY29wZSBv ZiB0aGlzCj4gPiB3b3JrIGlzIHdoYXQgaXMgb3V0bGluZWQgYnkgdGhlIHVzZSBjYXNlIGFuZCBy ZXF1aXJlbWVudHMgZHJhZnQuIEkKPiA+IGRvbsK5dCBtaW5kIHVzaW5nIHRoZSBXaWtpIGFzIGEg d29ya2luZyB0b29sIGJ1dCB0aGlzIGRvZXMgbm90IGdpdmUKPiA+IHRyYWNlYWJpbGl0eSBhIHll YXIgbGF0ZXIuIEFuZCBJIGRvbsK5dCBzZWUgdGhlIHBvaW50IGlmIGNvcHlpbmcgdGhlCj4gPiB1 c2UgY2FzZSBkb2N1bWVudCBpbnRvIGEgV2lraSBwYWdlIC0gcmVhZCB0aGUgZHJhZnQgYW5kIHBy b3ZpZGUgeW91cgo+IGNvbW1lbnRzIQo+ID4KPiA+IFdoZW4gaXQgY29tZXMgdG8gcHJvdG9jb2wg ZGVzaWduIGNyaXRlcmlhLCBJIGFncmVlIHRoYXQgbW9yZSB3b3JrIGlzCj4gPiBuZWVkZWQsIGZv ciB3aGljaCB0aGUgV2lraSBtYXkgYmUgc3VpdGFibGUuIE5ldmVydGhlbGVzcyBJIGluc2lzdCBv bgo+ID4gZG9jdW1lbnRpbmcgdGhlIGRlc2lnbiBjcml0ZXJpYSBhbmQgaXRzIHJhdGlvbmFsZSBz aW5jZSB0aGF0IHByb3ZpZGVzCj4gPiBhIG1lYW5zIGZvciB0cmFjZWFiaWxpdHkuIE1ha2UgaXQg YSBtaWxlc3RvbmUgdG8gaGF2ZSBhIGRyYWZ0IHdpdGgKPiA+IGFzc3VtcHRpb25zIGFuZCBkZXNp Z24gY3JpdGVyaWHCoCAoeW91IG1heSBpbmNsdWRlIMKzYXJjaGl0ZWN0dXJlwrIgaW4KPiA+IHRo aXMgZG9jdW1lbnQpLiBUaGlzIHdvcmsgaXMgYW55d2F5IGEgcHJlLXJlcXVpc2l0ZSBmb3IgY29t aW5nIHRvIGEKPiA+IHNvbHV0aW9uLCBhbmQgb25jZSB5b3UgaGF2ZSB0aGlzIGNvbnRlbnQsIHRo ZSBjYW5kaWRhdGUgc29sdXRpb25zIGFyZQo+ID4gbXVjaCBlYXNpZXIgZXZhbHVhdGVkLgo+ID4K PiA+IFNvLCBjaGFuZ2UgMSkgdG8gc3RhdGUgc29tZXRoaW5nIGxpa2UKPiA+Cj4gPiAiMcK5ICkK PiA+IGEpIGNvbXBsZXRlIHRoZSB3b3JrIG9uIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMKPiA+ IGIpIHVzZSBXaWtpIHBhZ2VzIGZvciBsaXN0aW5nIGFzc3VtcHRpb25zIGFuZCBwcm90b2NvbCBk ZXNpZ24KPiA+IGNyaXRlcmlhLCBkb2N1bWVudCB0aGUgcmVzdWx0IGluIGEgZHJhZnQiCj4gPgo+ ID4gUHJveHkgZGVwbG95bWVudCBhc3BlY3RzIGZpdHMgd2VsbCBpbnRvIDFiKcKgIFttb3JlIGlu IHNlcGFyYXRlCj4gPiB1cGNvbWluZyBtYWlsXQo+ID4KPiA+Cj4gPiAyKSBTZWxlY3Rpb24gb2Yg YW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9yCj4gPiBjb25z dHJhaW5lZCBlbnZpcm9ubWVudHMuCj4gPgo+ID4gSGVyZSBJwrltIG1pc3NpbmcgYW1vbmcgb3Ro ZXIgdGhpbmdzIHRoZSBzcGVjaWZpYyBwcm9ibGVtIHN0YXRlbWVudC4KPiA+IFRoZSBwcmVsaW1p bmFyeSBjb25jbHVzaW9ucyBmcm9tIHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0 Cj4gPiBmb3JtZWQgdGhlIGJhc2lzIGZvciB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYXMgcHJlc2Vu dGVkIGluIHRoZSBCT0Y6IFdlCj4gPiBsYWNrIGEgbWVjaGFuaXNtIGZvciBkeW5hbWljIGFuZCBm aW5lIGdyYWluZWQgYWNjZXNzIGNvbnRyb2wgZm9yCj4gPiBjb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMuCj4gPgo+ID4gVGhlIHByb2Nlc3MgaGVyZSBzaG91bGQgYmUgdG86Cj4gPiAiMsK5KSBpZGVu dGlmeSBzdWl0YWJsZSBwcm90b2NvbCBtZWNoYW5pc21zIGFuZCBtYXRjaCBjYW5kaWRhdGUKPiA+ IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyBhZ2FpbnN0IHJlcXVp cmVtZW50cyBhbmQKPiA+IGRlc2lnbiBjcml0ZXJpYSwgaW4gcGFydGljdWxhciBhZGRyZXNzaW5n IGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZAo+ID4gYWNjZXNzIGNvbnRyb2wgc3VpdGFibGUgZm9y IENvQVAgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3RzIGluIGNvbnN0cmFpbmVkCj4gZW52aXJvbm1l bnRzLiIKPiA+Cj4gPgo+ID4KPiA+IDMpIEV2YWx1YXRpb24gb2YgdGhlIGNhbmRpZGF0ZSBzb2x1 dGlvbiBmb3IgdXNlIHdpdGggSFRUUC9UTFMgYW5kCj4gPiBwcm94eSBkZXBsb3ltZW50cy7Csgo+ ID4KPiA+Cj4gPiBBcyBtZW50aW9uZWQgYWJvdmUsIHByb3h5IGRlcGxveW1lbnRzIGNvdWxkIGJl IGNvbnNpZGVyZWQgYXMgcGFydCBvZgo+IDHCuWIpLgo+ID4gSW4gMsK5KSBpdCBpcyBhbHJlYWR5 IHN0YXRlZCB0aGF0IGluIHBhcnRpY3VsYXIgd2Ugc2hvdWxkIGNvbnNpZGVyIENvQVAKPiA+IG9u IGludGVyZmFjZSAoSUkpLiBBcyBmb3IgdXNlIG9mIG90aGVyIHByb3RvY29scyBiZXNpZGVzIENv QVAgdGhhdAo+ID4gaXNzdWUgaXMgb3J0aG9nb25hbCB0byB0aGlzIHNvIEkgbGVhdmUgdGhhdCBv dXQgZnJvbSB0aGlzIGRpc2N1c3Npb24uCj4gPgo+ID4KPiA+Cj4gPiBHw7ZyYW4KPiA+Cj4gPgo+ ID4KPiA+Cj4gPgo+ID4gT24gMTEvMDMvMTQgMTY6NDksICJaYWNoIFNoZWxieSIgPFphY2guU2hl bGJ5QGFybS5jb20+IHdyb3RlOgo+ID4KPiA+PiBIYW5uZXMsCj4gPj4KPiA+PiBJIGFtIGhhcHB5 IHdpdGggdGhpcyBjaGFydGVyIHdpdGggb25lIGV4Y2VwdGlvbi4gVGhlIHByb3h5IGl0ZW0gaGVy ZQo+ID4+IHNlZW1zIHRvIGJlIG1vcmUgb2YgYSBkaXN0cmFjdGlvbiB0aGFuIGFueXRoaW5nIGVs c2UsIGFuZCB3aWxsCj4gPj4gcHJvYmFibHkgcmVzdWx0IGluIGluY3JlYXNlZCBjb21wbGV4aXR5 LiBXYXMgcHJveHkgc3VwcG9ydCBtYXliZSBqdXN0Cj4gPj4gYSBtaXN1bmRlcnN0YW5kaW5nPyBE byB3ZSByZWFsbHkgc2VlIHRoZSBuZWVkIGZvciBhIHByb3h5IGluIHRoZQo+ID4+IG1pZGRsZSBv ZiBJIG9yIElJST8KPiA+Pgo+ID4+IEkgdGhpbmsgd2hhdCB3ZSByZWFsbHkgd2FudCBoZXJlIGlz IHRvIG1ha2Ugc3VyZSB0aGF0IGUuZy4gZXZlbgo+ID4+IHRocm91Z2ggSSBpcyBiYXNlZCBvbiBI VFRQL1RMUywgSUkgYW5kIElJSSBmb3IgZXhhbXBsZSBjYW4gcnVuCj4gPj4gQ29BUC9EVExTLiBJ biBvdGhlciB3b3Jkcywgc29tZSBpbnRlcmZhY2VzIGNhbiBiZSBjb25zdHJhaW5lZCB3aGlsZQo+ ID4+IG90aGVycyBhcmUgbm90LiBJIHRoaW5rIHRoZSBjaGFydGVyIGFscmVhZHkgY292ZXJzIHRo aXMgZmluZS4KPiA+Pgo+ID4+IFNvIG15IHByb3Bvc2FsIHdvdWxkIGJlIHRvIHJlbW92ZSB0aGUg bWVudGlvbiBvZiBwcm90b2NvbCB0cmFuc2xhdGlvbgo+ID4+IHByb3hpZXMuIElmIHdlIHJlYWxs eSBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgc29tZSBkYXkgaW4gdGhlIGZ1dHVyZSwKPiA+PiBpdCBj b3VsZCBiZSB0YWNrbGVkIHRoZW4uCj4gPj4KPiA+PiBaYWNoCj4gPj4KPiA+PiBPbiBNYXIgMTEs IDIwMTQsIGF0IDEyOjUwIEFNLCBIYW5uZXMgVHNjaG9mZW5pZwo+ID4+IDxoYW5uZXMudHNjaG9m ZW5pZ0BnbXgubmV0PiB3cm90ZToKPiA+Pgo+ID4+PiBIaSBhbGwsCj4gPj4+Cj4gPj4+IEkgaGF2 ZSB0YWtlbiB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBhbmQgdGhlIHJlY2VudAo+ID4+ PiBkaXNjdXNzaW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBwcm9kdWNlZCBhIG5ldyBzdHJh d21hbiBwcm9wb3NhbC4KPiA+Pj4KPiA+Pj4gVGhlIGNoYW5nZXMgaW5jbHVkZToKPiA+Pj4gKiBB ZGRlZCB0aGUgZm9jdXMgb24gRFRMUy9Db0FQIHdpdGggYW4gaW5kaWNhdGlvbiB0aGF0IHdlIHdp bGwgY2hlY2sKPiA+Pj4gYSBjYW5kaWRhdGUgc29sdXRpb24gZm9yIHN1aXRhYmlsaXR5IHdpdGgg SFRUUC9UTFMuCj4gPj4+ICogQWRkZWQgdGV4dCB0byBpbmRpY2F0ZSB0aGF0IHdlIHdpbGwgYWxz byB2ZXJpZnkgdGhlIHN1aXRhYmlsaXR5IG9mCj4gPj4+IHRoZSBzb2x1dGlvbiBmb3IgdXNlIHdp dGggcHJvdG9jb2wgdHJhbnNsYXRpb24gcHJveGllcy4KPiA+Pj4gKiBTaW1wbGlmaWVkIHRoZSB0 YXNrIGxpc3QgYnkgcmVtb3Zpbmcgc29sdXRpb24gc3BlY2lmaWMgaXRlbXMuCj4gPj4+ICogTWVy Z2VkIHNldmVyYWwgaXRlbXMgb24gdGhlIHRhc2sgbGlzdCAodXNlIGNhc2VzLCByZXF1aXJlbWVu dHMsCj4gPj4+IGFuZCBwcm90b2NvbCBkZXNpZ24gZ3VpZGVsaW5lcykuIEZvbGxvd2VkIHRoZSBz dWdnZXN0aW9uIHRvIHVzZSBvZiBhCj4gPj4+IFdpa2kgZm9yIGNhcHR1cmluZyB0aG9zZS4KPiA+ Pj4KPiA+Pj4gV2hhdCBkbyB5b3UgdGhpbms/Cj4gPj4+Cj4gPj4+IC0tLS0tCj4gPj4+Cj4gPj4+ IERyYWZ0IENoYXJ0ZXIgVjAuNSAtIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZv cgo+ID4+PiBDb25zdHJhaW5lZCBFbnZpcm9ubWVudCAoQUNFKQo+ID4+Pgo+ID4+PiBUaGUgSUVU RiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGVudmlyb25tZW50 cwo+ID4+PiB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5LCBh bmQgcG93ZXIuIEl0IHdhcwo+ID4+PiBvYnNlcnZlZCB0aGF0IEludGVybmV0IHByb3RvY29scyBj YW4gYmUgYXBwbGllZCB0byB0aGVzZSBjb25zdHJhaW5lZAo+ID4+PiBlbnZpcm9ubWVudHMsIG9m dGVuIG9ubHkgcmVxdWlyaW5nIG1pbm9yIHR3ZWFraW5nIGFuZCBwcm9maWxpbmcuIEluCj4gPj4+ IG90aGVyIGNhc2VzLCBuZXcgcHJvdG9jb2xzIGhhdmUgYmVlbiBkZWZpbmVkIHRvIGFkZHJlc3Mg dGhlIHNwZWNpZmljCj4gPj4+IHJlcXVpcmVtZW50cyBvZiBjb25zdHJhaW5lZCBkZXZpY2VzIGFu ZCBuZXR3b3Jrcy4gQW4gZXhhbXBsZSBvZiBzdWNoCj4gPj4+IGEgcHJvdG9jb2wgaXMgdGhlIENv bnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKS4KPiA+Pj4gY29tcG9uZW50cwo+ ID4+PiBBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp emF0aW9uIHF1ZXN0aW9uCj4gPj4+IGFsc28gYXJpc2UgaW4gZW52aXJvbm1lbnRzIHdpdGggY29u c3RyYWluZWQgbm9kZXMgYW5kIG5ldHdvcmtzLiBGb3IKPiA+Pj4gZXhhbXBsZSwgYSBkb29yIGxv Y2sgaGFzIHRvIGF1dGhvcml6ZSB0aGUgcGVyc29uIHNlZWtpbmcgYWNjZXNzCj4gPj4+IHVzaW5n IGEgImRpZ2l0YWwga2V5Ii4gV2hlcmUgYXJlIHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBz dG9yZWQ/Cj4gPj4+IEhvdyBkb2VzIHRoZSBkaWdpdGFsIGtleSBjb21tdW5pY2F0ZSB3aXRoIHRo ZSBsb2NrPyBEb2VzIHRoZSBsb2NrCj4gPj4+IGludGVyYWN0IHdpdGggYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXIgdG8gb2J0YWluIGF1dGhvcml6YXRpb24KPiA+Pj4gaW5mb3JtYXRpb24/IEhvdyBj YW4gYWNjZXNzIGJlIGdyYW50ZWQgdG8gb3RoZXIgcGVyc29ucyB0ZW1wb3JhcmlseT8KPiBIb3cg Y2FuIGFjY2VzcyBiZSByZXZva2VkPwo+ID4+PiBUaGVzZSB0eXBlcyBvZiBxdWVzdGlvbnMgaGF2 ZSBiZWVuIGFuc3dlcmVkIGJ5IGV4aXN0aW5nIHByb3RvY29scwo+ID4+PiBmb3IgdXNlIGNhc2Vz IG91dHNpZGUgdGhlIGNvbnN0cmFpbmVkIGVudmlyb25tZW50LiBCdXQgaW4KPiA+Pj4gY29uc3Ry YWluZWQgZW52aXJvbm1lbnQsIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHBvc2UgY2hhbGxlbmdl cyBmb3IKPiA+Pj4gdGhlIHVzZSBvZiB2YXJpb3VzIHNlY3VyaXR5IHByb3RvY29scy4KPiA+Pj4K PiA+Pj4gVGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5IGluIGRldmVsb3BpbmcgdGhyZWUgcGFy dHkgYXV0aGVudGljYXRpb24KPiA+Pj4gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGZvciBk aXN0cmlidXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzCj4gPj4+IGluY2x1ZGUgS2VyYmVyb3Ms IHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGUKPiA+Pj4gQXV0aGVudGlj YXRpb24sIEF1dGhvcml6YXRpb24sIGFuZCBBY2NvdW50aW5nIChBQUEpIGluZnJhc3RydWN0dXJl LAo+ID4+PiBhbmQgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuIEFsbCB0 aGVzZSBwcm90b2NvbHMKPiA+Pj4gZW5qb3kgd2lkZXNwcmVhZCBkZXBsb3ltZW50IG9uIHRoZSBJ bnRlcm5ldC4gQWx0aG91Z2ggdGhleSBhbGwgYWltCj4gPj4+IHRvIHNvbHZlIGEgc2ltaWxhciBn b2FsLCBhdCBhbiBhYnN0cmFjdCBsZXZlbCwgdGhleSBvZmZlciBxdWl0ZQo+ID4+PiBkaWZmZXJl bnQgZnVuY3Rpb25zIGFuZCB1dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4gVGhl c2UKPiA+Pj4gZGlmZmVyZW5jZXMgYXJlIG1vdGl2YXRlZCBieSB0aGUgbWFpbiBkZXBsb3ltZW50 IHVzZSBjYXNlcyB0aGV5IHdlcmUKPiBkZXNpZ25lZCBmb3IuCj4gPj4+Cj4gPj4+IFJlcXVpcmVt ZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGluZGljYXRlIHRoZSBzdWl0YWJpbGl0eSBvZgo+ ID4+PiBhbHJlYWR5IGV4aXN0aW5nIHdvcmssIHN1Y2ggYXMgT0F1dGgsIGFzIGEgc29sdXRpb24g Zm9yIGNvbnN0cmFpbmVkCj4gPj4+IGVudmlyb25tZW50cy4gVGhlc2UgcHJvdG9jb2xzIHdlcmUs IGhvd2V2ZXIsIG5vdCBvcHRpbWl6ZWQgZm9yCj4gPj4+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50 cy4gQWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBuZWVkIHRvIGJlCj4gPj4+IHRha2VuIGlu dG8gYWNjb3VudCBhcmUgdGhlIGxhY2sgb2YgYSBzdWl0YWJsZSB1c2VyLWludGVyZmFjZSBmb3IK PiA+Pj4gb2J0YWluaW5nIHRoZSBjb25zZW50IG9mIHRoZSB1c2VyIGFuZCB0aGUgaW5hYmlsaXR5 IG9mIGVtYmVkZGVkCj4gPj4+IGRldmljZXMgdG8gY29udGFjdCBhbiBhdXRob3JpemF0aW9uIHNl cnZlciBpbiByZWFsLXRpbWUgd2l0aCBldmVyeQo+ID4+PiBhY2Nlc3MgcmVxdWVzdCBkdWUgdG8g aW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSwgZXRjLgo+ID4+Pgo+ID4+PiBUaGlzIHdvcmtpbmcg Z3JvdXAgdGhlcmVmb3JlIGFpbXMgZm9yIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvcgo+ID4+ PiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB0byBlbmFibGUgYXV0aG9yaXplZCBh Y2Nlc3MgdG8KPiA+Pj4gcmVzb3VyY2VzIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQXMg YSBzdGFydGluZyBwb2ludCwgdGhlCj4gPj4+IHdvcmtpbmcgZ3JvdXAgd2lsbCBhc3N1bWUgdGhh dCBhY2Nlc3MgdG8gcmVzb3VyY2VzIG9mZmVyZWQgYnkgYQo+ID4+PiByZXNvdXJjZSBzZXJ2ZXIg YnkgYSBjbGllbnQgZGV2aWNlcyB0YWtlcyBwbGFjZSB1c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0 ZWQKPiBieSBEVExTLgo+ID4+PiBCb3RoIHJlc291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1heSBi ZSByZXNvdXJjZSBjb25zdHJhaW50LiBUaGlzCj4gPj4+IGFjY2VzcyB3aWxsIGJlIG1lZGlhdGVk IGJ5IGFuIGF1dGhvcml6YXRpb24gc2VydmVyLCB3aGljaCBkb2VzIG5vdAo+ID4+PiBzdWZmZXIg ZnJvbSB0aGUgc2FtZSByZXNvdXJjZSBsaW1pdGF0aW9ucy4KPiA+Pj4KPiA+Pj4gRXhpc3Rpbmcg YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGFyZSB1c2VkIGFuZAo+ ID4+PiByZS1hcHBsaWVkIGZvciB1c2Ugd2l0aCBjb25zdHJhaW5lZCBkZXZpY2VzLCB3aGVyZSBh cHBsaWNhYmxlLiBUaGlzCj4gPj4+IHJlcXVpcmVzIHJlbGV2YW50IHNwZWNpZmljYXRpb25zIHRv IGJlIHJldmlld2VkIGZvciBzdWl0YWJpbGl0eSwKPiA+Pj4gc2VsZWN0aW5nIGEgc3Vic2V0IG9m IHRoZW0sIHJlc3RyaWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mCj4gPj4+IHRoZSBz cGVjaWZpY2F0aW9ucy4gU29tZSBmdW5jdGlvbmFsaXRpZXMgbWF5LCBob3dldmVyLCBub3QgYmUK PiA+Pj4gYXZhaWxhYmxlIGluIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZm9yIHRob3NlIGNhc2Vz IG5ldwo+ID4+PiBmdW5jdGlvbmFsaXR5IGhhcyB0byBiZSBzdGFuZGFyZGl6ZWQuIFRodXMsIGV4 aXN0aW5nIHdvcmsgY2FuIGJlCj4gPj4+IGxldmVyYWdlZCBhbmQgdGhlIGdyb3VwIGJlbmVmaXRz IGZyb20gYXZhaWxhYmxlIHNlY3VyaXR5IGFuYWx5c2lzLAo+ID4+PiBpbXBsZW1lbnRhdGlvbiwg YW5kIGRlcGxveW1lbnQgZXhwZXJpZW5jZS4gTW9yZW92ZXIsIGEgc3RhbmRhcmRpemVkCj4gPj4+ IHNvbHV0aW9uIGZvciBmZWRlcmF0ZWQgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24g d2lsbCBoZWxwIHRvCj4gPj4+IHN0aW11bGF0ZSB0aGUgZGVwbG95bWVudCBvZiBJb1QgZGV2aWNl cyBvZmZlcmluZyBpbmNyZWFzZWQgc2VjdXJpdHkuCj4gPj4+Cj4gPj4+IE9uY2UgcHJvZ3Jlc3Mg aW4gaWRlbnRpZnlpbmcgc3VpdGFibGUgY2FuZGlkYXRlIHNvbHV0aW9ucyBoYXMgYmVlbgo+ID4+ PiBtYWRlIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdmVyaWZ5IHdoZXRoZXIgdGhlIHNhbWUgbWVj aGFuaXNtIGFyZQo+ID4+PiBhbHNvIGFwcGxpY2FibGUgYmV5b25kIHRoZSB1c2Ugb2YgQ29BUCBh bmQgRFRMUy4gSW4gcGFydGljdWxhciwgdGhlCj4gPj4+IGFiaWxpdHkgdG8gdXNlIHRoZSBkZXZl bG9wZWQgc29sdXRpb24gb3ZlciBIVFRQIGFuZCBUTFMgd2lsbCBiZQo+IGludmVzdGlnYXRlZC4K PiA+Pj4gRnVydGhlcm1vcmUsIHRvIGd1YXJhbnRlZSBzbW9vdGggdHJhbnNpdGlvbiB0aGUgaW50 ZWdyYXRpb24gd2l0aAo+ID4+PiBleGlzdGluZyBkZXBsb3ltZW50IHdpbGwgYmUgc3R1ZGllZC4g VGhpcyBwYXJ0aWN1bGFybHkgY29uY2VybnMgdGhlCj4gPj4+IHVzZSBvZiBwcm90b2NvbCB0cmFu c2xhdGlvbiBwcm94aWVzLgo+ID4+Pgo+ID4+PiBUbyBiZSBzdWNjZXNzZnVsIHRoaXMgd29ya2lu ZyBncm91cCByZXF1aXJlcyBleHBlcnRpc2UgaW4gc2VjdXJpdHksCj4gPj4+IHByaXZhY3ksIGFu ZCBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiB1c2FiaWxpdHkgaW4gdGhlIGNvbnN0cmFpbmVkCj4g Pj4+IGVudmlyb25tZW50IHNwYWNlLiBUaGlzIHdvcmsgZG9lcyBub3QgbWFrZSB0aGUgYXNzdW1w dGlvbiB0aGF0IHRoZQo+ID4+PiBwYXJ0eSBvZmZlcmluZyBhcHBsaWNhdGlvbiBsYXllciBzZXJ2 aWNlcyBpcyBhbHdheXMgdGhlIHNhbWUgcGFydHkKPiA+Pj4gb2ZmZXJpbmcgbmV0d29yayBhY2Nl c3Mgc2VydmljZXMuCj4gPj4+Cj4gPj4+IFRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93 aW5nIHRhc2tzIChpbiB0aGlzIG9yZGVyKToKPiA+Pj4KPiA+Pj4gMSkgVGhlIHdvcmtpbmcgZ3Jv dXAgV2lraSBwYWdlcyB3aWxsIGJlIHVzZWQgdG8gZG9jdW1lbnQgdXNlIGNhc2VzLAo+ID4+PiBy ZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEuIFRoaXMgd29yayB3aWxs IGd1aWRlIHRoZQo+ID4+PiBpZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNo YW5pc21zLgo+ID4+Pgo+ID4+PiAyKSBTZWxlY3Rpb24gb2YgYW4gYXV0aGVudGljYXRpb24gYW5k IGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9yCj4gPj4+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50 cy4KPiA+Pj4KPiA+Pj4gMykgRXZhbHVhdGlvbiBvZiB0aGUgY2FuZGlkYXRlIHNvbHV0aW9uIGZv ciB1c2Ugd2l0aCBIVFRQL1RMUyBhbmQKPiA+Pj4gcHJveHkgZGVwbG95bWVudHMuCj4gPj4+Cj4g Pj4+IC0tLS0tCj4gPj4+Cj4gPj4+IENpYW8KPiA+Pj4gSGFubmVzCj4gPj4+Cj4gPj4+IDxzaWdu YXR1cmUuYXNjPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gPj4+IEFjZSBtYWlsaW5nIGxpc3QKPiA+Pj4gQWNlQGlldGYub3JnCj4gPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlCj4gPj4KPiA+PiBaYWNoIFNoZWxieQo+ ID4+IERpcmVjdG9yIG9mIFRlY2hub2xvZ3kKPiA+PiBBUk0gSW50ZXJuZXQgb2YgVGhpbmdzIEJV Cj4gPj4gd3d3LmFybS5jb20KPiA+PiBtb2JpbGU6ICsxICg0MDgpIDIwMy05NDM0Cj4gPj4gU2t5 cGU6IHpkc2hlbGJ5Cj4gPj4gTGlua2VkSW46IGZpLmxpbmtlZGluLmNvbS9pbi96YWNoc2hlbGJ5 Lwo+ID4+Cj4gPj4KPiA+PiAtLSBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzCj4gPj4gYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlCj4gPj4gaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdAo+ ID4+IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlLCBvcgo+ID4+IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uwqAgVGhhbmsgeW91Lgo+ID4+Cj4gPj4gQVJNIExpbWl0ZWQsIFJlZ2lzdGVyZWQg b2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwKPiA+PiBSZWdpc3Rl cmVkIGluIEVuZ2xhbmQgJiBXYWxlcywgQ29tcGFueSBObzrCoCAyNTU3NTkwIEFSTSBIb2xkaW5n cyBwbGMsCj4gPj4gUmVnaXN0ZXJlZCBvZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRn ZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGluCj4gPj4gRW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5v OsKgIDI1NDg3ODIKPiA+Pgo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gPj4gQWNlIG1haWxpbmcgbGlzdAo+ID4+IEFjZUBpZXRmLm9yZwo+ID4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlCj4gPgo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IEFjZSBtYWlsaW5n IGxpc3QKPiA+IEFjZUBpZXRmLm9yZwo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hY2UKPiA+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpBY2UgbWFpbGluZyBsaXN0CkFjZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FjZQo= ----_com.android.email_2589254224154210 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+UGVyc29uYWxseSwgSSB3b3VsZCBh bHNvIHJhdGhlciBzZWUgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIHB1Ymxpc2hlZCBh cyBpbmZvcm1hdGlvbmFsUkZDcy4gJm5ic3A7SSB0aGluayB0aGF0IGEgd2lraSBtaWdodCBiZSBh IGdvb2Qgd2F5IHRvIGNvbGxlY3QgdGhlbSBhdCBmaXJzdCwgYnV0IEkgd291bGQgcHJlZmVyIHRv IGJlIHN1cmUgdGhhdCB3ZSBoYXZlIGNvbnNlbnN1cyBvbiB0aGUgcHJvYmxlbShzKSB3ZSBhcmUg dHJ5aW5nIHRvIHNvbHZlLiAmbmJzcDtJIGFsc28gdGhpbmsgaXQgd2lsbCBiZSB1c2VmdWwgdG8g aGF2ZSB0aGVzZSB0aGluZ3MgaW4gYXJjaGl2YWwgZm9ybSBsYXRlci48ZGl2Pjxicj48L2Rpdj48 ZGl2PkkgZG8gbm90IHRoaW5rIHRoZSBvdGhlciB3b3JrIG9mIHRoZSBncm91cCBzaG91bGQgYmUg Z2F0ZWQgb24gdGhlIHJlcXVpcmVtZW50cywgdGhvdWdoLCBhcyBJIHRoaW5rIHRoYXQgaXQgbWFr ZXMgc2Vuc2UgdG8gZXhwbG9yZSBob3cgZXhpc3RpbmcgdGVjaG5vbG9naWVzIGNvdWxkIG9yIGNv dWxkbid0IG1lZXQgdGhlIHJlcXVpcmVtZW50cyB0byBpbnN1cmUgdGhhdCBvdXIgcmVxdWlyZW1l bnRzIGFyZSByZWFsaXR5LWJhc2VkLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TWFyZ2FyZXQ8 L2Rpdj48YnI+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZy b20gTGlrZXBlbmcgJmx0O2xpa2VwZW5nQGh1YXdlaS5jb20mZ3Q7IDxicj5EYXRlOiAwMy8xMy8y MDE0ICA0OjI4IEFNICAoR01ULTA1OjAwKSA8YnI+VG8gSGFubmVzIFRzY2hvZmVuaWcgJmx0O2hh bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7LEfDtnJhbiBTZWxhbmRlciAmbHQ7Z29yYW4uc2Vs YW5kZXJAZXJpY3Nzb24uY29tJmd0OyxaYWNoIFNoZWxieSAmbHQ7WmFjaC5TaGVsYnlAYXJtLmNv bSZndDsgPGJyPkNjIGFjZUBpZXRmLm9yZyA8YnI+U3ViamVjdCBSZTogW0FjZV0gQUNFIENoYXJ0 ZXIgUHJvcG9zYWwgdjAuNSA8YnI+IDxicj48YnI+TXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0 IHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGNhbiBoZWxwIHBlb3BsZSB0 byB1bmRlcnN0YW5kIHdoYXQga2luZCBvZiBpc3N1ZXMgd2UgYXJlIHRyeWluZyB0byByZXNvbHZl Ljxicj48YnI+SSBjYW4gc2VlIHNvbWUgdmFsdWVzIHRvIHB1Ymxpc2ggaXQgaW50byBSRkNzLiBJ ZiBpdCBpcyBhIHdpa2kgcGFnZSwgd2Ugd2lsbCBoYXZlIGxlc3MgcGVvcGxlIHRvIHJldmlldyBp dCBvciBpbXByb3ZlIGl0LiA8YnI+PGJyPkVzcGVjaWFsbHkgdGhlIHVzZSBjYXNlIGFuZCByZXF1 aXJlbWVudCBkb2N1bWVudCBpcyBhbHJlYWR5IGluIGEgZ29vZCBzaGFwZSBhbmQgaXQgaXMgcmVm ZXJlbmNlZCBzZXZlcmFsIHRpbWVzIGluIHRoZSBtYWlsaW5nIGxpc3QgdG8gaW50cm9kdWNlIG91 ciB3b3JrIHRvIG91dHNpZGUuPGJyPjxicj5UaGFua3MsPGJyPjxicj5LaW5kIFJlZ2FyZHM8YnI+ S2VwZW5nPGJyPjxicj4mZ3Q7IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS08YnI+Jmd0OyDlj5Hku7bk uro6IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggSGFubmVzIFRzY2hv ZmVuaWc8YnI+Jmd0OyDlj5HpgIHml7bpl7Q6IDIwMTTlubQz5pyIMTPml6UgNDozMzxicj4mZ3Q7 IOaUtuS7tuS6ujogR8O2cmFuIFNlbGFuZGVyOyBaYWNoIFNoZWxieTxicj4mZ3Q7IOaKhOmAgTog YWNlQGlldGYub3JnPGJyPiZndDsg5Li76aKYOiBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9z YWwgdjAuNTxicj4mZ3Q7IDxicj4mZ3Q7IEhpIEdvZXJhbiw8YnI+Jmd0OyA8YnI+Jmd0OyBJIHJl YWQgYSBsaXR0bGUgYml0IGJldHdlZW4gdGhlIGxpbmVzIG9mIHlvdXIgbWFpbCBhbmQgeW91ciBt YWluIGNvbmNlcm4gaXMgdGhhdDxicj4mZ3Q7IHlvdSB3YW50IHRvIGhhdmUgYW4gUkZDIHB1Ymxp c2hlZCB3aXRoIHlvdXIgbmFtZSBvbiBpdC48YnI+Jmd0OyBBIHdpa2kgcGFnZSB0byBkb2N1bWVu dCB0aGUgcmVxdWlyZW1lbnRzLCBhbmQgdXNlIGNhc2VzIGlzIG5vdCBnb29kIGVub3VnaDxicj4m Z3Q7IGZvciB5b3UuPGJyPiZndDsgPGJyPiZndDsgRm9yIHlvdSBwdXR0aW5nIHRoZSBkcmFmdCB0 ZXh0IG9uIGEgV0cgd2lraSBmZWVscyBsaWtlIHdhc3RlZCB0aW1lLjxicj4mZ3Q7IEl0IGlzIGp1 c3QgYSBkaWZmZXJlbnQgZm9ybSBvZiBkb2N1bWVudGluZyB0aGUgd29yay48YnI+Jmd0OyA8YnI+ Jmd0OyBNeSBleHBlcmllbmNlIHdpdGggdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgaGFzIG5v dCBiZWVuIGdyZWF0IGluIHRoZSBJRVRGLjxicj4mZ3Q7IEluIGVzc2VuY2UgZXZlcnlvbmUgcXVp Y2tseSBtb3ZlcyBvbiBvbmNlIHRoZSBncm91cCBkZWNpZGVzIGFib3V0IGE8YnI+Jmd0OyBwYXJ0 aWN1bGFyIHNvbHV0aW9uIGRpcmVjdGlvbi4gSXQgdGhlbiBiZWNvbWVzIHZlcnkgaGFyZCAoZm9y IHRoZTxicj4mZ3Q7IGNoYWlycykgdG8gZmluaXNoIHRoZSByZXF1aXJlbWVudHMgd29yayBzaW5j ZSBub2JvZHkgd2FudHMgdG8gcmV2aWV3IG9yIGxvb2s8YnI+Jmd0OyBhdCB0aGVtIGFueW1vcmUu PGJyPiZndDsgPGJyPiZndDsgVXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgYXJlIGdyZWF0IGR1 cmluZyB0aGUgaW5pdGlhbCBwYXJ0IG9mIHRoZSB3b3JrIHRvIGdldDxicj4mZ3Q7IGFuIHVuZGVy c3RhbmRpbmcgb2YgdGhlIG1haW4gY2hhbGxlbmdlcy48YnI+Jmd0OyA8YnI+Jmd0OyBIYXZpbmcg c2FpZCB0aGF0IEkgd2lsbCBsZWF2ZSBpdCB0byB0aGUgZ3JvdXAgdG8gZGVjaWRlIHdoYXQgdGhl eSB3YW50IHRvIGRvOjxicj4mZ3Q7IFJGQ3Mgb3IgV2lraSBwYWdlPGJyPiZndDsgPGJyPiZndDsg Q2lhbzxicj4mZ3Q7IEhhbm5lczxicj4mZ3Q7IDxicj4mZ3Q7IFBTOiBSZWdhcmRpbmcgeW91ciBv dGhlciBjb21tZW50IGFib3V0IHBvaW50aW5nIHRvIHRoZSBjb25zdHJhaW50IG5hdHVyZSB0bzxi cj4mZ3Q7IGV2ZXJ5IGl0ZW0uIFdlIGNhbiBkbyB0aGF0IGlmIHlvdSBmZWVsIGJldHRlciBidXQg dGhlIGVudGlyZSBjaGFydGVyIHBhZ2U8YnI+Jmd0OyBhbHJlYWR5IHNheXMgMTAgdGltZXMgdGhh dCB3ZSBhcmUgZm9jdXNpbmcgb24gdGhlIGNvbnN0cmFpbnQgc3BhY2UuPGJyPiZndDsgSSBhbSBz dXJlIHRoYXQgdGhlIHJlYWRlciB3aWxsIGhhdmUgdW5kZXJzdG9vZCB0aGF0IHdoZW4gdGhleSBn ZXQgdG8gdGhlIHRhc2s8YnI+Jmd0OyBsaXN0Ljxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IE9u IDAzLzEyLzIwMTQgMTA6MzIgQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZTo8YnI+Jmd0OyAmZ3Q7 IEhhbm5lcywgWmFjaCBhbmQgYWxsLDxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IEkgbXVzdCBz YXkgSSBkb27CuXQgZmluZCB0aGUgdGFzayBsaXN0IG9mIHRoZSBjdXJyZW50IGNoYXJ0ZXIgdmVy eSBoZWxwZnVsOjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IMKzVGhlIHdvcmtpbmcgZ3JvdXAg aGFzIHRoZSBmb2xsb3dpbmcgdGFza3MgKGluIHRoaXMgb3JkZXIpOjxicj4mZ3Q7ICZndDs8YnI+ Jmd0OyAmZ3Q7IDEpIFRoZSB3b3JraW5nIGdyb3VwIFdpa2kgcGFnZXMgd2lsbCBiZSB1c2VkIHRv IGRvY3VtZW50IHVzZSBjYXNlcyw8YnI+Jmd0OyAmZ3Q7IHJlcXVpcmVtZW50cywgYW5kIHByb3Rv Y29sIGRlc2lnbiBjcml0ZXJpYS4gVGhpcyB3b3JrIHdpbGwgZ3VpZGUgdGhlPGJyPiZndDsgJmd0 OyBpZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNoYW5pc21zLjxicj4mZ3Q7 ICZndDs8YnI+Jmd0OyAmZ3Q7IDIpIFNlbGVjdGlvbiBvZiBhbiBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiBwcm90b2NvbCBmb3I8YnI+Jmd0OyAmZ3Q7IGNvbnN0cmFpbmVkIGVudmly b25tZW50cy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAzKSBFdmFsdWF0aW9uIG9mIHRoZSBj YW5kaWRhdGUgc29sdXRpb24gZm9yIHVzZSB3aXRoIEhUVFAvVExTIGFuZDxicj4mZ3Q7ICZndDsg cHJveHkgZGVwbG95bWVudHMuwrI8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBUaGlzIGxpc3Qg ZG9lcyBub3QgZ2l2ZSBtdWNoIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgd29yayB0byBiZTxicj4m Z3Q7ICZndDsgY29uZHVjdGVkIHRoYW4gaXMgYWxyZWFkeSBnaXZlbiBieSB0aGUgdGl0bGUgb2Yg dGhlIFdHLiBUbyBhIHBlcnNvbjxicj4mZ3Q7ICZndDsgbm90IGhhdmluZyBmb2xsb3dlZCB0aGUg ZGlzY3Vzc2lvbiwgdGhlIGltcHJlc3Npb24gaXMgdGhhdCB0aGUgd29yazxicj4mZ3Q7ICZndDsg c3RhcnRzIGZyb20gc2NyYXRjaCBhbmQgdGhlcmUgaXMgbm8gY2xlYXIgdW5kZXJzdGFuZGluZyBv ZiB3aGF0IHRvIGRvLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IElmIHdlIGNhbsK5dCBmb3Jt dWxhdGUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBmaXJzdCBzdGVwIHRvd2FyZHMgYTxicj4m Z3Q7ICZndDsgc29sdXRpb24gaW4gc29tZSBkZWdyZWUgb2YgZGV0YWlsIGJlZm9yZSBzdGFydGlu ZyB0aGUgV0cgdGhhdCB3aWxsPGJyPiZndDsgJmd0OyBhbnl3YXkgYmUgdGhlIGZpcnN0IHRhc2sg dG8gZG8sIHNvIGxldMK5cyB0cnkgdG8gZ2V0IHNvbWV0aGluZyBpbiB3cml0aW5nLjxicj4mZ3Q7 ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAiMSkgVGhlIHdvcmtpbmcgZ3JvdXAgV2lr aSBwYWdlcyB3aWxsIGJlIHVzZWQgdG8gZG9jdW1lbnQgdXNlIGNhc2VzLDxicj4mZ3Q7ICZndDsg cmVxdWlyZW1lbnRzLCBhbmQgcHJvdG9jb2wgZGVzaWduIGNyaXRlcmlhLiBUaGlzIHdvcmsgd2ls bCBndWlkZSB0aGU8YnI+Jmd0OyAmZ3Q7IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3Rv Y29sIG1lY2hhbmlzbXMuIjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFRoaXMgaXMgaGlkaW5n IHRoZSBmYWN0IHRoYXQgdGhlcmUgaGFzIGJlZW4gNiBtb250aHMgb2Ygd29yayBvbiB0aGU8YnI+ Jmd0OyAmZ3Q7IHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZHJhZnQgKHRoZSBmaXJzdCB2ZXJz aW9uIG9mIHRoaXMgZHJhZnQgd2FzPGJyPiZndDsgJmd0OyBzdWJtaXR0ZWQgdG8gQ29SRSBpbiBJ RVRGODgpLCB3aGljaCBubyBvbmUgaGFzIGRpc2FncmVlZCBpcyBzZXR0aW5nPGJyPiZndDsgJmd0 OyB0aGUgc3RhZ2UgZm9yIHRoaXMgd29yay4gTG9vayBhdCBwYXJhbGxlbCB0aHJlYWRzIG9uIHRo aXMgbWFpbGluZyBsaXN0PGJyPiZndDsgJmd0OyB3aGVyZSBwZW9wbGUgYXNrIHdoZXRoZXIgdGhl aXIgcGFydGljdWxhciBzZWN1cml0eS1mb3ItSW9UIGRyYWZ0IGZpdHM8YnI+Jmd0OyAmZ3Q7IGlu dG8gQUNFLiBUaGUgYW5zd2VyIEhhbm5lcyBpcyBnaXZpbmcgaXMgY29ycmVjdGx5OiB0aGUgc2Nv cGUgb2YgdGhpczxicj4mZ3Q7ICZndDsgd29yayBpcyB3aGF0IGlzIG91dGxpbmVkIGJ5IHRoZSB1 c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0LiBJPGJyPiZndDsgJmd0OyBkb27CuXQgbWlu ZCB1c2luZyB0aGUgV2lraSBhcyBhIHdvcmtpbmcgdG9vbCBidXQgdGhpcyBkb2VzIG5vdCBnaXZl PGJyPiZndDsgJmd0OyB0cmFjZWFiaWxpdHkgYSB5ZWFyIGxhdGVyLiBBbmQgSSBkb27CuXQgc2Vl IHRoZSBwb2ludCBpZiBjb3B5aW5nIHRoZTxicj4mZ3Q7ICZndDsgdXNlIGNhc2UgZG9jdW1lbnQg aW50byBhIFdpa2kgcGFnZSAtIHJlYWQgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIHlvdXI8YnI+Jmd0 OyBjb21tZW50cyE8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBXaGVuIGl0IGNvbWVzIHRvIHBy b3RvY29sIGRlc2lnbiBjcml0ZXJpYSwgSSBhZ3JlZSB0aGF0IG1vcmUgd29yayBpczxicj4mZ3Q7 ICZndDsgbmVlZGVkLCBmb3Igd2hpY2ggdGhlIFdpa2kgbWF5IGJlIHN1aXRhYmxlLiBOZXZlcnRo ZWxlc3MgSSBpbnNpc3Qgb248YnI+Jmd0OyAmZ3Q7IGRvY3VtZW50aW5nIHRoZSBkZXNpZ24gY3Jp dGVyaWEgYW5kIGl0cyByYXRpb25hbGUgc2luY2UgdGhhdCBwcm92aWRlczxicj4mZ3Q7ICZndDsg YSBtZWFucyBmb3IgdHJhY2VhYmlsaXR5LiBNYWtlIGl0IGEgbWlsZXN0b25lIHRvIGhhdmUgYSBk cmFmdCB3aXRoPGJyPiZndDsgJmd0OyBhc3N1bXB0aW9ucyBhbmQgZGVzaWduIGNyaXRlcmlhJm5i c3A7ICh5b3UgbWF5IGluY2x1ZGUgwrNhcmNoaXRlY3R1cmXCsiBpbjxicj4mZ3Q7ICZndDsgdGhp cyBkb2N1bWVudCkuIFRoaXMgd29yayBpcyBhbnl3YXkgYSBwcmUtcmVxdWlzaXRlIGZvciBjb21p bmcgdG8gYTxicj4mZ3Q7ICZndDsgc29sdXRpb24sIGFuZCBvbmNlIHlvdSBoYXZlIHRoaXMgY29u dGVudCwgdGhlIGNhbmRpZGF0ZSBzb2x1dGlvbnMgYXJlPGJyPiZndDsgJmd0OyBtdWNoIGVhc2ll ciBldmFsdWF0ZWQuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgU28sIGNoYW5nZSAxKSB0byBz dGF0ZSBzb21ldGhpbmcgbGlrZTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICIxwrkgKTxicj4m Z3Q7ICZndDsgYSkgY29tcGxldGUgdGhlIHdvcmsgb24gdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50 czxicj4mZ3Q7ICZndDsgYikgdXNlIFdpa2kgcGFnZXMgZm9yIGxpc3RpbmcgYXNzdW1wdGlvbnMg YW5kIHByb3RvY29sIGRlc2lnbjxicj4mZ3Q7ICZndDsgY3JpdGVyaWEsIGRvY3VtZW50IHRoZSBy ZXN1bHQgaW4gYSBkcmFmdCI8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBQcm94eSBkZXBsb3lt ZW50IGFzcGVjdHMgZml0cyB3ZWxsIGludG8gMWIpJm5ic3A7IFttb3JlIGluIHNlcGFyYXRlPGJy PiZndDsgJmd0OyB1cGNvbWluZyBtYWlsXTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0OyAyKSBTZWxlY3Rpb24gb2YgYW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRp b24gcHJvdG9jb2wgZm9yPGJyPiZndDsgJmd0OyBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuPGJy PiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgSGVyZSBJwrltIG1pc3NpbmcgYW1vbmcgb3RoZXIgdGhp bmdzIHRoZSBzcGVjaWZpYyBwcm9ibGVtIHN0YXRlbWVudC48YnI+Jmd0OyAmZ3Q7IFRoZSBwcmVs aW1pbmFyeSBjb25jbHVzaW9ucyBmcm9tIHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRy YWZ0PGJyPiZndDsgJmd0OyBmb3JtZWQgdGhlIGJhc2lzIGZvciB0aGUgcHJvYmxlbSBzdGF0ZW1l bnQgYXMgcHJlc2VudGVkIGluIHRoZSBCT0Y6IFdlPGJyPiZndDsgJmd0OyBsYWNrIGEgbWVjaGFu aXNtIGZvciBkeW5hbWljIGFuZCBmaW5lIGdyYWluZWQgYWNjZXNzIGNvbnRyb2wgZm9yPGJyPiZn dDsgJmd0OyBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZn dDsgVGhlIHByb2Nlc3MgaGVyZSBzaG91bGQgYmUgdG86PGJyPiZndDsgJmd0OyAiMsK5KSBpZGVu dGlmeSBzdWl0YWJsZSBwcm90b2NvbCBtZWNoYW5pc21zIGFuZCBtYXRjaCBjYW5kaWRhdGU8YnI+ Jmd0OyAmZ3Q7IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyBhZ2Fp bnN0IHJlcXVpcmVtZW50cyBhbmQ8YnI+Jmd0OyAmZ3Q7IGRlc2lnbiBjcml0ZXJpYSwgaW4gcGFy dGljdWxhciBhZGRyZXNzaW5nIGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZDxicj4mZ3Q7ICZndDsg YWNjZXNzIGNvbnRyb2wgc3VpdGFibGUgZm9yIENvQVAgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3Rz IGluIGNvbnN0cmFpbmVkPGJyPiZndDsgZW52aXJvbm1lbnRzLiI8YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IDMpIEV2YWx1YXRpb24gb2YgdGhlIGNh bmRpZGF0ZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggSFRUUC9UTFMgYW5kPGJyPiZndDsgJmd0OyBw cm94eSBkZXBsb3ltZW50cy7Csjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0 OyBBcyBtZW50aW9uZWQgYWJvdmUsIHByb3h5IGRlcGxveW1lbnRzIGNvdWxkIGJlIGNvbnNpZGVy ZWQgYXMgcGFydCBvZjxicj4mZ3Q7IDHCuWIpLjxicj4mZ3Q7ICZndDsgSW4gMsK5KSBpdCBpcyBh bHJlYWR5IHN0YXRlZCB0aGF0IGluIHBhcnRpY3VsYXIgd2Ugc2hvdWxkIGNvbnNpZGVyIENvQVA8 YnI+Jmd0OyAmZ3Q7IG9uIGludGVyZmFjZSAoSUkpLiBBcyBmb3IgdXNlIG9mIG90aGVyIHByb3Rv Y29scyBiZXNpZGVzIENvQVAgdGhhdDxicj4mZ3Q7ICZndDsgaXNzdWUgaXMgb3J0aG9nb25hbCB0 byB0aGlzIHNvIEkgbGVhdmUgdGhhdCBvdXQgZnJvbSB0aGlzIGRpc2N1c3Npb24uPGJyPiZndDsg Jmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBHw7ZyYW48YnI+Jmd0 OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0 Ozxicj4mZ3Q7ICZndDsgT24gMTEvMDMvMTQgMTY6NDksICJaYWNoIFNoZWxieSIgJmx0O1phY2gu U2hlbGJ5QGFybS5jb20mZ3Q7IHdyb3RlOjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBI YW5uZXMsPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBJIGFtIGhhcHB5IHdpdGgg dGhpcyBjaGFydGVyIHdpdGggb25lIGV4Y2VwdGlvbi4gVGhlIHByb3h5IGl0ZW0gaGVyZTxicj4m Z3Q7ICZndDsmZ3Q7IHNlZW1zIHRvIGJlIG1vcmUgb2YgYSBkaXN0cmFjdGlvbiB0aGFuIGFueXRo aW5nIGVsc2UsIGFuZCB3aWxsPGJyPiZndDsgJmd0OyZndDsgcHJvYmFibHkgcmVzdWx0IGluIGlu Y3JlYXNlZCBjb21wbGV4aXR5LiBXYXMgcHJveHkgc3VwcG9ydCBtYXliZSBqdXN0PGJyPiZndDsg Jmd0OyZndDsgYSBtaXN1bmRlcnN0YW5kaW5nPyBEbyB3ZSByZWFsbHkgc2VlIHRoZSBuZWVkIGZv ciBhIHByb3h5IGluIHRoZTxicj4mZ3Q7ICZndDsmZ3Q7IG1pZGRsZSBvZiBJIG9yIElJST88YnI+ Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgd2hhdCB3ZSByZWFsbHkgd2Fu dCBoZXJlIGlzIHRvIG1ha2Ugc3VyZSB0aGF0IGUuZy4gZXZlbjxicj4mZ3Q7ICZndDsmZ3Q7IHRo cm91Z2ggSSBpcyBiYXNlZCBvbiBIVFRQL1RMUywgSUkgYW5kIElJSSBmb3IgZXhhbXBsZSBjYW4g cnVuPGJyPiZndDsgJmd0OyZndDsgQ29BUC9EVExTLiBJbiBvdGhlciB3b3Jkcywgc29tZSBpbnRl cmZhY2VzIGNhbiBiZSBjb25zdHJhaW5lZCB3aGlsZTxicj4mZ3Q7ICZndDsmZ3Q7IG90aGVycyBh cmUgbm90LiBJIHRoaW5rIHRoZSBjaGFydGVyIGFscmVhZHkgY292ZXJzIHRoaXMgZmluZS48YnI+ Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IFNvIG15IHByb3Bvc2FsIHdvdWxkIGJlIHRv IHJlbW92ZSB0aGUgbWVudGlvbiBvZiBwcm90b2NvbCB0cmFuc2xhdGlvbjxicj4mZ3Q7ICZndDsm Z3Q7IHByb3hpZXMuIElmIHdlIHJlYWxseSBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgc29tZSBkYXkg aW4gdGhlIGZ1dHVyZSw8YnI+Jmd0OyAmZ3Q7Jmd0OyBpdCBjb3VsZCBiZSB0YWNrbGVkIHRoZW4u PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBaYWNoPGJyPiZndDsgJmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7Jmd0OyBPbiBNYXIgMTEsIDIwMTQsIGF0IDEyOjUwIEFNLCBIYW5uZXMgVHNj aG9mZW5pZzxicj4mZ3Q7ICZndDsmZ3Q7ICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0 OyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBIaSBhbGwsPGJy PiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7IEkgaGF2ZSB0YWtlbiB0aGUg ZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBhbmQgdGhlIHJlY2VudDxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyBkaXNjdXNzaW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBwcm9kdWNlZCBhIG5ldyBz dHJhd21hbiBwcm9wb3NhbC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgVGhlIGNoYW5nZXMgaW5jbHVkZTo8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgKiBBZGRlZCB0aGUg Zm9jdXMgb24gRFRMUy9Db0FQIHdpdGggYW4gaW5kaWNhdGlvbiB0aGF0IHdlIHdpbGwgY2hlY2s8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgYSBjYW5kaWRhdGUgc29sdXRpb24gZm9yIHN1aXRhYmlsaXR5 IHdpdGggSFRUUC9UTFMuPGJyPiZndDsgJmd0OyZndDsmZ3Q7ICogQWRkZWQgdGV4dCB0byBpbmRp Y2F0ZSB0aGF0IHdlIHdpbGwgYWxzbyB2ZXJpZnkgdGhlIHN1aXRhYmlsaXR5IG9mPGJyPiZndDsg Jmd0OyZndDsmZ3Q7IHRoZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggcHJvdG9jb2wgdHJhbnNsYXRp b24gcHJveGllcy48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgKiBTaW1wbGlmaWVkIHRoZSB0YXNrIGxp c3QgYnkgcmVtb3Zpbmcgc29sdXRpb24gc3BlY2lmaWMgaXRlbXMuPGJyPiZndDsgJmd0OyZndDsm Z3Q7ICogTWVyZ2VkIHNldmVyYWwgaXRlbXMgb24gdGhlIHRhc2sgbGlzdCAodXNlIGNhc2VzLCBy ZXF1aXJlbWVudHMsPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGFuZCBwcm90b2NvbCBkZXNpZ24gZ3Vp ZGVsaW5lcykuIEZvbGxvd2VkIHRoZSBzdWdnZXN0aW9uIHRvIHVzZSBvZiBhPGJyPiZndDsgJmd0 OyZndDsmZ3Q7IFdpa2kgZm9yIGNhcHR1cmluZyB0aG9zZS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgV2hhdCBkbyB5b3UgdGhpbms/PGJyPiZndDsgJmd0OyZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7IC0tLS0tPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsmZ3Q7IERyYWZ0IENoYXJ0ZXIgVjAuNSAtIEF1dGhlbnRpY2F0aW9uIGFuZCBB dXRob3JpemF0aW9uIGZvcjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBDb25zdHJhaW5lZCBFbnZpcm9u bWVudCAoQUNFKTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGUg SUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGVudmlyb25t ZW50czxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVk IGluIENQVSwgbWVtb3J5LCBhbmQgcG93ZXIuIEl0IHdhczxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBv YnNlcnZlZCB0aGF0IEludGVybmV0IHByb3RvY29scyBjYW4gYmUgYXBwbGllZCB0byB0aGVzZSBj b25zdHJhaW5lZDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBlbnZpcm9ubWVudHMsIG9mdGVuIG9ubHkg cmVxdWlyaW5nIG1pbm9yIHR3ZWFraW5nIGFuZCBwcm9maWxpbmcuIEluPGJyPiZndDsgJmd0OyZn dDsmZ3Q7IG90aGVyIGNhc2VzLCBuZXcgcHJvdG9jb2xzIGhhdmUgYmVlbiBkZWZpbmVkIHRvIGFk ZHJlc3MgdGhlIHNwZWNpZmljPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50cyBvZiBj b25zdHJhaW5lZCBkZXZpY2VzIGFuZCBuZXR3b3Jrcy4gQW4gZXhhbXBsZSBvZiBzdWNoPGJyPiZn dDsgJmd0OyZndDsmZ3Q7IGEgcHJvdG9jb2wgaXMgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9u IFByb3RvY29sIChDb0FQKS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgY29tcG9uZW50czxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyBBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIHF1ZXN0aW9uPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGFsc28gYXJpc2Ug aW4gZW52aXJvbm1lbnRzIHdpdGggY29uc3RyYWluZWQgbm9kZXMgYW5kIG5ldHdvcmtzLiBGb3I8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgZXhhbXBsZSwgYSBkb29yIGxvY2sgaGFzIHRvIGF1dGhvcml6 ZSB0aGUgcGVyc29uIHNlZWtpbmcgYWNjZXNzPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHVzaW5nIGEg ImRpZ2l0YWwga2V5Ii4gV2hlcmUgYXJlIHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBzdG9y ZWQ/PGJyPiZndDsgJmd0OyZndDsmZ3Q7IEhvdyBkb2VzIHRoZSBkaWdpdGFsIGtleSBjb21tdW5p Y2F0ZSB3aXRoIHRoZSBsb2NrPyBEb2VzIHRoZSBsb2NrPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGlu dGVyYWN0IHdpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0YWluIGF1dGhvcml6YXRp b248YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb24/IEhvdyBjYW4gYWNjZXNzIGJlIGdy YW50ZWQgdG8gb3RoZXIgcGVyc29ucyB0ZW1wb3JhcmlseT88YnI+Jmd0OyBIb3cgY2FuIGFjY2Vz cyBiZSByZXZva2VkPzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGVzZSB0eXBlcyBvZiBxdWVzdGlv bnMgaGF2ZSBiZWVuIGFuc3dlcmVkIGJ5IGV4aXN0aW5nIHByb3RvY29sczxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyBmb3IgdXNlIGNhc2VzIG91dHNpZGUgdGhlIGNvbnN0cmFpbmVkIGVudmlyb25tZW50 LiBCdXQgaW48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgY29uc3RyYWluZWQgZW52aXJvbm1lbnQsIGFk ZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHBvc2UgY2hhbGxlbmdlcyBmb3I8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgdGhlIHVzZSBvZiB2YXJpb3VzIHNlY3VyaXR5IHByb3RvY29scy48YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5 IGluIGRldmVsb3BpbmcgdGhyZWUgcGFydHkgYXV0aGVudGljYXRpb248YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGZvciBkaXN0cmlidXRlZCBlbnZpcm9u bWVudHMuIEV4YW1wbGVzPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGluY2x1ZGUgS2VyYmVyb3MsIHRo ZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgQXV0aGVudGljYXRpb24sIEF1dGhvcml6YXRpb24sIGFuZCBBY2NvdW50aW5nIChBQUEpIGlu ZnJhc3RydWN0dXJlLDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBhbmQgdGhlIFdlYiBBdXRob3JpemF0 aW9uIFByb3RvY29sIChPQXV0aCkuIEFsbCB0aGVzZSBwcm90b2NvbHM8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgZW5qb3kgd2lkZXNwcmVhZCBkZXBsb3ltZW50IG9uIHRoZSBJbnRlcm5ldC4gQWx0aG91 Z2ggdGhleSBhbGwgYWltPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHRvIHNvbHZlIGEgc2ltaWxhciBn b2FsLCBhdCBhbiBhYnN0cmFjdCBsZXZlbCwgdGhleSBvZmZlciBxdWl0ZTxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyBkaWZmZXJlbnQgZnVuY3Rpb25zIGFuZCB1dGlsaXplIGRpZmZlcmVudCBtZXNzYWdl IGV4Y2hhbmdlcy4gVGhlc2U8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgZGlmZmVyZW5jZXMgYXJlIG1v dGl2YXRlZCBieSB0aGUgbWFpbiBkZXBsb3ltZW50IHVzZSBjYXNlcyB0aGV5IHdlcmU8YnI+Jmd0 OyBkZXNpZ25lZCBmb3IuPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7 IFJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGluZGljYXRlIHRoZSBzdWl0YWJp bGl0eSBvZjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBhbHJlYWR5IGV4aXN0aW5nIHdvcmssIHN1Y2gg YXMgT0F1dGgsIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkPGJyPiZndDsgJmd0OyZndDsm Z3Q7IGVudmlyb25tZW50cy4gVGhlc2UgcHJvdG9jb2xzIHdlcmUsIGhvd2V2ZXIsIG5vdCBvcHRp bWl6ZWQgZm9yPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4g QWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBuZWVkIHRvIGJlPGJyPiZndDsgJmd0OyZndDsm Z3Q7IHRha2VuIGludG8gYWNjb3VudCBhcmUgdGhlIGxhY2sgb2YgYSBzdWl0YWJsZSB1c2VyLWlu dGVyZmFjZSBmb3I8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgb2J0YWluaW5nIHRoZSBjb25zZW50IG9m IHRoZSB1c2VyIGFuZCB0aGUgaW5hYmlsaXR5IG9mIGVtYmVkZGVkPGJyPiZndDsgJmd0OyZndDsm Z3Q7IGRldmljZXMgdG8gY29udGFjdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBpbiByZWFsLXRp bWUgd2l0aCBldmVyeTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBhY2Nlc3MgcmVxdWVzdCBkdWUgdG8g aW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSwgZXRjLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIHdvcmtpbmcgZ3JvdXAgdGhlcmVmb3JlIGFpbXMgZm9yIGEg c3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvcjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBhdXRoZW50aWNh dGlvbiBhbmQgYXV0aG9yaXphdGlvbiB0byBlbmFibGUgYXV0aG9yaXplZCBhY2Nlc3MgdG88YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsgcmVzb3VyY2VzIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4g QXMgYSBzdGFydGluZyBwb2ludCwgdGhlPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHdvcmtpbmcgZ3Jv dXAgd2lsbCBhc3N1bWUgdGhhdCBhY2Nlc3MgdG8gcmVzb3VyY2VzIG9mZmVyZWQgYnkgYTxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyByZXNvdXJjZSBzZXJ2ZXIgYnkgYSBjbGllbnQgZGV2aWNlcyB0YWtl cyBwbGFjZSB1c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0ZWQ8YnI+Jmd0OyBieSBEVExTLjxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyBCb3RoIHJlc291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1heSBiZSBy ZXNvdXJjZSBjb25zdHJhaW50LiBUaGlzPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGFjY2VzcyB3aWxs IGJlIG1lZGlhdGVkIGJ5IGFuIGF1dGhvcml6YXRpb24gc2VydmVyLCB3aGljaCBkb2VzIG5vdDxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBzdWZmZXIgZnJvbSB0aGUgc2FtZSByZXNvdXJjZSBsaW1pdGF0 aW9ucy48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgRXhpc3Rpbmcg YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGFyZSB1c2VkIGFuZDxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyByZS1hcHBsaWVkIGZvciB1c2Ugd2l0aCBjb25zdHJhaW5lZCBk ZXZpY2VzLCB3aGVyZSBhcHBsaWNhYmxlLiBUaGlzPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHJlcXVp cmVzIHJlbGV2YW50IHNwZWNpZmljYXRpb25zIHRvIGJlIHJldmlld2VkIGZvciBzdWl0YWJpbGl0 eSw8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgc2VsZWN0aW5nIGEgc3Vic2V0IG9mIHRoZW0sIHJlc3Ry aWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHRo ZSBzcGVjaWZpY2F0aW9ucy4gU29tZSBmdW5jdGlvbmFsaXRpZXMgbWF5LCBob3dldmVyLCBub3Qg YmU8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgYXZhaWxhYmxlIGluIGV4aXN0aW5nIHByb3RvY29scyBh bmQgZm9yIHRob3NlIGNhc2VzIG5ldzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBmdW5jdGlvbmFsaXR5 IGhhcyB0byBiZSBzdGFuZGFyZGl6ZWQuIFRodXMsIGV4aXN0aW5nIHdvcmsgY2FuIGJlPGJyPiZn dDsgJmd0OyZndDsmZ3Q7IGxldmVyYWdlZCBhbmQgdGhlIGdyb3VwIGJlbmVmaXRzIGZyb20gYXZh aWxhYmxlIHNlY3VyaXR5IGFuYWx5c2lzLDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRh dGlvbiwgYW5kIGRlcGxveW1lbnQgZXhwZXJpZW5jZS4gTW9yZW92ZXIsIGEgc3RhbmRhcmRpemVk PGJyPiZndDsgJmd0OyZndDsmZ3Q7IHNvbHV0aW9uIGZvciBmZWRlcmF0ZWQgYXV0aGVudGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24gd2lsbCBoZWxwIHRvPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHN0 aW11bGF0ZSB0aGUgZGVwbG95bWVudCBvZiBJb1QgZGV2aWNlcyBvZmZlcmluZyBpbmNyZWFzZWQg c2VjdXJpdHkuPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7IE9uY2Ug cHJvZ3Jlc3MgaW4gaWRlbnRpZnlpbmcgc3VpdGFibGUgY2FuZGlkYXRlIHNvbHV0aW9ucyBoYXMg YmVlbjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBtYWRlIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdmVy aWZ5IHdoZXRoZXIgdGhlIHNhbWUgbWVjaGFuaXNtIGFyZTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBh bHNvIGFwcGxpY2FibGUgYmV5b25kIHRoZSB1c2Ugb2YgQ29BUCBhbmQgRFRMUy4gSW4gcGFydGlj dWxhciwgdGhlPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGFiaWxpdHkgdG8gdXNlIHRoZSBkZXZlbG9w ZWQgc29sdXRpb24gb3ZlciBIVFRQIGFuZCBUTFMgd2lsbCBiZTxicj4mZ3Q7IGludmVzdGlnYXRl ZC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgRnVydGhlcm1vcmUsIHRvIGd1YXJhbnRlZSBzbW9vdGgg dHJhbnNpdGlvbiB0aGUgaW50ZWdyYXRpb24gd2l0aDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBleGlz dGluZyBkZXBsb3ltZW50IHdpbGwgYmUgc3R1ZGllZC4gVGhpcyBwYXJ0aWN1bGFybHkgY29uY2Vy bnMgdGhlPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHVzZSBvZiBwcm90b2NvbCB0cmFuc2xhdGlvbiBw cm94aWVzLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUbyBiZSBz dWNjZXNzZnVsIHRoaXMgd29ya2luZyBncm91cCByZXF1aXJlcyBleHBlcnRpc2UgaW4gc2VjdXJp dHksPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHByaXZhY3ksIGFuZCBhIGdvb2QgdW5kZXJzdGFuZGlu ZyBvZiB1c2FiaWxpdHkgaW4gdGhlIGNvbnN0cmFpbmVkPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGVu dmlyb25tZW50IHNwYWNlLiBUaGlzIHdvcmsgZG9lcyBub3QgbWFrZSB0aGUgYXNzdW1wdGlvbiB0 aGF0IHRoZTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBwYXJ0eSBvZmZlcmluZyBhcHBsaWNhdGlvbiBs YXllciBzZXJ2aWNlcyBpcyBhbHdheXMgdGhlIHNhbWUgcGFydHk8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgb2ZmZXJpbmcgbmV0d29yayBhY2Nlc3Mgc2VydmljZXMuPGJyPiZndDsgJmd0OyZndDsmZ3Q7 PGJyPiZndDsgJmd0OyZndDsmZ3Q7IFRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5n IHRhc2tzIChpbiB0aGlzIG9yZGVyKTo8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgMSkgVGhlIHdvcmtpbmcgZ3JvdXAgV2lraSBwYWdlcyB3aWxsIGJlIHVzZWQgdG8g ZG9jdW1lbnQgdXNlIGNhc2VzLDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyByZXF1aXJlbWVudHMsIGFu ZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEuIFRoaXMgd29yayB3aWxsIGd1aWRlIHRoZTxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyBpZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNo YW5pc21zLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyAyKSBTZWxl Y3Rpb24gb2YgYW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9y PGJyPiZndDsgJmd0OyZndDsmZ3Q7IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48YnI+Jmd0OyAm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgMykgRXZhbHVhdGlvbiBvZiB0aGUgY2Fu ZGlkYXRlIHNvbHV0aW9uIGZvciB1c2Ugd2l0aCBIVFRQL1RMUyBhbmQ8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgcHJveHkgZGVwbG95bWVudHMuPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsmZ3Q7IC0tLS0tPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7 IENpYW88YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSGFubmVzPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJy PiZndDsgJmd0OyZndDsmZ3Q7ICZsdDtzaWduYXR1cmUuYXNjJmd0O19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0OyZndDsmZ3Q7IEFjZSBt YWlsaW5nIGxpc3Q8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgQWNlQGlldGYub3JnPGJyPiZndDsgJmd0 OyZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPGJyPiZn dDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBaYWNoIFNoZWxieTxicj4mZ3Q7ICZndDsmZ3Q7 IERpcmVjdG9yIG9mIFRlY2hub2xvZ3k8YnI+Jmd0OyAmZ3Q7Jmd0OyBBUk0gSW50ZXJuZXQgb2Yg VGhpbmdzIEJVPGJyPiZndDsgJmd0OyZndDsgd3d3LmFybS5jb208YnI+Jmd0OyAmZ3Q7Jmd0OyBt b2JpbGU6ICsxICg0MDgpIDIwMy05NDM0PGJyPiZndDsgJmd0OyZndDsgU2t5cGU6IHpkc2hlbGJ5 PGJyPiZndDsgJmd0OyZndDsgTGlua2VkSW46IGZpLmxpbmtlZGluLmNvbS9pbi96YWNoc2hlbGJ5 Lzxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAtLSBJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzPGJyPiZndDsgJmd0OyZndDsgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlPGJyPiZndDsgJmd0OyZndDsgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dDxicj4mZ3Q7ICZndDsmZ3Q7IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvcjxicj4mZ3Q7ICZndDsmZ3Q7IHN0b3JlIG9y IGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uJm5ic3A7IFRoYW5rIHlvdS48YnI+ Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEFSTSBMaW1pdGVkLCBSZWdpc3RlcmVkIG9m ZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosPGJyPiZndDsgJmd0OyZn dDsgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzLCBDb21wYW55IE5vOiZuYnNwOyAy NTU3NTkwIEFSTSBIb2xkaW5ncyBwbGMsPGJyPiZndDsgJmd0OyZndDsgUmVnaXN0ZXJlZCBvZmZp Y2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRnZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGluPGJy PiZndDsgJmd0OyZndDsgRW5nbGFuZCAmYW1wOyBXYWxlcywgQ29tcGFueSBObzombmJzcDsgMjU0 ODc4Mjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyAmZ3Q7Jmd0OyBBY2UgbWFpbGlu ZyBsaXN0PGJyPiZndDsgJmd0OyZndDsgQWNlQGlldGYub3JnPGJyPiZndDsgJmd0OyZndDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4mZ3Q7ICZndDsgQWNlIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgQWNlQGlldGYub3JnPGJy PiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTxicj4m Z3Q7ICZndDs8YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPkFjZSBtYWlsaW5nIGxpc3Q8YnI+QWNlQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPGJyPjwvYm9keT4= ----_com.android.email_2589254224154210-- From nobody Thu Mar 13 04:53:51 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719431A0971 for ; Thu, 13 Mar 2014 04:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q33pS8EwK-Io for ; Thu, 13 Mar 2014 04:53:46 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1319F1A09C3 for ; Thu, 13 Mar 2014 04:53:44 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-69-53219c415d7a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.60.04249.14C91235; Thu, 13 Mar 2014 12:53:38 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 12:53:36 +0100 From: =?windows-1254?Q?G=F6ran_Selander?= To: Hannes Tschofenig , Zach Shelby Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: AQHPPP7mXnQfvixAoUyrPsxr924da5rb+CuAgAE52ACAAKfFAIABEfSA Date: Thu, 13 Mar 2014 11:53:36 +0000 Message-ID: References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> <5320C480.9070609@gmx.net> In-Reply-To: <5320C480.9070609@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="windows-1254" Content-ID: <97BF4526A5BD384B9495DF22B3FD37BC@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7THMVgg58LWSy+f+thtli68x6r xaVrT9gdmD3WzFvD6LF40342jyVLfjIFMEdx2aSk5mSWpRbp2yVwZVx4uJOl4EFpxdlHT5kb GGcndDFyckgImEgs/XaaBcIWk7hwbz0biC0kcIRR4vnr8i5GLiB7CaPEt/Xb2EESbALuEnP2 rgRrEBEIkzh68ylYnFlAUWLdnD4mEFtYQEfi+twLQDUcQDW6ElPeukCYbhKLu1hBKlgEVCU2 tUOs5RUwl1hx7BYjxNoFjBL75oWD2JwC6hL7X09lBrEZgU77fmoNE8QmcYlbT+YzQZwsILFk z3lmCFtU4uXjf2DzRQX0JO49mgv1lpLEiu2XGCF6DSSOnLvJCmFbS7zqn8cMYWtLLFv4mhni HkGJkzOfsExglJiFZN0sJO2zkLTPQtI+C0n7AkbWVYwcxanFSbnpRgabGIHRd3DLb4sdjJf/ 2hxilOZgURLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD47Rpiff/KHqc92hkFy16 EjQvKlRhzrf1ouvz9zt/vCf091ZitENY+anTW5+znrvZtYnh91fePfK5s5Of6rFpu+avXTFh yoH1n75Ldvx5qpTFueJmUUz7td3bH9/WuBP4xTTk1EzeSFHZpzv8t/D/eaQ3k9V7v3O+Ulj4 7hXhYsUVQkI3T/23XqLEUpyRaKjFXFScCAAEJB16jAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/9M6kd6Db1MQ1ojTyiNxJ-QNwhHs Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 11:53:50 -0000 Hi Hannes, On 12/03/14 21:33, "Hannes Tschofenig" wrote: >Hi Goeran, > >I read a little bit between the lines of your mail and your main concern >is that you want to have an RFC published with your name on it. >A wiki page to document the requirements, and use cases is not good >enough for you. Interesting comment. Could someone please tell me if I=92ve broken some etiquette and deserve this treatment? =20 > >For you putting the draft text on a WG wiki feels like wasted time. >It is just a different form of documenting the work. > >My experience with use cases and requirements has not been great in the >IETF. In essence everyone quickly moves on once the group decides about >a particular solution direction. It then becomes very hard (for the >chairs) to finish the requirements work since nobody wants to review or >look at them anymore. OK - this is exactly my point: If you don=92t complete the use case and requirements work there is no traceability. I hear something similar on the list. > >Use cases and requirements are great during the initial part of the work >to get an understanding of the main challenges. > >Having said that I will leave it to the group to decide what they want >to do: RFCs or Wiki page > >Ciao >Hannes > >PS: Regarding your other comment about pointing to the constraint nature >to every item. We can do that if you feel better but the entire charter >page already says 10 times that we are focusing on the constraint space. >I am sure that the reader will have understood that when they get to the >task list. "your other comment about pointing to the constraint nature to every item= =94 ??? - I proposed to explicitly include the detailed problem statement we used in the BOF which is missing not only in the task description. - I proposed to specifically mention CoAP in access request (i.e. Interface II) in the task description, which seems to be consensus on the list. (Again, did I break some etiquette by explicitly proposing charter text? Was this =93nit picking=94? What went wrong?) G=F6ran > > >On 03/12/2014 10:32 AM, G=F6ran Selander wrote: >> Hannes, Zach and all, >>=20 >> I must say I don=B9t find the task list of the current charter very >>helpful: >>=20 >> =B3The working group has the following tasks (in this order): >>=20 >> 1) The working group Wiki pages will be used to document use cases, >> requirements, and protocol design criteria. This work will guide the >> identification of suitable protocol mechanisms. >>=20 >> 2) Selection of an authentication and authorization protocol for >> constrained environments. >>=20 >> 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy >> deployments.=B2 >>=20 >> This list does not give much more details about the work to be conducted >> than is already given by the title of the WG. To a person not having >> followed the discussion, the impression is that the work starts from >> scratch and there is no clear understanding of what to do. >>=20 >> If we can=B9t formulate the problem statement and first step towards a >> solution in some degree of detail before starting the WG that will >>anyway >> be the first task to do, so let=B9s try to get something in writing. >>=20 >>=20 >> "1) The working group Wiki pages will be used to document use cases, >> requirements, and protocol design criteria. This work will guide the >> identification of suitable protocol mechanisms." >>=20 >> This is hiding the fact that there has been 6 months of work on the use >> case and requirements draft (the first version of this draft was >>submitted >> to CoRE in IETF88), which no one has disagreed is setting the stage for >> this work. Look at parallel threads on this mailing list where people >>ask >> whether their particular security-for-IoT draft fits into ACE. The >>answer >> Hannes is giving is correctly: the scope of this work is what is >>outlined >> by the use case and requirements draft. I don=B9t mind using the Wiki as= a >> working tool but this does not give traceability a year later. And I >>don=B9t >> see the point if copying the use case document into a Wiki page - read >>the >> draft and provide your comments! >>=20 >> When it comes to protocol design criteria, I agree that more work is >> needed, for which the Wiki may be suitable. Nevertheless I insist on >> documenting the design criteria and its rationale since that provides a >> means for traceability. Make it a milestone to have a draft with >> assumptions and design criteria (you may include =B3architecture=B2 in = this >> document). This work is anyway a pre-requisite for coming to a solution, >> and once you have this content, the candidate solutions are much easier >> evaluated. >>=20 >> So, change 1) to state something like >>=20 >> "1=B9 ) >> a) complete the work on use case and requirements >> b) use Wiki pages for listing assumptions and protocol design criteria, >> document the result in a draft" >>=20 >> Proxy deployment aspects fits well into 1b) [more in separate upcoming >> mail] >>=20 >>=20 >> 2) Selection of an authentication and authorization protocol for >> constrained environments. >>=20 >> Here I=B9m missing among other things the specific problem statement. Th= e >> preliminary conclusions from the use case and requirements draft formed >> the basis for the problem statement as presented in the BOF: We lack a >> mechanism for dynamic and fine grained access control for constrained >> environments.=20 >>=20 >> The process here should be to: >> "2=B9) identify suitable protocol mechanisms and match candidate >> authentication and authorization protocols against requirements and >>design >> criteria, in particular addressing dynamic and fine grained access >>control >> suitable for CoAP resource access requests in constrained environments." >>=20 >>=20 >>=20 >> 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy >> deployments.=B2 >>=20 >>=20 >> As mentioned above, proxy deployments could be considered as part of >>1=B9b). >> In 2=B9) it is already stated that in particular we should consider CoAP >>on >> interface (II). As for use of other protocols besides CoAP that issue is >> orthogonal to this so I leave that out from this discussion. >>=20 >>=20 >>=20 >> G=F6ran >>=20 >>=20 >>=20 >>=20 >>=20 >> On 11/03/14 16:49, "Zach Shelby" wrote: >>=20 >>> Hannes, >>> >>> I am happy with this charter with one exception. The proxy item here >>> seems to be more of a distraction than anything else, and will probably >>> result in increased complexity. Was proxy support maybe just a >>> misunderstanding? Do we really see the need for a proxy in the middle >>>of >>> I or III? >>> >>> I think what we really want here is to make sure that e.g. even >>>through I >>> is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In >>>other >>> words, some interfaces can be constrained while others are not. I think >>> the charter already covers this fine. >>> >>> So my proposal would be to remove the mention of protocol translation >>> proxies. If we really see the need for this some day in the future, it >>> could be tackled then. >>> >>> Zach >>> >>> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig >>> wrote: >>> >>>> Hi all, >>>> >>>> I have taken the feedback from the meeting and the recent discussions >>>>on >>>> the mailing list and produced a new strawman proposal. >>>> >>>> The changes include: >>>> * Added the focus on DTLS/CoAP with an indication that we will check a >>>> candidate solution for suitability with HTTP/TLS. >>>> * Added text to indicate that we will also verify the suitability of >>>> the solution for use with protocol translation proxies. >>>> * Simplified the task list by removing solution specific items. >>>> * Merged several items on the task list (use cases, requirements, and >>>> protocol design guidelines). Followed the suggestion to use of a Wiki >>>> for capturing those. >>>> >>>> What do you think? >>>> >>>> ----- >>>> >>>> Draft Charter V0.5 - Authentication and Authorization for Constrained >>>> Environment (ACE) >>>> >>>> The IETF has recently developed protocols for use in environments >>>>where >>>> network nodes are limited in CPU, memory, and power. It was observed >>>> that Internet protocols can be applied to these constrained >>>> environments, often only requiring minor tweaking and profiling. In >>>> other cases, new protocols have been defined to address the specific >>>> requirements of constrained devices and networks. An example of such a >>>> protocol is the Constrained Application Protocol (CoAP). >>>> components >>>> As in other environments, authentication and authorization question >>>>also >>>> arise in environments with constrained nodes and networks. For >>>>example, >>>> a door lock has to authorize the person seeking access using a >>>>"digital >>>> key". Where are the authorization decisions stored? How does the >>>>digital >>>> key communicate with the lock? Does the lock interact with an >>>> authorization server to obtain authorization information? How can >>>>access >>>> be granted to other persons temporarily? How can access be revoked? >>>> These types of questions have been answered by existing protocols for >>>> use cases outside the constrained environment. But in constrained >>>> environment, additional requirements pose challenges for the use of >>>> various security protocols. >>>> >>>> The IETF has a long history in developing three party authentication >>>>and >>>> authorization protocols for distributed environments. Examples include >>>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>>> Authorization, and Accounting (AAA) infrastructure, and the Web >>>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>>> deployment on the Internet. Although they all aim to solve a similar >>>> goal, at an abstract level, they offer quite different functions and >>>> utilize different message exchanges. These differences are motivated >>>>by >>>> the main deployment use cases they were designed for. >>>> >>>> Requirements derived from use cases indicate the suitability of >>>>already >>>> existing work, such as OAuth, as a solution for constrained >>>> environments. These protocols were, however, not optimized for >>>> constrained environments. Additional requirements that need to be >>>>taken >>>> into account are the lack of a suitable user-interface for obtaining >>>>the >>>> consent of the user and the inability of embedded devices to contact >>>>an >>>> authorization server in real-time with every access request due to >>>> intermittent connectivity, etc. >>>> >>>> This working group therefore aims for a standardized solution for >>>> authentication and authorization to enable authorized access to >>>> resources in constrained environments. As a starting point, the >>>>working >>>> group will assume that access to resources offered by a resource >>>>server >>>> by a client devices takes place using CoAP and is protected by DTLS. >>>> Both resource server and client may be resource constraint. This >>>>access >>>> will be mediated by an authorization server, which does not suffer >>>>from >>>> the same resource limitations. >>>> >>>> Existing authentication and authorization protocols are used and >>>> re-applied for use with constrained devices, where applicable. This >>>> requires relevant specifications to be reviewed for suitability, >>>> selecting a subset of them, restricting the options within each of the >>>> specifications. Some functionalities may, however, not be available in >>>> existing protocols and for those cases new functionality has to be >>>> standardized. Thus, existing work can be leveraged and the group >>>> benefits from available security analysis, implementation, and >>>> deployment experience. Moreover, a standardized solution for federated >>>> authentication and authorization will help to stimulate the deployment >>>> of IoT devices offering increased security. >>>> >>>> Once progress in identifying suitable candidate solutions has been >>>>made >>>> the working group will verify whether the same mechanism are also >>>> applicable beyond the use of CoAP and DTLS. In particular, the ability >>>> to use the developed solution over HTTP and TLS will be investigated. >>>> Furthermore, to guarantee smooth transition the integration with >>>> existing deployment will be studied. This particularly concerns the >>>>use >>>> of protocol translation proxies. >>>> >>>> To be successful this working group requires expertise in security, >>>> privacy, and a good understanding of usability in the constrained >>>> environment space. This work does not make the assumption that the >>>>party >>>> offering application layer services is always the same party offering >>>> network access services. >>>> >>>> The working group has the following tasks (in this order): >>>> >>>> 1) The working group Wiki pages will be used to document use cases, >>>> requirements, and protocol design criteria. This work will guide the >>>> identification of suitable protocol mechanisms. >>>> >>>> 2) Selection of an authentication and authorization protocol for >>>> constrained environments. >>>> >>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and >>>>proxy >>>> deployments. >>>> >>>> ----- >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>> >>> Zach Shelby >>> Director of Technology >>> ARM Internet of Things BU >>> www.arm.com >>> mobile: +1 (408) 203-9434 >>> Skype: zdshelby >>> LinkedIn: fi.linkedin.com/in/zachshelby/ >>> >>> >>> -- IMPORTANT NOTICE: The contents of this email and any attachments are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose the >>> contents to any other person, use it for any purpose, or store or copy >>> the information in any medium. Thank you. >>> >>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>> Registered in England & Wales, Company No: 2557590 >>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>>9NJ, >>> Registered in England & Wales, Company No: 2548782 >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 > From nobody Thu Mar 13 05:28:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00F81A08E5 for ; Thu, 13 Mar 2014 05:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVEBAagxw0yF for ; Thu, 13 Mar 2014 05:28:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 27B3F1A0970 for ; Thu, 13 Mar 2014 05:28:06 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lj25i-1X0zaa2Xjq-00dJlp for ; Thu, 13 Mar 2014 13:27:58 +0100 Message-ID: <53210566.60100@gmx.net> Date: Thu, 13 Mar 2014 02:09:58 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q8pFHVhM1wxgaSU4L32o500mdpO1sat9u" X-Provags-ID: V03:K0:PIgL2O+5cCTU06OuD9a4uNwkZEwotzq8V9EuIbp00pbfOKwWnXR 1E3ttPKQBO0/MVcLmwkxJX7PAwWu+v6TFYxNHDrMcWLC9yRBSjq0JebM79HOjKiPxR2BaZi x4IZ9NvWV5pdztRb9eVWdmGYmrLrQZ014raPAxIP81uoWJSsk2Aik5ZIqL/rdCQmN7S9JUL nGTzSRm1dtcuRSMzIJJNA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/AKXE_VEqobse9DJRvnxI3rxOdNY Subject: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:28:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q8pFHVhM1wxgaSU4L32o500mdpO1sat9u Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Goeran raised a question about adding a milestone for a document that captures assumptions and design criteria. He contributed an initial version of such a document with https://tools.ietf.org/html/draft-seitz-ace-design-considerations-00 What does the rest of the group think about that idea? Would you be willing to review such a document? Would you be willing to contribute to such a document? Ciao Hannes --q8pFHVhM1wxgaSU4L32o500mdpO1sat9u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIQVmAAoJEGhJURNOOiAtv6MIAKfb02VSSqM8JOboySpGESzG /lbF7PhhLdlarUlv1T5ekK5njAPUiGklcT/SH2aLuvHVJKaJfxI/4JbYQo3MpUls wHNfumHdID2yNmSxI4XTyzraHRCzBIEjCS9zFwbKQXFXgevH2MuWSblpDej55CTN coVnaMOYoS82n10jWspZbTxhDXcT7S3PVu42NfUCV+hZ/jnQpQ04Xom+ek6qpJrz +rSaibXD/PXBrRj7C9Kp2MLnGYg05RO9hb/B8Tm+5k4i5GvnvtrY6/aLzAtkNtO9 Z7wToYXR/4n5R3KUF/ABZlTYbuR9h1xTZRa3YBNEzx4Io+sceDP8fhJvjLbOWbE= =fBYg -----END PGP SIGNATURE----- --q8pFHVhM1wxgaSU4L32o500mdpO1sat9u-- From nobody Thu Mar 13 05:40:14 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DE41A0920 for ; Thu, 13 Mar 2014 05:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNy9rnQTrv2h for ; Thu, 13 Mar 2014 05:40:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 303FC1A081D for ; Thu, 13 Mar 2014 05:40:06 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ls8Qd-1X9Y7J32jP-013wHv; Thu, 13 Mar 2014 13:39:55 +0100 Message-ID: <5321082E.6040502@gmx.net> Date: Thu, 13 Mar 2014 02:21:50 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?windows-1254?Q?G=F6ran_Selander?= , Zach Shelby References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> <5320C480.9070609@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l1QnbA3Les00RHoR25OehoPt7MOFfTHBT" X-Provags-ID: V03:K0:vcs+Qi9S/A0OxW1vRswgrBCzLbNYi6jEKS+Nb4raPsG8x57yOF2 OHbZRJN2nUw6j0TkdKUOBruEtXpH0WHAGtQADehf5sNk6TETbNbum0QJxkqlSjcJq3/NanJ 4MWaJpGFEsEFbqqITHDsziJWU/bms81+M+kvudCow4hHPoNl6RUzwsDbVd+6coKhUhZ42h4 Zw3WZQt1F4vt/g4oQFPXA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/4RLlXa0qtIMyODPghGs8jIIhAYg Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:40:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l1QnbA3Les00RHoR25OehoPt7MOFfTHBT Content-Type: text/plain; charset=windows-1254 Content-Transfer-Encoding: quoted-printable Hi Goeran, sorry if I was a bit too direct and went straight down to the meat of your comment. Regarding the "traceability" note that requirements have never been a sort of "contract". Whenever there are reasons to violate the requirements then this has been done. For example, the group may gain some new insight during the solution work. But as I said, I listen to the group when it comes to this issue. There is, however, an interesting aspect to your remark in your email below. Are you suggesting that we should sequence the work meaning that solution work should only start after the use cases are finished? That has advantages and disadvantages but it certainly has an impact on the milestones. You seem to be saying "yes, they should be sequenced" and I also see Margaret=92s mail to the list saying "no". Regarding to the charter I will post a mail to the list and hopefully it meets your needs. Ciao Hannes On 03/13/2014 12:53 PM, G=F6ran Selander wrote: > Hi Hannes, >=20 > On 12/03/14 21:33, "Hannes Tschofenig" wrot= e: >=20 >> Hi Goeran, >> >> I read a little bit between the lines of your mail and your main conce= rn >> is that you want to have an RFC published with your name on it. >> A wiki page to document the requirements, and use cases is not good >> enough for you. >=20 > Interesting comment. Could someone please tell me if I=92ve broken some= > etiquette and deserve this treatment? > =20 >=20 >> >> For you putting the draft text on a WG wiki feels like wasted time. >> It is just a different form of documenting the work. >> >> My experience with use cases and requirements has not been great in th= e >> IETF. In essence everyone quickly moves on once the group decides abou= t >> a particular solution direction. It then becomes very hard (for the >> chairs) to finish the requirements work since nobody wants to review o= r >> look at them anymore. >=20 > OK - this is exactly my point: If you don=92t complete the use case and= > requirements work there is no traceability. I hear something similar on= > the list. >=20 >> >> Use cases and requirements are great during the initial part of the wo= rk >> to get an understanding of the main challenges. >> >> Having said that I will leave it to the group to decide what they want= >> to do: RFCs or Wiki page >> >> Ciao >> Hannes >> >> PS: Regarding your other comment about pointing to the constraint natu= re >> to every item. We can do that if you feel better but the entire charte= r >> page already says 10 times that we are focusing on the constraint spac= e. >> I am sure that the reader will have understood that when they get to t= he >> task list. >=20 >=20 > "your other comment about pointing to the constraint nature to every it= em=94 > ??? >=20 >=20 > - I proposed to explicitly include the detailed problem statement we us= ed > in the BOF which is missing not only in the task description. >=20 > - I proposed to specifically mention CoAP in access request (i.e. > Interface II) in the task description, which seems to be consensus on t= he > list. >=20 > (Again, did I break some etiquette by explicitly proposing charter text= ? > Was this =93nit picking=94? What went wrong?) >=20 >=20 > G=F6ran >=20 >=20 >> >> >> On 03/12/2014 10:32 AM, G=F6ran Selander wrote: >>> Hannes, Zach and all, >>> >>> I must say I don=B9t find the task list of the current charter very >>> helpful: >>> >>> =B3The working group has the following tasks (in this order): >>> >>> 1) The working group Wiki pages will be used to document use cases, >>> requirements, and protocol design criteria. This work will guide the >>> identification of suitable protocol mechanisms. >>> >>> 2) Selection of an authentication and authorization protocol for >>> constrained environments. >>> >>> 3) Evaluation of the candidate solution for use with HTTP/TLS and pro= xy >>> deployments.=B2 >>> >>> This list does not give much more details about the work to be conduc= ted >>> than is already given by the title of the WG. To a person not having >>> followed the discussion, the impression is that the work starts from >>> scratch and there is no clear understanding of what to do. >>> >>> If we can=B9t formulate the problem statement and first step towards = a >>> solution in some degree of detail before starting the WG that will >>> anyway >>> be the first task to do, so let=B9s try to get something in writing. >>> >>> >>> "1) The working group Wiki pages will be used to document use cases, >>> requirements, and protocol design criteria. This work will guide the >>> identification of suitable protocol mechanisms." >>> >>> This is hiding the fact that there has been 6 months of work on the u= se >>> case and requirements draft (the first version of this draft was >>> submitted >>> to CoRE in IETF88), which no one has disagreed is setting the stage f= or >>> this work. Look at parallel threads on this mailing list where people= >>> ask >>> whether their particular security-for-IoT draft fits into ACE. The >>> answer >>> Hannes is giving is correctly: the scope of this work is what is >>> outlined >>> by the use case and requirements draft. I don=B9t mind using the Wiki= as a >>> working tool but this does not give traceability a year later. And I >>> don=B9t >>> see the point if copying the use case document into a Wiki page - rea= d >>> the >>> draft and provide your comments! >>> >>> When it comes to protocol design criteria, I agree that more work is >>> needed, for which the Wiki may be suitable. Nevertheless I insist on >>> documenting the design criteria and its rationale since that provides= a >>> means for traceability. Make it a milestone to have a draft with >>> assumptions and design criteria (you may include =B3architecture=B2 = in this >>> document). This work is anyway a pre-requisite for coming to a soluti= on, >>> and once you have this content, the candidate solutions are much easi= er >>> evaluated. >>> >>> So, change 1) to state something like >>> >>> "1=B9 ) >>> a) complete the work on use case and requirements >>> b) use Wiki pages for listing assumptions and protocol design criteri= a, >>> document the result in a draft" >>> >>> Proxy deployment aspects fits well into 1b) [more in separate upcomi= ng >>> mail] >>> >>> >>> 2) Selection of an authentication and authorization protocol for >>> constrained environments. >>> >>> Here I=B9m missing among other things the specific problem statement.= The >>> preliminary conclusions from the use case and requirements draft form= ed >>> the basis for the problem statement as presented in the BOF: We lack = a >>> mechanism for dynamic and fine grained access control for constrained= >>> environments.=20 >>> >>> The process here should be to: >>> "2=B9) identify suitable protocol mechanisms and match candidate >>> authentication and authorization protocols against requirements and >>> design >>> criteria, in particular addressing dynamic and fine grained access >>> control >>> suitable for CoAP resource access requests in constrained environment= s." >>> >>> >>> >>> 3) Evaluation of the candidate solution for use with HTTP/TLS and pro= xy >>> deployments.=B2 >>> >>> >>> As mentioned above, proxy deployments could be considered as part of >>> 1=B9b). >>> In 2=B9) it is already stated that in particular we should consider C= oAP >>> on >>> interface (II). As for use of other protocols besides CoAP that issue= is >>> orthogonal to this so I leave that out from this discussion. >>> >>> >>> >>> G=F6ran >>> >>> >>> >>> >>> >>> On 11/03/14 16:49, "Zach Shelby" wrote: >>> >>>> Hannes, >>>> >>>> I am happy with this charter with one exception. The proxy item here= >>>> seems to be more of a distraction than anything else, and will proba= bly >>>> result in increased complexity. Was proxy support maybe just a >>>> misunderstanding? Do we really see the need for a proxy in the middl= e >>>> of >>>> I or III? >>>> >>>> I think what we really want here is to make sure that e.g. even >>>> through I >>>> is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In >>>> other >>>> words, some interfaces can be constrained while others are not. I th= ink >>>> the charter already covers this fine. >>>> >>>> So my proposal would be to remove the mention of protocol translatio= n >>>> proxies. If we really see the need for this some day in the future, = it >>>> could be tackled then. >>>> >>>> Zach >>>> >>>> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I have taken the feedback from the meeting and the recent discussio= ns >>>>> on >>>>> the mailing list and produced a new strawman proposal. >>>>> >>>>> The changes include: >>>>> * Added the focus on DTLS/CoAP with an indication that we will chec= k a >>>>> candidate solution for suitability with HTTP/TLS. >>>>> * Added text to indicate that we will also verify the suitability o= f >>>>> the solution for use with protocol translation proxies. >>>>> * Simplified the task list by removing solution specific items. >>>>> * Merged several items on the task list (use cases, requirements, a= nd >>>>> protocol design guidelines). Followed the suggestion to use of a Wi= ki >>>>> for capturing those. >>>>> >>>>> What do you think? >>>>> >>>>> ----- >>>>> >>>>> Draft Charter V0.5 - Authentication and Authorization for Constrain= ed >>>>> Environment (ACE) >>>>> >>>>> The IETF has recently developed protocols for use in environments >>>>> where >>>>> network nodes are limited in CPU, memory, and power. It was observe= d >>>>> that Internet protocols can be applied to these constrained >>>>> environments, often only requiring minor tweaking and profiling. In= >>>>> other cases, new protocols have been defined to address the specifi= c >>>>> requirements of constrained devices and networks. An example of suc= h a >>>>> protocol is the Constrained Application Protocol (CoAP). >>>>> components >>>>> As in other environments, authentication and authorization question= >>>>> also >>>>> arise in environments with constrained nodes and networks. For >>>>> example, >>>>> a door lock has to authorize the person seeking access using a >>>>> "digital >>>>> key". Where are the authorization decisions stored? How does the >>>>> digital >>>>> key communicate with the lock? Does the lock interact with an >>>>> authorization server to obtain authorization information? How can >>>>> access >>>>> be granted to other persons temporarily? How can access be revoked?= >>>>> These types of questions have been answered by existing protocols f= or >>>>> use cases outside the constrained environment. But in constrained >>>>> environment, additional requirements pose challenges for the use of= >>>>> various security protocols. >>>>> >>>>> The IETF has a long history in developing three party authenticatio= n >>>>> and >>>>> authorization protocols for distributed environments. Examples incl= ude >>>>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>>>> Authorization, and Accounting (AAA) infrastructure, and the Web >>>>> Authorization Protocol (OAuth). All these protocols enjoy widesprea= d >>>>> deployment on the Internet. Although they all aim to solve a simila= r >>>>> goal, at an abstract level, they offer quite different functions an= d >>>>> utilize different message exchanges. These differences are motivate= d >>>>> by >>>>> the main deployment use cases they were designed for. >>>>> >>>>> Requirements derived from use cases indicate the suitability of >>>>> already >>>>> existing work, such as OAuth, as a solution for constrained >>>>> environments. These protocols were, however, not optimized for >>>>> constrained environments. Additional requirements that need to be >>>>> taken >>>>> into account are the lack of a suitable user-interface for obtainin= g >>>>> the >>>>> consent of the user and the inability of embedded devices to contac= t >>>>> an >>>>> authorization server in real-time with every access request due to >>>>> intermittent connectivity, etc. >>>>> >>>>> This working group therefore aims for a standardized solution for >>>>> authentication and authorization to enable authorized access to >>>>> resources in constrained environments. As a starting point, the >>>>> working >>>>> group will assume that access to resources offered by a resource >>>>> server >>>>> by a client devices takes place using CoAP and is protected by DTLS= =2E >>>>> Both resource server and client may be resource constraint. This >>>>> access >>>>> will be mediated by an authorization server, which does not suffer >>>>> from >>>>> the same resource limitations. >>>>> >>>>> Existing authentication and authorization protocols are used and >>>>> re-applied for use with constrained devices, where applicable. This= >>>>> requires relevant specifications to be reviewed for suitability, >>>>> selecting a subset of them, restricting the options within each of = the >>>>> specifications. Some functionalities may, however, not be available= in >>>>> existing protocols and for those cases new functionality has to be >>>>> standardized. Thus, existing work can be leveraged and the group >>>>> benefits from available security analysis, implementation, and >>>>> deployment experience. Moreover, a standardized solution for federa= ted >>>>> authentication and authorization will help to stimulate the deploym= ent >>>>> of IoT devices offering increased security. >>>>> >>>>> Once progress in identifying suitable candidate solutions has been >>>>> made >>>>> the working group will verify whether the same mechanism are also >>>>> applicable beyond the use of CoAP and DTLS. In particular, the abil= ity >>>>> to use the developed solution over HTTP and TLS will be investigate= d. >>>>> Furthermore, to guarantee smooth transition the integration with >>>>> existing deployment will be studied. This particularly concerns the= >>>>> use >>>>> of protocol translation proxies. >>>>> >>>>> To be successful this working group requires expertise in security,= >>>>> privacy, and a good understanding of usability in the constrained >>>>> environment space. This work does not make the assumption that the >>>>> party >>>>> offering application layer services is always the same party offeri= ng >>>>> network access services. >>>>> >>>>> The working group has the following tasks (in this order): >>>>> >>>>> 1) The working group Wiki pages will be used to document use cases,= >>>>> requirements, and protocol design criteria. This work will guide th= e >>>>> identification of suitable protocol mechanisms. >>>>> >>>>> 2) Selection of an authentication and authorization protocol for >>>>> constrained environments. >>>>> >>>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and >>>>> proxy >>>>> deployments. >>>>> >>>>> ----- >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>>> Zach Shelby >>>> Director of Technology >>>> ARM Internet of Things BU >>>> www.arm.com >>>> mobile: +1 (408) 203-9434 >>>> Skype: zdshelby >>>> LinkedIn: fi.linkedin.com/in/zachshelby/ >>>> >>>> >>>> -- IMPORTANT NOTICE: The contents of this email and any attachments = are >>>> confidential and may also be privileged. If you are not the intended= >>>> recipient, please notify the sender immediately and do not disclose = the >>>> contents to any other person, use it for any purpose, or store or co= py >>>> the information in any medium. Thank you. >>>> >>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,= >>>> Registered in England & Wales, Company No: 2557590 >>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1= >>>> 9NJ, >>>> Registered in England & Wales, Company No: 2548782 >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --l1QnbA3Les00RHoR25OehoPt7MOFfTHBT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIQguAAoJEGhJURNOOiAtJZsH/34m1sUiaCwxp3jQQylKaM8+ f7QJyO7QXbIayInHrbIAfnwFD+TrHQdoXmvD34678iOUgR46NzLxvqBlbw2kblY8 pie09I7kzN3bePnUt+ASvEmn1hFshSkWsfs7UwN/CPSa67NXNVAx2XovNyoDz035 SeJmIyjyqI6MEAIZJZOBsRpcnNlY3HNqwc3UfzTxiShdxSgnOeabXfx+MbcFOOpg YWgWweh78uMu3fVDv7cXXhtbAM5WT+WaaLindp7E1SYGp7/iZ/eJoQJqJvQ8qFSk lPLef5Kohe3+ypwkvkGobjRjWD4N6HDwwz+F+GIv6qn+UdUBGSseH1CoPXLrDBE= =0uIO -----END PGP SIGNATURE----- --l1QnbA3Les00RHoR25OehoPt7MOFfTHBT-- From nobody Thu Mar 13 05:43:23 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6034D1A081D for ; Thu, 13 Mar 2014 05:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8DFdKYM2WuZ for ; Thu, 13 Mar 2014 05:43:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 478E81A07D9 for ; Thu, 13 Mar 2014 05:43:19 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LcnRD-1Wpfkt0U4t-00k3w3 for ; Thu, 13 Mar 2014 13:43:12 +0100 Message-ID: <532108F4.10007@gmx.net> Date: Thu, 13 Mar 2014 02:25:08 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k9L84PH6U9nFo7Lg4ebq9C75S3XT3gJxp" X-Provags-ID: V03:K0:qpBEu/BDxxWZ0L4zCrYS/xlv2eriljIrZnrXlMcVhFD8OoVorpM 03VmIKLoz3YWa/0luhyWC9CjrERary7ikjTp2B1DOl4p3Eu53hcF8GHRiVUMc9aBRkIwIQM mmECaiMOVn9VCcr+EMI5BI5721XCkpwvq7e3MMu75Y6FR0b+nVYO3YMM74EFHCww0db+ajY MF02EZV6U72+vFxbIx4nA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/yQhpmEd04IzMQBhSPfidWWffG64 Subject: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:43:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k9L84PH6U9nFo7Lg4ebq9C75S3XT3gJxp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --> Here is an update based on comments from Goeran. Draft Charter V0.6 - Authentication and Authorization for Constrained Environment (ACE) The IETF has recently developed protocols for use in environments where network nodes are limited in CPU, memory, and power. It was observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained devices and networks. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization question also arise in environments with constrained nodes and networks. For example, a door lock has to authorize the person seeking access using a "digital key". Where are the authorization decisions stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be granted to other persons temporarily? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside the constrained environment. But in constrained environment, additional requirements pose challenges for the use of various security protocols. In particular, the need for a dynamic and fine grained access control mechanism whereby clients and/or resource servers suffer from constraints arises. The IETF has a long history in developing three party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization, and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences are motivated by the main deployment use cases they were designed for. Requirements derived from use cases indicate the suitability of already existing work, such as OAuth, as a solution for constrained environments. These protocols were, however, not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface for obtaining the consent of the user and the inability of embedded devices to contact an authorization server in real-time with every access request due to intermittent connectivity, etc. This working group therefore aims for a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments. As a starting point, the working group will assume that access to resources offered by a resource server by a client devices takes place using CoAP and is protected by DTLS. Both resource server and client may be resource constraint. This access will be mediated by an authorization server, which does not suffer from the same resource limitations. Existing authentication and authorization protocols are used and re-applied for use with constrained devices, where applicable. This requires relevant specifications to be reviewed for suitability, selecting a subset of them, restricting the options within each of the specifications. Some functionalities may, however, not be available in existing protocols and for those cases new functionality has to be standardized. Thus, existing work can be leveraged and the group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of IoT devices offering increased security. Once progress in identifying suitable candidate solutions has been made the working group will verify whether the same mechanism are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Furthermore, to guarantee smooth transition the integration with existing deployment will be studied. This particularly concerns the use of protocol translation proxies. To be successful this working group requires expertise in security, privacy, and a good understanding of usability in the constrained environment space. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. The working group has the following tasks (in this order): 1) Use cases, requirements, and design criteria. [[Details pending mailing list discussion.]] This work will guide the identification of suitable protocol mechanisms. 2) Selection of an authentication and authorization protocol for constrained environments. 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy deployments. [[Details pending mailing list discussion.]] --k9L84PH6U9nFo7Lg4ebq9C75S3XT3gJxp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIQj0AAoJEGhJURNOOiAts0gH/igrg0Jruq44B+JKDNeYhApj diRFCabAX57M9YYtZbnABM3zv81qNnPT39wP8fRqCeqEnvZ5wncUWhrGtw0Qv+Hb Ee3dcInQR/uockxeGvolFRVkSUcK9nfAZh1TNzj+o/ogxxcCgygxeuN7EcwA0Lnt yaXsdAumJjzoEf7t0Bn78B6fOHrBaBo3rijVKPT/83tVXqWShFuZgo+n56f+Y8ym psIqtmgqTMEAyiRhRoojt/hwjiiS+ljRWkjwCkDXEOMNvwh9wyfpmSFubUatATir wNjkShTAOW4U6GkcycPG5Z1VglfYu13lqRWSzrYdqRVWd5M2NIEvgYaXrGXbRdE= =bWeN -----END PGP SIGNATURE----- --k9L84PH6U9nFo7Lg4ebq9C75S3XT3gJxp-- From nobody Thu Mar 13 05:48:32 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327F01A07FA for ; Thu, 13 Mar 2014 05:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7iozGGwXc_3 for ; Thu, 13 Mar 2014 05:48:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id EAD5A1A07B7 for ; Thu, 13 Mar 2014 05:48:27 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lmazv-1WxPwV3g3v-00aHQq for ; Thu, 13 Mar 2014 13:48:21 +0100 Message-ID: <53210A20.6090709@gmx.net> Date: Thu, 13 Mar 2014 02:30:08 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="of6xHeo143CoAeCdeLrWvvs9QKtxaSEOM" X-Provags-ID: V03:K0:FL1ISsSVwArYKm0ByyKnw9tGojkq3hfWNst8GhTQqbnIkEv21xR nn33P40mB90SH0MT34sQd1IjxFC1RBCO7a8C1pvGScOX0KTf8TNQjHQWr7tybeHYHup+OoO knPYOCsBItILw8QdQ/5e7CPMQCjF40sx8bz6XbxQcwYfki7llD8nE44213OvV6Kf3rh88B+ YmwesDh9pkqoiTwO/ewCA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/dzJ5d5KxuVDaOpwxBtbDHeecYBo Subject: [Ace] When to deal with proxies? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:48:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --of6xHeo143CoAeCdeLrWvvs9QKtxaSEOM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, Goeran raised a question in the charter discussion about when to investigate suitability of the solution regarding proxies. With version 0.5 of the charter I suggested to explore the proxy issues* after a candidate solution had been selected. He suggested, however, to deal with proxies already during as part of the requirements/use case/design considerations phase. What would you like to do? Ciao Hannes PS: We discussed various types of proxies on the list. Some proxies were protocol translation proxies that provided the ability to interface with other protocols (e.g., HTTP) and deployed infrastructure (some backend authentication/authorization infrastructure) and yet other proxies were part of the CoAP protocol. --of6xHeo143CoAeCdeLrWvvs9QKtxaSEOM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIQogAAoJEGhJURNOOiAt978H/ilbAd5uAUKRm4pQ7HvQVNHP iw6AQRiaQk5L/oIcY+3aAc2M5PfupeazHSWKIeVLNW7qYW6UDGXRj7BTyounBZWR SsSv6fSC3pN+EbkpxyrTd94wm5q9zvptGgkgtCpHIpousJnjQutbrjjQ5wHnfGGa 5MXQ2EM+il5WQggl2ZbQcHVlhdBwLQDeUlTxZbQzvllwN7eXhnC4lHLm9DRNG6AD MQ6Djl7XhDMDHkjVwQQyTThpkMhhOZkoqLoVf2yAHT6bU9noV6yJ/zVatx9qZyjD g9cyZkTePXi+Y/nI+y/fGI4PR8niCXCKO8NgU9sElPphJunzcJ81C/rwGtwMNuw= =EzXh -----END PGP SIGNATURE----- --of6xHeo143CoAeCdeLrWvvs9QKtxaSEOM-- From nobody Thu Mar 13 05:56:02 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52E61A07CD for ; Thu, 13 Mar 2014 05:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4yPGeXlTuuE for ; Thu, 13 Mar 2014 05:55:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 35F381A07C5 for ; Thu, 13 Mar 2014 05:55:59 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjZn2-1WzKjk21lo-00bfNi; Thu, 13 Mar 2014 13:55:48 +0100 Message-ID: <53210BE1.5070702@gmx.net> Date: Thu, 13 Mar 2014 02:37:37 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Margaret Wasserman , Likepeng , =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Zach Shelby References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> In-Reply-To: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ku6xhb64uT2FvEpIcEE3HX0pqlcKtrSqM" X-Provags-ID: V03:K0:DZX+uGcyD+EcEezKvUTYWu3vUmK8QJ61Ef8W6KbdpNIFbwEw04k YcmDgRhn6Sn5imqZ0CfsYZknnpQT+Tl70+XMa11GYoc2xn8cOhwr8WqWpWILLKi3AhMvhDe /u1W9FkiN4Xsj+bkemFbzxJcS8xKB5uAgNhAQO7SHnjOKDagLMk0DgBvUULRcySQnCca26r xJaDrc9wj+xCVXJZyseRw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/UfUgfmSguP4bjreNGOKJynmMRpw Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:56:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ku6xhb64uT2FvEpIcEE3HX0pqlcKtrSqM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/13/2014 11:55 AM, Margaret Wasserman wrote: > I do not think the other work of the group should be gated on the > requirements, though, as I think that it makes sense to explore how > existing technologies could or couldn't meet the requirements to insure= > that our requirements are reality-based. Thanks for your feedback, Margaret. Btw, as part of the current charter we are not planning to capture what existing technologies could or couldn't meet the requirements. Would you see that as being useful? Ciao Hannes --Ku6xhb64uT2FvEpIcEE3HX0pqlcKtrSqM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIQvhAAoJEGhJURNOOiAtBNUIAIgTEYkRorjv5iYvv4PEMFEy jrliGI/nzQufmfKujReQ0zjFKCY6axJQk4dcLOhr0UbBc+HFjAsoziyRbuM/N2wz iqmZVQQhQID8VY38ZvIqAucury45uqYWMWiUbNzeO3MHo0eGGycsiN3bNCxAQwRc abmwMcKaQySOhfHP2TYZUuIgoW3XkkO6CbEi0mKh7dq+cn2qbv8DoQF8iSaEr76K Edbh35Wxg9bnjvuTAOlLNAseSYajfRLnkVl/NKD8ACvm1DtCXFoRVdfmjxNeV0bM CNPxnD5SadlBvFV4vXcwxdHBr5HuNWOjLuBAHN3GrIY5ns8t/no1fn2ayMKMYr0= =dTu/ -----END PGP SIGNATURE----- --Ku6xhb64uT2FvEpIcEE3HX0pqlcKtrSqM-- From nobody Thu Mar 13 06:28:46 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97381A0963 for ; Thu, 13 Mar 2014 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV-qSveAohLY for ; Thu, 13 Mar 2014 06:28:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 320D81A095E for ; Thu, 13 Mar 2014 06:28:41 -0700 (PDT) Received: from [192.168.131.135] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LcWSI-1Wpy7z26Za-00jmtJ for ; Thu, 13 Mar 2014 14:28:33 +0100 Message-ID: <5321B255.3070801@gmx.net> Date: Thu, 13 Mar 2014 14:27:49 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6W7Ujk6KtD9f4b1KWvKRxNg7JB8uQth01" X-Provags-ID: V03:K0:pVCJ1uLArU4TeD8BiV3bEXdwyEU0KNWbzFwm5BNSaKpEJwmGcP5 1cV2xH0xmtvTRyuhxUXfhlftIzNVbjsnVFGPYJ444JIRg5rxPQuI6TBtoO2uLO4q9u6QPff T/cVDR3QdeHnZfsDcYmKyG96LdqX4FfkUu/QhKH/kcs3QJV4Sv/4vlzEoCLyLeM1aD6DjMc 53cOlAhhvTjrGBZ6TFvFg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/An_9RXec58zXZCqS6ISifJx4frs Subject: [Ace] Authorization server: a constrained device? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:28:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6W7Ujk6KtD9f4b1KWvKRxNg7JB8uQth01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, reading through Sam's email and various comments during the BOF I was wondering whether the group has a consensus to assume that the authorization is not a constrained device. In earlier discussions we said that the client and/or the resource server are constrained. Thoughts? Ciao Hannes --6W7Ujk6KtD9f4b1KWvKRxNg7JB8uQth01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIbJVAAoJEGhJURNOOiAtu4YH/1meWh0YmqcuTTpyBX0WaQcN 78j3OyDCpearfMmIFAcpFWfDz5dn9JKQkP8uphukHRqFJXrY2ehvoncmroSFFP89 HfbzIXm8HgQUdITUJa4D4w8bNtlYNZd1l8Jf38TfGe7EGxNffMxfvUazt8tl5Bgl dSa0x+Htzl1UQwo7y2u1c+apOz3V54OdSgFiuqik4q354gx6MtlXJi5DV11UuRo7 MEWMvEZyERjE8RaZmI1o4IPndmZjWLLQSUmCTmjhKTyUrnX11lVu1+Isp+us/OXY PmkLWwk/BjcGDL4MybRw7k4yFPXPrV24z010PJFZe2c3U0O+qp+ahkcoiwLeyEg= =9h+N -----END PGP SIGNATURE----- --6W7Ujk6KtD9f4b1KWvKRxNg7JB8uQth01-- From nobody Thu Mar 13 07:03:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B631A098C for ; Thu, 13 Mar 2014 07:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPKo1frZwFaC for ; Thu, 13 Mar 2014 07:02:41 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1741A096B for ; Thu, 13 Mar 2014 07:02:40 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-02-5321ba798f09 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F4.D4.04249.97AB1235; Thu, 13 Mar 2014 15:02:33 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 15:02:32 +0100 From: =?windows-1254?Q?G=F6ran_Selander?= To: Hannes Tschofenig , Zach Shelby Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: AQHPPP7mXnQfvixAoUyrPsxr924da5rb+CuAgAE52ACAAKfFAIABEfSA//8+ugCAAOVMgA== Date: Thu, 13 Mar 2014 14:02:32 +0000 Message-ID: References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> <5320C480.9070609@gmx.net> <5321082E.6040502@gmx.net> In-Reply-To: <5321082E.6040502@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="windows-1254" Content-ID: <088E6C36CCF08744BFB51183DBA316AF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+JvjW7lLsVggwc3lS2+f+thtli68x6r xaVrT9gdmD3WzFvD6LF40342jyVLfjIFMEdx2aSk5mSWpRbp2yVwZbRPu8RWsK6bseLN4XmM DYzTiroYOTkkBEwkJi9awgJhi0lcuLeerYuRi0NI4AijxOS+5YwQzhJGiZtz1rKCVLEJuEvM 2bsSrENEIEzi6M2n7CA2s4CixLo5fUwgtrCAjsT1uReAajiAanQlprx1gSnf0t4KNoZFQFVi +f6LbCAlvALmEgte5ICEhQReMkr8+OMAYnMKqEvsufuOEcRmBLrt+6k1TBCbxCVuPZnPBHGz gMSSPeeZIWxRiZeP/4GNFxXQk7j3aC7UX0oSK7ZfYoToNZA4cu4mK4RtLXH+xHMoW1ti2cLX YHN4BQQlTs58wjKBUWIWknWzkLTPQtI+C0n7LCTtCxhZVzFyFKcWJ+WmGxlsYgRG4MEtvy12 MF7+a3OIUZqDRUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjE+XfL9cmlb3d+H1 4LyI8s9yF5+X1ouHNZtzmXedDfYWnBVc8jsyg+/k0Xsimg+aMniq50uf9TlZ5/tZ5eDCOWr1 7avNnK5yHNozpzp60ltxlcN6Sy6/OT1fveaj0dmYX2Ftqjf67G3DonP6PMWumf08t1k8+6VM 16aCRiF9WZmnu+orL8dMVGIpzkg01GIuKk4EAP92FRuOAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1hPRjcYaWPiE4EnM8RnJR9aBaQU Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 14:02:44 -0000 Hi Hannes On 13/03/14 02:21, "Hannes Tschofenig" wrote: >Hi Goeran, > >sorry if I was a bit too direct and went straight down to the meat of >your comment. Well, I disagree with your interpretation of "the meat=94 of my comment, bu= t I think I=92ve made my point clear, so let=92s leave it at that. > >Regarding the "traceability" note that requirements have never been a >sort of "contract". Whenever there are reasons to violate the >requirements then this has been done. For example, the group may gain >some new insight during the solution work. > >But as I said, I listen to the group when it comes to this issue. > >There is, however, an interesting aspect to your remark in your email >below. Are you suggesting that we should sequence the work meaning that >solution work should only start after the use cases are finished? That >has advantages and disadvantages but it certainly has an impact on the >milestones. You seem to be saying "yes, they should be sequenced" and I >also see Margaret=92s mail to the list saying "no". I don=92t have a strong opinion here and certainly do not insist on a =93waterfall=94 design model. It could be fruitful to elaborate on differen= t requirements as long as you are aware of what requirements you break and what the consequences might be in terms of e.g. supported use cases or security. G=F6ran > >Regarding to the charter I will post a mail to the list and hopefully it >meets your needs. > >Ciao >Hannes > > > >On 03/13/2014 12:53 PM, G=F6ran Selander wrote: >> Hi Hannes, >>=20 >> On 12/03/14 21:33, "Hannes Tschofenig" >>wrote: >>=20 >>> Hi Goeran, >>> >>> I read a little bit between the lines of your mail and your main >>>concern >>> is that you want to have an RFC published with your name on it. >>> A wiki page to document the requirements, and use cases is not good >>> enough for you. >>=20 >> Interesting comment. Could someone please tell me if I=92ve broken some >> etiquette and deserve this treatment? >> =20 >>=20 >>> >>> For you putting the draft text on a WG wiki feels like wasted time. >>> It is just a different form of documenting the work. >>> >>> My experience with use cases and requirements has not been great in the >>> IETF. In essence everyone quickly moves on once the group decides about >>> a particular solution direction. It then becomes very hard (for the >>> chairs) to finish the requirements work since nobody wants to review or >>> look at them anymore. >>=20 >> OK - this is exactly my point: If you don=92t complete the use case and >> requirements work there is no traceability. I hear something similar on >> the list. >>=20 >>> >>> Use cases and requirements are great during the initial part of the >>>work >>> to get an understanding of the main challenges. >>> >>> Having said that I will leave it to the group to decide what they want >>> to do: RFCs or Wiki page >>> >>> Ciao >>> Hannes >>> >>> PS: Regarding your other comment about pointing to the constraint >>>nature >>> to every item. We can do that if you feel better but the entire charter >>> page already says 10 times that we are focusing on the constraint >>>space. >>> I am sure that the reader will have understood that when they get to >>>the >>> task list. >>=20 >>=20 >> "your other comment about pointing to the constraint nature to every >>item=94 >> ??? >>=20 >>=20 >> - I proposed to explicitly include the detailed problem statement we >>used >> in the BOF which is missing not only in the task description. >>=20 >> - I proposed to specifically mention CoAP in access request (i.e. >> Interface II) in the task description, which seems to be consensus on >>the >> list. >>=20 >> (Again, did I break some etiquette by explicitly proposing charter text? >> Was this =93nit picking=94? What went wrong?) >>=20 >>=20 >> G=F6ran >>=20 >>=20 >>> >>> >>> On 03/12/2014 10:32 AM, G=F6ran Selander wrote: >>>> Hannes, Zach and all, >>>> >>>> I must say I don=B9t find the task list of the current charter very >>>> helpful: >>>> >>>> =B3The working group has the following tasks (in this order): >>>> >>>> 1) The working group Wiki pages will be used to document use cases, >>>> requirements, and protocol design criteria. This work will guide the >>>> identification of suitable protocol mechanisms. >>>> >>>> 2) Selection of an authentication and authorization protocol for >>>> constrained environments. >>>> >>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and >>>>proxy >>>> deployments.=B2 >>>> >>>> This list does not give much more details about the work to be >>>>conducted >>>> than is already given by the title of the WG. To a person not having >>>> followed the discussion, the impression is that the work starts from >>>> scratch and there is no clear understanding of what to do. >>>> >>>> If we can=B9t formulate the problem statement and first step towards a >>>> solution in some degree of detail before starting the WG that will >>>> anyway >>>> be the first task to do, so let=B9s try to get something in writing. >>>> >>>> >>>> "1) The working group Wiki pages will be used to document use cases, >>>> requirements, and protocol design criteria. This work will guide the >>>> identification of suitable protocol mechanisms." >>>> >>>> This is hiding the fact that there has been 6 months of work on the >>>>use >>>> case and requirements draft (the first version of this draft was >>>> submitted >>>> to CoRE in IETF88), which no one has disagreed is setting the stage >>>>for >>>> this work. Look at parallel threads on this mailing list where people >>>> ask >>>> whether their particular security-for-IoT draft fits into ACE. The >>>> answer >>>> Hannes is giving is correctly: the scope of this work is what is >>>> outlined >>>> by the use case and requirements draft. I don=B9t mind using the Wiki >>>>as a >>>> working tool but this does not give traceability a year later. And I >>>> don=B9t >>>> see the point if copying the use case document into a Wiki page - read >>>> the >>>> draft and provide your comments! >>>> >>>> When it comes to protocol design criteria, I agree that more work is >>>> needed, for which the Wiki may be suitable. Nevertheless I insist on >>>> documenting the design criteria and its rationale since that provides >>>>a >>>> means for traceability. Make it a milestone to have a draft with >>>> assumptions and design criteria (you may include =B3architecture=B2 i= n >>>>this >>>> document). This work is anyway a pre-requisite for coming to a >>>>solution, >>>> and once you have this content, the candidate solutions are much >>>>easier >>>> evaluated. >>>> >>>> So, change 1) to state something like >>>> >>>> "1=B9 ) >>>> a) complete the work on use case and requirements >>>> b) use Wiki pages for listing assumptions and protocol design >>>>criteria, >>>> document the result in a draft" >>>> >>>> Proxy deployment aspects fits well into 1b) [more in separate >>>>upcoming >>>> mail] >>>> >>>> >>>> 2) Selection of an authentication and authorization protocol for >>>> constrained environments. >>>> >>>> Here I=B9m missing among other things the specific problem statement. >>>>The >>>> preliminary conclusions from the use case and requirements draft >>>>formed >>>> the basis for the problem statement as presented in the BOF: We lack a >>>> mechanism for dynamic and fine grained access control for constrained >>>> environments.=20 >>>> >>>> The process here should be to: >>>> "2=B9) identify suitable protocol mechanisms and match candidate >>>> authentication and authorization protocols against requirements and >>>> design >>>> criteria, in particular addressing dynamic and fine grained access >>>> control >>>> suitable for CoAP resource access requests in constrained >>>>environments." >>>> >>>> >>>> >>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and >>>>proxy >>>> deployments.=B2 >>>> >>>> >>>> As mentioned above, proxy deployments could be considered as part of >>>> 1=B9b). >>>> In 2=B9) it is already stated that in particular we should consider Co= AP >>>> on >>>> interface (II). As for use of other protocols besides CoAP that issue >>>>is >>>> orthogonal to this so I leave that out from this discussion. >>>> >>>> >>>> >>>> G=F6ran >>>> >>>> >>>> >>>> >>>> >>>> On 11/03/14 16:49, "Zach Shelby" wrote: >>>> >>>>> Hannes, >>>>> >>>>> I am happy with this charter with one exception. The proxy item here >>>>> seems to be more of a distraction than anything else, and will >>>>>probably >>>>> result in increased complexity. Was proxy support maybe just a >>>>> misunderstanding? Do we really see the need for a proxy in the middle >>>>> of >>>>> I or III? >>>>> >>>>> I think what we really want here is to make sure that e.g. even >>>>> through I >>>>> is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In >>>>> other >>>>> words, some interfaces can be constrained while others are not. I >>>>>think >>>>> the charter already covers this fine. >>>>> >>>>> So my proposal would be to remove the mention of protocol translation >>>>> proxies. If we really see the need for this some day in the future, >>>>>it >>>>> could be tackled then. >>>>> >>>>> Zach >>>>> >>>>> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have taken the feedback from the meeting and the recent >>>>>>discussions >>>>>> on >>>>>> the mailing list and produced a new strawman proposal. >>>>>> >>>>>> The changes include: >>>>>> * Added the focus on DTLS/CoAP with an indication that we will >>>>>>check a >>>>>> candidate solution for suitability with HTTP/TLS. >>>>>> * Added text to indicate that we will also verify the suitability of >>>>>> the solution for use with protocol translation proxies. >>>>>> * Simplified the task list by removing solution specific items. >>>>>> * Merged several items on the task list (use cases, requirements, >>>>>>and >>>>>> protocol design guidelines). Followed the suggestion to use of a >>>>>>Wiki >>>>>> for capturing those. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> ----- >>>>>> >>>>>> Draft Charter V0.5 - Authentication and Authorization for >>>>>>Constrained >>>>>> Environment (ACE) >>>>>> >>>>>> The IETF has recently developed protocols for use in environments >>>>>> where >>>>>> network nodes are limited in CPU, memory, and power. It was observed >>>>>> that Internet protocols can be applied to these constrained >>>>>> environments, often only requiring minor tweaking and profiling. In >>>>>> other cases, new protocols have been defined to address the specific >>>>>> requirements of constrained devices and networks. An example of >>>>>>such a >>>>>> protocol is the Constrained Application Protocol (CoAP). >>>>>> components >>>>>> As in other environments, authentication and authorization question >>>>>> also >>>>>> arise in environments with constrained nodes and networks. For >>>>>> example, >>>>>> a door lock has to authorize the person seeking access using a >>>>>> "digital >>>>>> key". Where are the authorization decisions stored? How does the >>>>>> digital >>>>>> key communicate with the lock? Does the lock interact with an >>>>>> authorization server to obtain authorization information? How can >>>>>> access >>>>>> be granted to other persons temporarily? How can access be revoked? >>>>>> These types of questions have been answered by existing protocols >>>>>>for >>>>>> use cases outside the constrained environment. But in constrained >>>>>> environment, additional requirements pose challenges for the use of >>>>>> various security protocols. >>>>>> >>>>>> The IETF has a long history in developing three party authentication >>>>>> and >>>>>> authorization protocols for distributed environments. Examples >>>>>>include >>>>>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>>>>> Authorization, and Accounting (AAA) infrastructure, and the Web >>>>>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>>>>> deployment on the Internet. Although they all aim to solve a similar >>>>>> goal, at an abstract level, they offer quite different functions and >>>>>> utilize different message exchanges. These differences are motivated >>>>>> by >>>>>> the main deployment use cases they were designed for. >>>>>> >>>>>> Requirements derived from use cases indicate the suitability of >>>>>> already >>>>>> existing work, such as OAuth, as a solution for constrained >>>>>> environments. These protocols were, however, not optimized for >>>>>> constrained environments. Additional requirements that need to be >>>>>> taken >>>>>> into account are the lack of a suitable user-interface for obtaining >>>>>> the >>>>>> consent of the user and the inability of embedded devices to contact >>>>>> an >>>>>> authorization server in real-time with every access request due to >>>>>> intermittent connectivity, etc. >>>>>> >>>>>> This working group therefore aims for a standardized solution for >>>>>> authentication and authorization to enable authorized access to >>>>>> resources in constrained environments. As a starting point, the >>>>>> working >>>>>> group will assume that access to resources offered by a resource >>>>>> server >>>>>> by a client devices takes place using CoAP and is protected by DTLS. >>>>>> Both resource server and client may be resource constraint. This >>>>>> access >>>>>> will be mediated by an authorization server, which does not suffer >>>>>> from >>>>>> the same resource limitations. >>>>>> >>>>>> Existing authentication and authorization protocols are used and >>>>>> re-applied for use with constrained devices, where applicable. This >>>>>> requires relevant specifications to be reviewed for suitability, >>>>>> selecting a subset of them, restricting the options within each of >>>>>>the >>>>>> specifications. Some functionalities may, however, not be available >>>>>>in >>>>>> existing protocols and for those cases new functionality has to be >>>>>> standardized. Thus, existing work can be leveraged and the group >>>>>> benefits from available security analysis, implementation, and >>>>>> deployment experience. Moreover, a standardized solution for >>>>>>federated >>>>>> authentication and authorization will help to stimulate the >>>>>>deployment >>>>>> of IoT devices offering increased security. >>>>>> >>>>>> Once progress in identifying suitable candidate solutions has been >>>>>> made >>>>>> the working group will verify whether the same mechanism are also >>>>>> applicable beyond the use of CoAP and DTLS. In particular, the >>>>>>ability >>>>>> to use the developed solution over HTTP and TLS will be >>>>>>investigated. >>>>>> Furthermore, to guarantee smooth transition the integration with >>>>>> existing deployment will be studied. This particularly concerns the >>>>>> use >>>>>> of protocol translation proxies. >>>>>> >>>>>> To be successful this working group requires expertise in security, >>>>>> privacy, and a good understanding of usability in the constrained >>>>>> environment space. This work does not make the assumption that the >>>>>> party >>>>>> offering application layer services is always the same party >>>>>>offering >>>>>> network access services. >>>>>> >>>>>> The working group has the following tasks (in this order): >>>>>> >>>>>> 1) The working group Wiki pages will be used to document use cases, >>>>>> requirements, and protocol design criteria. This work will guide the >>>>>> identification of suitable protocol mechanisms. >>>>>> >>>>>> 2) Selection of an authentication and authorization protocol for >>>>>> constrained environments. >>>>>> >>>>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and >>>>>> proxy >>>>>> deployments. >>>>>> >>>>>> ----- >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> _______________________________________________ >>>>>> Ace mailing list >>>>>> Ace@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ace >>>>> >>>>> Zach Shelby >>>>> Director of Technology >>>>> ARM Internet of Things BU >>>>> www.arm.com >>>>> mobile: +1 (408) 203-9434 >>>>> Skype: zdshelby >>>>> LinkedIn: fi.linkedin.com/in/zachshelby/ >>>>> >>>>> >>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments >>>>>are >>>>> confidential and may also be privileged. If you are not the intended >>>>> recipient, please notify the sender immediately and do not disclose >>>>>the >>>>> contents to any other person, use it for any purpose, or store or >>>>>copy >>>>> the information in any medium. Thank you. >>>>> >>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>>>> Registered in England & Wales, Company No: 2557590 >>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>>>> 9NJ, >>>>> Registered in England & Wales, Company No: 2548782 >>>>> >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>> >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 > From nobody Thu Mar 13 07:37:32 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2F1A09C9 for ; Thu, 13 Mar 2014 07:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKB9SeLY2WzO for ; Thu, 13 Mar 2014 07:37:13 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2001A09E5 for ; Thu, 13 Mar 2014 07:37:13 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6964D20035 for ; Thu, 13 Mar 2014 11:56:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 83343647C9; Thu, 13 Mar 2014 10:37:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5DB2A64655 for ; Thu, 13 Mar 2014 10:37:05 -0400 (EDT) From: Michael Richardson To: "ace\@ietf.org" In-Reply-To: <53210BE1.5070702@gmx.net> References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/cd94IQqby9Ma6O-s7RLDQjcXVTs Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 14:37:15 -0000 --=-=-= I propose that there be a use case Informational ID, which over time, will transform into a roadmap/architectural document. It will not be published "prior" to the standards track documents, but since it will be referenced by them all, they won't go forward either without it. (this is essentially how homenet has turned out, but we didn't do it intentionally... ) I agree with Hannes that we the use cases/requirements can be hard to complete and the approach of "no desert until you finish your veggies" sometimes works, but as often as not, it just means it takes a long time. Pick someone to edit the use case document who really wants an RFC credit, and their personal motiviation will get it done. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyHCkYqHRg3pndX9AQIgOgQA1T4jn8fmKChU8tvXQrsBjcrTEXiY5aiV P8vylm8dd0S2MP2ZQaPybZS1CgT222qCn7FVMtqMo8/EvZcmu7qCD7OKhQsis64z LaISVYBItlvLHOkt8dGvfT0IZ3QVCTYgoz5X6Nsj8cS/MQvrRnB3TFeVoRFBaylQ 87S/K6k4cBw= =EYwr -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 13 08:01:06 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D851A09E0 for ; Thu, 13 Mar 2014 08:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0EwR4z7dew7 for ; Thu, 13 Mar 2014 08:01:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3A92F1A09DA for ; Thu, 13 Mar 2014 08:01:03 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-89-5321c827c66d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F3.F1.23809.728C1235; Thu, 13 Mar 2014 16:00:55 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 16:00:55 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] Design Consideration Document as one milestone? Thread-Index: AQHPPrewRMKjLCAMGkyGQgBzpjAjyZrfHJ+A Date: Thu, 13 Mar 2014 15:00:55 +0000 Message-ID: References: <53210566.60100@gmx.net> In-Reply-To: <53210566.60100@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja76CcVggxcLrS2+f+thtli68x6r A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJXx4FcDY8F0gYqlmz8yNjDO4O1i5OCQEDCR +PrBoouRE8gUk7hwbz1bFyMXh5DAIUaJJ7ObWCGcJYwSz793MIJUsQm4Shx48I4JxBYRCJI4 3PiaDcQWFnCSWPt+NjtE3Fli8cEljBC2kcTDy+dYQJaxCKhKzJnCDBLmFTCXuNE5lR0kLCSg IvHnFFiYE6ji8vePYJ2MQPd8P7UGbBOzgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WEFtUQE/i 3qO5LBBxJYlFtz9D9epJ3Jg6hQ3CtpZ4e7+BHcLWlli28DXUOYISJ2c+YZnAKD4LybpZSNpn IWmfhaR9FpL2BYysqxjZcxMzc9LLjTYxAuPp4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQZGpu15efbeW8KKOH/82MLH5nfir5iE1HZlvhd3qw9JGWnb HNC9/3DzCsGftm8uyxbGtL/kNNT2UHixh7v5Xuutta1LNZ7cdazrFHaZ/GD2ImnNuT9TnvqH cxZbNq0USLlXF6UXsdD31L2yE50uzR9uauySa43xEdj1ZsJsrgPTrdt5fS4bbmJRYinOSDTU Yi4qTgQAFkiYZ3UCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0kjYzOD3Uq4DC4iTfN32xtAYQPA Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:01:05 -0000 Hi Hannes Thanks for bringing this up. Let me give some context. In the preparation for the BOF (and as was later shown in the BOF) it was clear that there are strong opinions about the (in)feasibility of /public key/ crypto in constrained devices. Some people state that =B3there will only be two public key operations in the lifetime of this device=B2, referring to the high cost for asymmetric crypto so that they are only used to establishing secret keys that are used thereafter. Yet other people state =B3the cost for public key crypto is negligable in today=B9s devices=B2=20 Looking into the literature it is clear that public key crypto is in many cases affordable, but also that it does not come for free. Moreover, when comparing e.g. with message transmission and reception in wireless embedded devices, you get another picture what may be expensive in security protocol execution from an energy consumption point of view. Section 3.2.2 discusses this in a symmetric crypto context. This draft was put together in a rush a few days before cutoff and contains mainly obvious things. As said, I=B9m happy to use this as a basis for a Wiki or restart the discussion. What I would like to see documented is the (non-obvious) cost comparisons and trade-offs between e.g. round-trips and crypto operations, symmetric vs asymmetric operations etc. to be able to refer to in future discussions when we need to assess the feasibility of a particular security protocol in a constrained environment. G=F6ran On 13/03/14 02:09, "Hannes Tschofenig" wrote: >Goeran raised a question about adding a milestone for a document that >captures assumptions and design criteria. > >He contributed an initial version of such a document with >https://tools.ietf.org/html/draft-seitz-ace-design-considerations-00 > >What does the rest of the group think about that idea? > >Would you be willing to review such a document? >Would you be willing to contribute to such a document? > >Ciao >Hannes > From nobody Thu Mar 13 08:27:59 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0531A09CD for ; Thu, 13 Mar 2014 08:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeIMKz2_S-Ew for ; Thu, 13 Mar 2014 08:27:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABE21A08ED for ; Thu, 13 Mar 2014 08:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2DFRjR3010721; Thu, 13 Mar 2014 16:27:45 +0100 (CET) Received: from aung.tzi.org (eduroam-pool7-0557.wlan.uni-bremen.de [134.102.114.45]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8E993B7F; Thu, 13 Mar 2014 16:27:45 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <5321B255.3070801@gmx.net> Date: Thu, 13 Mar 2014 16:27:45 +0100 In-Reply-To: <5321B255.3070801@gmx.net> (Hannes Tschofenig's message of "Thu, 13 Mar 2014 14:27:49 +0100") Message-ID: <87eh26glu6.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/ace/N9uppJH1V9P2Edb1vNB1mcyknug Cc: "ace@ietf.org" Subject: Re: [Ace] Authorization server: a constrained device? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:27:57 -0000 Hannes Tschofenig writes: > reading through Sam's email and various comments during the BOF I was > wondering whether the group has a consensus to assume that the > authorization is not a constrained device. >From what I took from the discussions since the Berlin IETF that eventually led to the ACE BoF, I always had the impression that the Authorization Server is regarded as not constrained in non-trivial use-cases. Gruesse Olaf From nobody Thu Mar 13 08:30:03 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78351A09EC for ; Thu, 13 Mar 2014 08:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy0jRKpyHy1P for ; Thu, 13 Mar 2014 08:30:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF0451A08ED for ; Thu, 13 Mar 2014 08:29:59 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LwGDy-1XECI504GE-0185Xu; Thu, 13 Mar 2014 16:29:51 +0100 Message-ID: <5321CE51.9060903@gmx.net> Date: Thu, 13 Mar 2014 16:27:13 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?windows-1254?Q?G=F6ran_Selander?= , Zach Shelby References: <531EC063.3000903@gmx.net> <33D17082-A12A-41A3-9CFF-7EF6E802648D@arm.com> <5320C480.9070609@gmx.net> <5321082E.6040502@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PCOCgcjcBNCeg0q109qB7E1weS7jrcaEe" X-Provags-ID: V03:K0:EmWxumgyKfjkv5BF4TlDj6JU8M7dxS9n0oifaVcDeAZCia91nAX +MFJTbaxv100N+IQ7P9277daWYDDhY8ut/PPx0uBc5By/ZgJiuV408Z/KJWRdTo5srJ/Y9b yRyhLtBvpfWkvhsfcnwRViT6pcMQxpMDPb1a/t2XTvr9A8qvI1QITpEdSKD+9AMmKlbl1tO BckEobAS0P/fuyjcDArQA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/UbYKoKSglavJkIwUQxGmP7mqTX0 Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:30:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PCOCgcjcBNCeg0q109qB7E1weS7jrcaEe Content-Type: text/plain; charset=windows-1254 Content-Transfer-Encoding: quoted-printable On 03/13/2014 03:02 PM, G=F6ran Selander wrote: > I don=92t have a strong opinion here and certainly do not insist on a > =93waterfall=94 design model. It could be fruitful to elaborate on diff= erent > requirements as long as you are aware of what requirements you break an= d > what the consequences might be in terms of e.g. supported use cases or > security. I have seen both approaches being used and there are advantages and disadvantages. The benefit is that it forces folks to agree on the requirements early rather to push them into the solution space. On the other hand, everyone has some solutions in mind and hence they argue for their solution via requirements. If you move on too early there is the risk that you haven't actually concluded the use case/requirements discussion. If you start too late people moved on to do other things already and the work becomes irrelevan= t. Ciao Hannes --PCOCgcjcBNCeg0q109qB7E1weS7jrcaEe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIc5RAAoJEGhJURNOOiAtBOkIAIPfmaTf42AIaRXDKgw8cken vAekV1vnETEXhciU8GD06uLHD+peXtcSSATnDxUG7zGTlWPE/5N0Y1CcdpH+lYbK o2hez+h+rbJutn5/b2G9PFFo1jx1+tc6ZRGNhl480RsWkZdgkzgTokeuvF0jbKc5 +TbU5uEViJ9vWoViTOtSX4ZkNKtwM8eCzIadIrmdEw+WcHzb01Sw+Tvf9RI/ti4m 6bQuVbibQ8IcGH8zgsVscn8iJYVOMPp8zEGfqlMXRj74uUSH67xBQQqrlrhuXmKE Qn0if3nrvbc6+Wt3lReMWTK8P61A2NJkXiWfCk3btZ3fD8ay5P2T3yguhegOCaI= =Tl7A -----END PGP SIGNATURE----- --PCOCgcjcBNCeg0q109qB7E1weS7jrcaEe-- From nobody Thu Mar 13 08:36:33 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8EF1A09E9 for ; Thu, 13 Mar 2014 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRmA6rEuOyeE for ; Thu, 13 Mar 2014 08:36:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A71A1A08ED for ; Thu, 13 Mar 2014 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2DFaI9h027999; Thu, 13 Mar 2014 16:36:18 +0100 (CET) Received: from aung.tzi.org (eduroam-pool7-0557.wlan.uni-bremen.de [134.102.114.45]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 708C1B9F; Thu, 13 Mar 2014 16:36:18 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <53210566.60100@gmx.net> Date: Thu, 13 Mar 2014 16:36:18 +0100 In-Reply-To: <53210566.60100@gmx.net> (Hannes Tschofenig's message of "Thu, 13 Mar 2014 02:09:58 +0100") Message-ID: <87a9cuglfx.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/ace/6mB6--N6G1kULN0Real2RxaOTYc Cc: "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:36:32 -0000 Hannes Tschofenig writes: > Goeran raised a question about adding a milestone for a document that > captures assumptions and design criteria. I think that this document would be useful to track assumptions and design considerations. If there was a milestone for this (is that really necessary?) than it should be very later, after finishing most of the protocol design. Gruesse Olaf From nobody Thu Mar 13 08:49:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCE91A0A0D for ; Thu, 13 Mar 2014 08:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxvtTphwZpIy for ; Thu, 13 Mar 2014 08:49:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 544C01A09CD for ; Thu, 13 Mar 2014 08:49:05 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M5a9E-1XLJ8t3KuG-00xbcz; Thu, 13 Mar 2014 16:48:52 +0100 Message-ID: <5321D2B5.3070003@gmx.net> Date: Thu, 13 Mar 2014 16:45:57 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson , "ace@ietf.org" References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> <1148.1394721425@sandelman.ca> In-Reply-To: <1148.1394721425@sandelman.ca> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Rt7GTt63r4v7t4TCK9qoSKDrsqriCjFMm" X-Provags-ID: V03:K0:XSPOBLoloKHK9DCqufl+jD2XjmQ8zX1OD8rqD5O4eKRyYzD50z4 YfALM+wTN8E4aTeRnzjEOyQt1VOD1NRsyb1VWY1rS92stnFNUB2H10lU2T68MZ6ySncgim5 PwsjkLxzwYgvdqF2fp7m95Pszz810RojHqvEX+91FC17mW8cb98tARMraOOt1/fNZHncmov qqN4+kHVj3rSfB2F2U0yQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/QCpPGuTArLQ-oOKimVO8QndPQLI Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:49:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Rt7GTt63r4v7t4TCK9qoSKDrsqriCjFMm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, On 03/13/2014 03:37 PM, Michael Richardson wrote: >=20 > I propose that there be a use case Informational ID, which over time, > will transform into a roadmap/architectural document. It will not be > published "prior" to the standards track documents, but since it will > be referenced by them all, they won't go forward either without it. That's an interesting idea from a document management point of view. It unfortunately does not answer the question when to start the solution work. I fear that it will be difficult to come up with a good answer. Of course I see the value to identify the key assumptions/requirements (as we, for example, have done during the BOF) to cut through the solution space. I had gotten the impression that a number of the folks in the group are already very much bought into their own solution approach and a lot of discussion on requirements/use cases will not necessarily change their mind. I hope I am wrong. Ciao Hannes --Rt7GTt63r4v7t4TCK9qoSKDrsqriCjFMm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIdK2AAoJEGhJURNOOiAtH0MIAIZW3zkvwSVCqwp/AXcrYcNn nM/UN2PkhL2FEWDm02KvwCN8R3eBQtSJMBwqmz6SRxLb/8s8czQsJgglue4Ry4L3 I1ZzkmPDBFkouEFCJRWsWix3WvnMp91EhvkvgaEzxulgN1qvDjgKogV/JLUcBdFf 5MzaCLkWKKrrjQ+eoPQQFLVvMpm30i9wSsp5vlCEWmPzpmzIDKLywUiv44qROSdO skglSGCWZPLeeH570kWsOc4u1dGxn3qMEbTljgCZfYgKASbS1ljo7q2LVnxKLt8G xKNf2qMt73TOOagwFx4opMblz/Jg58RqsQEdnWeVp1o9C/Q/xeDUL9FhlSwX93I= =krT1 -----END PGP SIGNATURE----- --Rt7GTt63r4v7t4TCK9qoSKDrsqriCjFMm-- From nobody Thu Mar 13 09:09:30 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6001A0A2A for ; Thu, 13 Mar 2014 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITuewhaV5hRv for ; Thu, 13 Mar 2014 09:09:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id CD6021A0A27 for ; Thu, 13 Mar 2014 09:09:12 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MJGFi-1WQsHa1Dr8-002nZM; Thu, 13 Mar 2014 17:09:04 +0100 Message-ID: <5321D764.5010000@gmx.net> Date: Thu, 13 Mar 2014 17:05:56 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=F6ran_Selander?= , "ace@ietf.org" References: <53210566.60100@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cddXFNO76MC3AKc2BWhrDCR7BI9VTEdGO" X-Provags-ID: V03:K0:jOJIQDgqVGCi7tWRX4xc+KtLM+JaBfAm+ZV2jwgvM/EP2ma8sdP zi/LArQmdJFHq5slOP8YvjxEaGFmdOE+7WZKbPHmtqz43oTeun3/E5ziAoqTG5BFoqIL5yC BIpvRoRjZbmXwqH/0t6XA3YZbRvIWa7rE2Yji0qiFodV8JRBQ+vhRjsSJjakEceDYp7bPT8 AAWvw9K4SbqltCx0vSF9A== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Vag2uSA70GgTdyRGtuNGfS_1kcw Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:09:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cddXFNO76MC3AKc2BWhrDCR7BI9VTEdGO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Goeran, you raise another difficult question that relates a bit to the type of IoT devices have in mind. I fully agree with the challenge you identified regarding symmetric vs. asymmetric key crypto. It will be difficult to reach a consensus on that topic since most people in the group are actually not building devices themselves and therefore just use what fits their solution best. The cost of transmission that you mention is also important but the implication of just having fewer round-trips is a bit too simplistic since a constrained resource server will obviously suffer a lot since he has to listen for incoming connection attempts. So, I fear that (while these are super important aspects) we will have a hard time to make any useful decisions about them is two-fold: * We are not designing complete systems in the IETF and the energy assumption relates to the overall system (rather than a single protocol). Most of it is outside the IETF protocol design. * The processing capability obviously depends on the hardware and we are not making any statement about hardware in the group. Looking at Carsten's presentation from the BOF it also relates to cost, which is again a very complicated topic since hardware cost is not the only cost in product development. The classes in the LWIG terminology document do not go into any level of details regarding computational power and energy consumption. Only the memory requirements are listed in more detail and they seem to be rather hand-wavy. Ciao Hannes On 03/13/2014 04:00 PM, G=F6ran Selander wrote: > Hi Hannes >=20 > Thanks for bringing this up. Let me give some context. >=20 > In the preparation for the BOF (and as was later shown in the BOF) it w= as > clear that there are strong opinions about the (in)feasibility of /publ= ic > key/ crypto in constrained devices. Some people state that =B3there wil= l > only be two public key operations in the lifetime of this device=B2, > referring to the high cost for asymmetric crypto so that they are only > used to establishing secret keys that are used thereafter. Yet other > people state =B3the cost for public key crypto is negligable in today=B9= s > devices=B2=20 >=20 > Looking into the literature it is clear that public key crypto is in ma= ny > cases affordable, but also that it does not come for free. Moreover, wh= en > comparing e.g. with message transmission and reception in wireless > embedded devices, you get another picture what may be expensive in > security protocol execution from an energy consumption point of view. > Section 3.2.2 discusses this in a symmetric crypto context. >=20 > This draft was put together in a rush a few days before cutoff and > contains mainly obvious things. As said, I=B9m happy to use this as a b= asis > for a Wiki or restart the discussion. What I would like to see document= ed > is the (non-obvious) cost comparisons and trade-offs between e.g. > round-trips and crypto operations, symmetric vs asymmetric operations e= tc. > to be able to refer to in future discussions when we need to assess the= > feasibility of a particular security protocol in a constrained environm= ent. >=20 >=20 > G=F6ran >=20 >=20 > On 13/03/14 02:09, "Hannes Tschofenig" wrot= e: >=20 >> Goeran raised a question about adding a milestone for a document that >> captures assumptions and design criteria. >> >> He contributed an initial version of such a document with >> https://tools.ietf.org/html/draft-seitz-ace-design-considerations-00 >> >> What does the rest of the group think about that idea? >> >> Would you be willing to review such a document? >> Would you be willing to contribute to such a document? >> >> Ciao >> Hannes >> >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --cddXFNO76MC3AKc2BWhrDCR7BI9VTEdGO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIddkAAoJEGhJURNOOiAt85sIAKORLXzqekHrR3PKuGfG4Ebs sPIakmvqxLpCGJfA9ozL5ei3vRjEF6dJyb1U1SGFWhGDwC+W7bBL5JAGp/fRjO3X TGe7rb6waUXKE51fU/na9BChLhOzFLYXy38Fm7DvPzLdI1KuXphECila1ZfVyous IKmgDkKUtxfQNcEU34zwnEs1Gw0Q2AeoDk/zPM1CmN6YARn8L5p8u4ESudj4Lnwm IFiNeRyAcLEUMc/iwBX0PHBMELGabJDjFt0ZSXzXk64BFfouimTB0t/E3O30E/X3 2OlrTftGsNTEmeNIIkBaBncVAlDqR/9APgk/Ysl+8q7HNpITH7KI9vEnh/F/KfE= =fkJm -----END PGP SIGNATURE----- --cddXFNO76MC3AKc2BWhrDCR7BI9VTEdGO-- From nobody Thu Mar 13 09:11:16 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21121A0A11 for ; Thu, 13 Mar 2014 09:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdAow15OBK2D for ; Thu, 13 Mar 2014 09:11:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 46AE51A09F7 for ; Thu, 13 Mar 2014 09:11:11 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M1zFf-1XHBuu2AiB-00u3FE; Thu, 13 Mar 2014 17:11:04 +0100 Message-ID: <5321D7D5.2000503@gmx.net> Date: Thu, 13 Mar 2014 17:07:49 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Olaf Bergmann References: <5321B255.3070801@gmx.net> <87eh26glu6.fsf@tzi.org> In-Reply-To: <87eh26glu6.fsf@tzi.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i3Wfp3bp1BQTLMctM0u0OWqsAkgmRdCUQ" X-Provags-ID: V03:K0:dGJ5OWgPdjo8RpvcRaf2tkWcCafV5P6EPyvKtVDUK6z28gind0t gGjz2Z39rBHl+yY/YVp0s0EF9FC8ZznPjhl9C6ieWnEVh+BbcR1dZ7Kr49oSDQ2RMVSg03i 20gvOBb/Ay4guZe8rL90EV5oPTExDvIyldJ+ZWFDwf9DKsNzLX5lQZfxyLyufw73jNJ4qxi gjb2EeeYv2I01gaVPlsHQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/5fox7CYBQNhHet5K-NlYjys2RDI Cc: "ace@ietf.org" Subject: Re: [Ace] Authorization server: a constrained device? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:11:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i3Wfp3bp1BQTLMctM0u0OWqsAkgmRdCUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Olaf, thanks for sharing your views. The discussions before the BOF happened in a rather small group (mostly offline) and now we have a larger audience and so it seemed to be fair to re-state the question again (particularly after reading Sam's email). Ciao Hannes On 03/13/2014 04:27 PM, Olaf Bergmann wrote: > Hannes Tschofenig writes: >=20 >> reading through Sam's email and various comments during the BOF I was >> wondering whether the group has a consensus to assume that the >> authorization is not a constrained device. >=20 >>From what I took from the discussions since the Berlin IETF that > eventually led to the ACE BoF, I always had the impression that the > Authorization Server is regarded as not constrained in non-trivial > use-cases. >=20 > Gruesse > Olaf >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --i3Wfp3bp1BQTLMctM0u0OWqsAkgmRdCUQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIdfVAAoJEGhJURNOOiAtSNEIAI97MzadhVxXZx2XT92qtTYk SxK16jUZJEhEp498/Zg67jLwn0WXG8Qr9+hgidap1SABaSxUuF7FP866mI5i2vXD Nq4oNu2Lb6kH22yGbZdTPEMWY9c4SfvpArJ6NXrYprRPf+Lwh3GnE1nkpLt/QCdN gw09UKVsWWpmMfu3bOPTsDY4CkD5NB+unP3YxOcXofJj6Mec2m2/ASgQGStOFTIN N1yYYtoOFBbIRluidU9DvQYW0iA1/K4/WFX2sriQ1/lp0iCe6AbF/0MQwrpqHzPj bxvo8MpA+ZlKvl2f2F3tEyoiEkVyUesmOu4KQQpqu3QvC43GRzDRdyQJtZwcJ1A= =cH2W -----END PGP SIGNATURE----- --i3Wfp3bp1BQTLMctM0u0OWqsAkgmRdCUQ-- From nobody Thu Mar 13 09:15:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F971A09A8 for ; Thu, 13 Mar 2014 09:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqo9MNEqGbkO for ; Thu, 13 Mar 2014 09:15:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 43FAF1A073C for ; Thu, 13 Mar 2014 09:15:30 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LejNC-1WwepQ1Iti-00qPzf; Thu, 13 Mar 2014 17:15:22 +0100 Message-ID: <5321D8D6.5060001@gmx.net> Date: Thu, 13 Mar 2014 17:12:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Olaf Bergmann References: <53210566.60100@gmx.net> <87a9cuglfx.fsf@tzi.org> In-Reply-To: <87a9cuglfx.fsf@tzi.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MK7v2wWGoUxD2Nq96x6Kx4jTTDnvkQfAi" X-Provags-ID: V03:K0:tanbiGV3WFr9AP+ut+NP9C63f+nN9+MAhz3cY9AFzPIWvxzxmCf M5vJCwckSOETRI7obGsttHwdO1EO2nD8ikZTkAPAe+Qfel7UNZMoLAbGlDmHdfbmJOxhsLf G1Z4qsqkfFLDq2TocDDGljvjpB/tz9mT2tvAPpUU6kg8GjDgeVB/y1PatmttlrvR+pbVWHk DSCzzaHYHoZaqwGS3PITg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/NFhRzjXVphp0h8AuWDLnQDH6aow Cc: "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:15:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MK7v2wWGoUxD2Nq96x6Kx4jTTDnvkQfAi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we want to publish a document as part of the group then we also need to have a milestone for it. You need to tell me whether you think it is useful to add such a document as a deliverable to the charter or not and whether you are willing to review/contribute. Ciao Hannes On 03/13/2014 04:36 PM, Olaf Bergmann wrote: > Hannes Tschofenig writes: >=20 >> Goeran raised a question about adding a milestone for a document that >> captures assumptions and design criteria. >=20 > I think that this document would be useful to track assumptions and > design considerations. If there was a milestone for this (is that reall= y > necessary?) than it should be very later, after finishing most of the > protocol design. >=20 > Gruesse > Olaf >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --MK7v2wWGoUxD2Nq96x6Kx4jTTDnvkQfAi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIdjWAAoJEGhJURNOOiAtPc8H/3n9ZBUxjVbv4vHhCiayYV7j j7fTO5JVp1Pc4NK49uXUN5hDCPFJSXmsXQ2nxmSa46e92dHgiS+pFvP1mwwrgDLk ER1lC8V8a6V/D/SydWZUjYgtE1oWfKygIuh1V7ek0K6HAD8jX/aBY4uLL7zlKj35 EkyFl97rA1juxrDWzTXSPKBcLfSM47hGqCOelquG/vMxmURTq37Y/jl3nsy6+LJM UxOq9r/j5uUm/bqVAyy4+GqrumDXZ2AQDTfMvKN7Qy7zJxGgRpJbAZjejGL+kwPS NCKJp196hPPik+a8zTzam5cfRiMm8gEMLXvdSTx6Qigs3HedEMABrMeE0bLxe3E= =N1e5 -----END PGP SIGNATURE----- --MK7v2wWGoUxD2Nq96x6Kx4jTTDnvkQfAi-- From nobody Thu Mar 13 09:28:56 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F141A0A1D for ; Thu, 13 Mar 2014 09:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvMqW-nxqM75 for ; Thu, 13 Mar 2014 09:28:52 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9136F1A09F0 for ; Thu, 13 Mar 2014 09:28:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BFB0C2003B; Thu, 13 Mar 2014 13:47:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D3FED647C9; Thu, 13 Mar 2014 12:28:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BEF6364655; Thu, 13 Mar 2014 12:28:45 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <5321D2B5.3070003@gmx.net> References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> <1148.1394721425@sandelman.ca> <5321D2B5.3070003@gmx.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1889iPbJ1PW_kmwP6hznRi1oikw Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:28:53 -0000 --=-=-= Hannes Tschofenig wrote: > On 03/13/2014 03:37 PM, Michael Richardson wrote: >> >> I propose that there be a use case Informational ID, which over time, >> will transform into a roadmap/architectural document. It will not be >> published "prior" to the standards track documents, but since it will >> be referenced by them all, they won't go forward either without it. > That's an interesting idea from a document management point of view. > It unfortunately does not answer the question when to start the solution > work. I fear that it will be difficult to come up with a good answer. Every piece of solution has to reference some part of problem space. If the problem space (document) is incomplete, then that part/feature of the solution has some problem with motivation. This would seem to be the Agile approach: cycles. When the cycle becomes empty, we are done. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyHcvYqHRg3pndX9AQLIIAP/anzCQ8dXmDS21R0MjRt+tfFpiAkuyqll mTPNP/iZ+DfQlYeTDZL5LfrrkxtwuvriN12Vof0qzwQo5F6KPue0ZnXQ/lmju2R4 1IlWxxoDUVPVlqVL4hNmByzbYNvNPAvQlOFyH50TKBoy6yZvFmr7oJpNRNQW+6Um X+i6THVe3YI= =gZKS -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 13 09:37:19 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5886F1A0A33 for ; Thu, 13 Mar 2014 09:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gIrE6K-J1zF for ; Thu, 13 Mar 2014 09:37:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 57F651A0A0B for ; Thu, 13 Mar 2014 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2DGb52x027491; Thu, 13 Mar 2014 17:37:05 +0100 (CET) Received: from [192.168.217.105] (p54890E27.dip0.t-ipconnect.de [84.137.14.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A86B9C55; Thu, 13 Mar 2014 17:37:04 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <5321D764.5010000@gmx.net> Date: Thu, 13 Mar 2014 17:37:02 +0100 X-Mao-Original-Outgoing-Id: 416421422.884331-314147091cbec9450a0c68ccb11ade38 Content-Transfer-Encoding: quoted-printable Message-Id: <61D7C04F-9B17-4EAF-A565-A25A45B97756@tzi.org> References: <53210566.60100@gmx.net> <5321D764.5010000@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fXou_gvIj9XyWRhetNevZw8sDxo Cc: =?windows-1252?Q?G=F6ran_Selander?= , "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:37:17 -0000 On 13 Mar 2014, at 17:05, Hannes Tschofenig = wrote: > I fully agree with the challenge you > identified regarding symmetric vs. asymmetric key crypto. It will be > difficult to reach a consensus on that topic I don=92t think that such a decision is possible or desirable. We didn=92t do that for CoAP (which has security modes, and preferred = cipher suites, for both shared-key and public-key), and we shouldn=92t = try to do that here. Gr=FC=DFe, Carsten From nobody Thu Mar 13 09:41:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18C1A0A0B for ; Thu, 13 Mar 2014 09:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIpCi38P_K2m for ; Thu, 13 Mar 2014 09:41:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A30631A0A1E for ; Thu, 13 Mar 2014 09:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2DGfeAW007363; Thu, 13 Mar 2014 17:41:40 +0100 (CET) Received: from [192.168.217.105] (p54890E27.dip0.t-ipconnect.de [84.137.14.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E286CC64; Thu, 13 Mar 2014 17:41:39 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <5321D2B5.3070003@gmx.net> Date: Thu, 13 Mar 2014 17:41:38 +0100 X-Mao-Original-Outgoing-Id: 416421698.465019-f1a47c76b4abeb1da46ca056bdaa72e4 Content-Transfer-Encoding: quoted-printable Message-Id: <9167D48D-3791-475D-90B1-E80D61BEA2D4@tzi.org> References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> <1148.1394721425@sandelman.ca> <5321D2B5.3070003@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fYudG2k6Q3pzkg1V7Eaijc4-DHU Cc: Michael Richardson , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:41:51 -0000 On 13 Mar 2014, at 16:45, Hannes Tschofenig = wrote: > It unfortunately does not answer the question when to start the = solution > work. I fear that it will be difficult to come up with a good answer. This is a design problem, so you start solution work in parallel with = understanding the feasible objectives. (The solution space informs the objectives as much as the objectives = inform the solutions.) Gr=FC=DFe, Carsten From nobody Thu Mar 13 09:50:08 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14EA1A0A23 for ; Thu, 13 Mar 2014 09:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2nFML60oAa5 for ; Thu, 13 Mar 2014 09:49:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5701A0A36 for ; Thu, 13 Mar 2014 09:49:55 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzXTy-1XArn63nog-014m6E; Thu, 13 Mar 2014 17:49:47 +0100 Message-ID: <5321E0C3.5020802@gmx.net> Date: Thu, 13 Mar 2014 17:45:55 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carsten Bormann References: <53210566.60100@gmx.net> <5321D764.5010000@gmx.net> <61D7C04F-9B17-4EAF-A565-A25A45B97756@tzi.org> In-Reply-To: <61D7C04F-9B17-4EAF-A565-A25A45B97756@tzi.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="I79BP7DePCHdvbgKcXM1bCmCpLJpwd3Rx" X-Provags-ID: V03:K0:cIpmb3dYxUzQSF9h8PcR2/yLI/CgsBl1Rakk5CDd18zNfNelfvE NHa2MWlGfMzxALDDl6+AkTdurg55vZvlgL0hJN3DkOesl4e2ANDX6sl4UhbafFSB80/dSJa fYxtlKFzXyGABH/3L/LBqbSW2in046GILJ+X2bK4gpqBcUPpCUHpaImHEV49Qo7ZVQQLnBL AYw51BiCj5fj0iyHkI3xQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/a0dG34XekcRvTPWtKzLQGjPG404 Cc: =?windows-1252?Q?G=F6ran_Selander?= , "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:49:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I79BP7DePCHdvbgKcXM1bCmCpLJpwd3Rx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Carsten, while that's an interesting way to post pone the problem it introduces interoperability problems. Clients implementing one option who talk to resource servers implementing different options. Do you see the interop challenges there? Ciao Hannes On 03/13/2014 05:37 PM, Carsten Bormann wrote: > On 13 Mar 2014, at 17:05, Hannes Tschofenig = wrote: >=20 >> I fully agree with the challenge you >> identified regarding symmetric vs. asymmetric key crypto. It will be >> difficult to reach a consensus on that topic >=20 > I don=92t think that such a decision is possible or desirable. > We didn=92t do that for CoAP (which has security modes, and preferred c= ipher suites, for both shared-key and public-key), and we shouldn=92t try= to do that here. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --I79BP7DePCHdvbgKcXM1bCmCpLJpwd3Rx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIeDEAAoJEGhJURNOOiAtgisH/1YnbpLxM5QMgKgtLUmiPB4s 78rrbjnkVAd6ZBbPRYNZdDAgNLuNqPMtUDWTHvyExKt1pOP/bT+vkcHWUbqYUUE2 /VvuTTUD025NRoFLxB3eWb4Qbhb+8DgWBLnNPJkbHf1NGCNGTgN35sfDem7zzJfC En9oANqjwdVqT+R5Cs1rro6dCVc5cvdqgKlmCg5Oy+ig8hzSZuZaLSWS+AKLT4Ha fjdyL/oR/Kf8Ovxdf9RIS09hN10mP4SV7pGQUx1LwDOgS19mnMavjKur2t/5rqzM 3ggNNLKHbsKnO5TRw4UGpLz6o9Ne/Q/kt6u1Slw7n9Dc0AG2qDBbntoCfAWkbwQ= =FPJs -----END PGP SIGNATURE----- --I79BP7DePCHdvbgKcXM1bCmCpLJpwd3Rx-- From nobody Thu Mar 13 09:54:17 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26011A0A27 for ; Thu, 13 Mar 2014 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmgXRj1_H7Df for ; Thu, 13 Mar 2014 09:54:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id BBEEA1A09CE for ; Thu, 13 Mar 2014 09:54:13 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LoKHN-1X3YO33Z8r-00gGq8; Thu, 13 Mar 2014 17:54:03 +0100 Message-ID: <5321E1BF.7060708@gmx.net> Date: Thu, 13 Mar 2014 17:50:07 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carsten Bormann References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> <1148.1394721425@sandelman.ca> <5321D2B5.3070003@gmx.net> <9167D48D-3791-475D-90B1-E80D61BEA2D4@tzi.org> In-Reply-To: <9167D48D-3791-475D-90B1-E80D61BEA2D4@tzi.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TptL18dllV6qEOCT3tCpnX82E5ViskUqQ" X-Provags-ID: V03:K0:jBBj0w//jGlTwE1g1U3SSmLS32TtlPV4Qa0Z3wMFZmp512Q17AY RGEf2NB7PfPlL2hXgiesNqSemAU3v78ixbprNdBTrXgF5WGCXo5mqjxXpCoRKkP5a5T3ggK 9hj5Mof3dpNoMgBy7XVrOxsS1G2y0SCoF2HuIgb7U4y9SGoFVwtWLHlcKH9U4DJpSPGi1pB kIvWJ6ha9Lf9fAZ+eoCSA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/iMlaTY9ejLipvdI2P6Ofr34y8aw Cc: Michael Richardson , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:54:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TptL18dllV6qEOCT3tCpnX82E5ViskUqQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that this approach is in-line with what Michael suggested. Goeran (and others), is that OK for you as well? The use cases/requirements/etc. document would then get roughly published at the same time as the solution spec. On 03/13/2014 05:41 PM, Carsten Bormann wrote: > On 13 Mar 2014, at 16:45, Hannes Tschofenig = wrote: >=20 >> It unfortunately does not answer the question when to start the soluti= on >> work. I fear that it will be difficult to come up with a good answer. >=20 > This is a design problem, so you start solution work in parallel with u= nderstanding the feasible objectives. > (The solution space informs the objectives as much as the objectives in= form the solutions.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --TptL18dllV6qEOCT3tCpnX82E5ViskUqQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIeG/AAoJEGhJURNOOiAtY1sH/imSHMcvrBTENLbluyNmfMSi hPkVXo320DryZgEbMZixoIrEBQaHfYL5NXSSyyY9L28cu9olfL3JlFzOAQjfxId4 F5snKIsppynKXhXNZgKdD/+MW/C5raE6NgRkuvOGqvdJvyABquETMZRBTrk2dUCZ ZGCt6gEBaOSC1A2bx+jJndh3gUHgHbOBCg4g6waKHOC8Q6Whwc43hj499/RPYcyM 71BOHO0CIxPjGkzY3jJ6CrqGKY5JOkM2V2ONh4RNGgTn78h/22wnVFP2rJ84jW9N pbZUjEA4dyj7lKQ/ae1E14rLAcDGC/+idD87aCBAc0JG7MBhvsTXunIloLcWvp8= =kbJA -----END PGP SIGNATURE----- --TptL18dllV6qEOCT3tCpnX82E5ViskUqQ-- From nobody Thu Mar 13 09:54:34 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C178B1A0A4A for ; Thu, 13 Mar 2014 09:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aDau8oNQLPE for ; Thu, 13 Mar 2014 09:54:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBC91A0A49 for ; Thu, 13 Mar 2014 09:54:30 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2DGsKxO010235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 16:54:21 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2DGsKK5009861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 16:54:20 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2DGsKjN028348; Thu, 13 Mar 2014 16:54:20 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Mar 2014 09:54:19 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <53210A20.6090709@gmx.net> Date: Thu, 13 Mar 2014 09:54:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53210A20.6090709@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/ace/6_t02QtekcE7Wyvap7rh1wNmfi4 Cc: "ace@ietf.org" Subject: Re: [Ace] When to deal with proxies? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:54:33 -0000 I think proxies should be discussed up front. I'm not a big fan of them, = so discussing why we think we need them seems important. My belief is that dual-protocol endpoints rather than gateways/proxies = is what will be simplest and most secure.=20 But again, discussion will bring out what we mean by proxy and what the = benefits are. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-03-12, at 6:30 PM, Hannes Tschofenig = wrote: > Hi all, >=20 > Goeran raised a question in the charter discussion about when to > investigate suitability of the solution regarding proxies. >=20 > With version 0.5 of the charter I suggested to explore the proxy = issues* > after a candidate solution had been selected. >=20 > He suggested, however, to deal with proxies already during as part of > the requirements/use case/design considerations phase. >=20 > What would you like to do? >=20 > Ciao > Hannes >=20 > PS: We discussed various types of proxies on the list. Some proxies = were > protocol translation proxies that provided the ability to interface = with > other protocols (e.g., HTTP) and deployed infrastructure (some backend > authentication/authorization infrastructure) and yet other proxies = were > part of the CoAP protocol. >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Mar 13 10:00:28 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8CB1A0A2F for ; Thu, 13 Mar 2014 10:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDwWZXvpmmy9 for ; Thu, 13 Mar 2014 10:00:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id CCF011A0499 for ; Thu, 13 Mar 2014 10:00:25 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mecqq-1WmIdi0ZJo-00OKTy; Thu, 13 Mar 2014 18:00:14 +0100 Message-ID: <5321E32C.2040706@gmx.net> Date: Thu, 13 Mar 2014 17:56:12 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Phil Hunt References: <53210A20.6090709@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VBEbGrVo3nfPBgDqiUpRE2Gtx8eiOpTkO" X-Provags-ID: V03:K0:MGf39LMboD8/PrHRZOo7EiG92sA1Dwlukt0k8+EiCvR5aSFm11a hISgdG/t6M45FdgvIgA5/l36iAYcdVMwbl1sHHC9gn/L760gTjqiOXws9fKWgAIHl8D8PzZ a/05Yw3H436/SMpTYIWlv+KzeaT4uAFvaps5iDT3tqtsly4YWG1dx8aN8Cv76FwVH6lTADj dYBXZLpjtW7CPsY1XPxeg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/bMgKK9fpsbxcCsPGDrzO0SyZX7o Cc: "ace@ietf.org" Subject: Re: [Ace] When to deal with proxies? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:00:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VBEbGrVo3nfPBgDqiUpRE2Gtx8eiOpTkO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your feedback, Phil. Dual-protocol endpoints might be a bit challenging for some of the devices that folks have in mind. CoAP was developed since there was the believe HTTP stacks do not fit on some of these very constrained devices. Telling these people now that they should now add HTTP to it because of interworking with legacy infrastructure might make them jump up-and-down. Ciao Hannes On 03/13/2014 05:54 PM, Phil Hunt wrote: > I think proxies should be discussed up front. I'm not a big fan of them= , so discussing why we think we need them seems important. >=20 > My belief is that dual-protocol endpoints rather than gateways/proxies = is what will be simplest and most secure.=20 >=20 > But again, discussion will bring out what we mean by proxy and what the= benefits are. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > On 2014-03-12, at 6:30 PM, Hannes Tschofenig wrote: >=20 >> Hi all, >> >> Goeran raised a question in the charter discussion about when to >> investigate suitability of the solution regarding proxies. >> >> With version 0.5 of the charter I suggested to explore the proxy issue= s* >> after a candidate solution had been selected. >> >> He suggested, however, to deal with proxies already during as part of >> the requirements/use case/design considerations phase. >> >> What would you like to do? >> >> Ciao >> Hannes >> >> PS: We discussed various types of proxies on the list. Some proxies we= re >> protocol translation proxies that provided the ability to interface wi= th >> other protocols (e.g., HTTP) and deployed infrastructure (some backend= >> authentication/authorization infrastructure) and yet other proxies wer= e >> part of the CoAP protocol. >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --VBEbGrVo3nfPBgDqiUpRE2Gtx8eiOpTkO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIeMsAAoJEGhJURNOOiAtuWcH/3ujx66qyLFbsPdNLlGtdvHJ MWlyh/SVP5QGmGQ+PH2BGnGV5s1d1zNWSQlpL6xl184yHw0UCuo3Grd/l98S2MdX GhLuXMtHcxLxd3oaJI20iGOlJnuBilMl5HGVAQ4D2aDbnM5Za5cXFOcCMyBk0M8Y u6NnIVZsF+h8xhCe/qvZQo05GYWMSOgw2xYH78n5+lcWE/LizOYlPPt/ZFTIp79l oMErWXSfh5xVRg9kiztqR6iUWYD1FMGN6IDvgEfUCPWIDlP01a4CPwBZYf2Gzfq9 nNgfBhh+2gQ2RAurM04ACd6bcn/e+fqpZJwky8odA83rfJ774K1EjG/KtwGKRIE= =gnb0 -----END PGP SIGNATURE----- --VBEbGrVo3nfPBgDqiUpRE2Gtx8eiOpTkO-- From nobody Thu Mar 13 10:04:11 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8421A0A27 for ; Thu, 13 Mar 2014 10:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk8Sz-DAWx0M for ; Thu, 13 Mar 2014 10:04:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 958BD1A0A49 for ; Thu, 13 Mar 2014 10:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2DH3uw1020526; Thu, 13 Mar 2014 18:03:56 +0100 (CET) Received: from [192.168.217.105] (p54890E27.dip0.t-ipconnect.de [84.137.14.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B39D4C93; Thu, 13 Mar 2014 18:03:55 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <5321E0C3.5020802@gmx.net> Date: Thu, 13 Mar 2014 18:03:53 +0100 X-Mao-Original-Outgoing-Id: 416423033.8647-67d6d6005ec80d0d1557c82fcf09444d Content-Transfer-Encoding: quoted-printable Message-Id: References: <53210566.60100@gmx.net> <5321D764.5010000@gmx.net> <61D7C04F-9B17-4EAF-A565-A25A45B97756@tzi.org> <5321E0C3.5020802@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/-DDZAF28bXvoOtrGLq7xBVGxVmY Cc: =?windows-1252?Q?G=F6ran_Selander?= , "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:04:10 -0000 On 13 Mar 2014, at 17:45, Hannes Tschofenig = wrote: > Hi Carsten, >=20 > while that's an interesting way to post pone the problem it introduces > interoperability problems. This doesn=92t postpone the problem, it simply acknowledges that it is = not a problem because it can=92t be solved. > Clients implementing one option who talk to resource servers > implementing different options. >=20 > Do you see the interop challenges there? Starting from the Berlin model: M------A | (|) | (|) C------S It is probably worth keeping the C-S protocol free of asymmetric crypto, = if only for performance reasons. The A-S protocols (both the direct one and the one tunneled through M = and C) are intra-domain and can therefore more easily be chosen for the = specific application, so it is easier to live with both a symmetric and = an asymmetric variant being around and to be chosen from; this is also = true for the C-M protocol. The M-A protocols should allow for a much larger variety, based on what = is in use in the specific application sector. But again, let=92s generate those solutions first and evolve the = objectives based on what is achievable, not the other way around. Gr=FC=DFe, Carsten From nobody Thu Mar 13 10:12:21 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09F21A0A3B for ; Thu, 13 Mar 2014 10:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTG_N0oU_H_F for ; Thu, 13 Mar 2014 10:12:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DEC571A0499 for ; Thu, 13 Mar 2014 10:12:17 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2DHC7xs015346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 17:12:08 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2DHC6br001377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 17:12:07 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s2DHC6Se011941; Thu, 13 Mar 2014 17:12:06 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Mar 2014 10:12:06 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <5321E32C.2040706@gmx.net> Date: Thu, 13 Mar 2014 10:12:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6FA2C0F0-8B90-43A2-951B-BA93ACB0E18D@oracle.com> References: <53210A20.6090709@gmx.net> <5321E32C.2040706@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Oiz0-5sSt489Wgw4lYAi_YAPZQg Cc: "ace@ietf.org" Subject: Re: [Ace] When to deal with proxies? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:12:20 -0000 Agreed. When it is all constrained, the case is clear. But often there = will be a mix. Some have pointed out that AS servers will likely be = unconstrained. My thought is that unconstrained endpoints will likely = have to be dual protocol (TCP and UDP) based. Some have commented that they think AS's would likely be unconstrained. = Taking that thought forward: an AS would likely support both constrained = and non-constrained clients allowing a non-constrained client to obtain = a token to use against a constrained resource. The reverse, a = constrained client obtains a token to use against a dual-protocol = resource. Or finally, a constrained client obtains a token to use with a = constrained resource. This is what we need to work through. As soon as we introduce proxies, = we get into MITM issues when a lot of current authorization approaches = are assuming secure point-to-point communication. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-03-13, at 9:56 AM, Hannes Tschofenig = wrote: > Thanks for your feedback, Phil. >=20 > Dual-protocol endpoints might be a bit challenging for some of the > devices that folks have in mind. CoAP was developed since there was = the > believe HTTP stacks do not fit on some of these very constrained > devices. Telling these people now that they should now add HTTP to it > because of interworking with legacy infrastructure might make them = jump > up-and-down. >=20 > Ciao > Hannes >=20 >=20 > On 03/13/2014 05:54 PM, Phil Hunt wrote: >> I think proxies should be discussed up front. I'm not a big fan of = them, so discussing why we think we need them seems important. >>=20 >> My belief is that dual-protocol endpoints rather than = gateways/proxies is what will be simplest and most secure.=20 >>=20 >> But again, discussion will bring out what we mean by proxy and what = the benefits are. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> On 2014-03-12, at 6:30 PM, Hannes Tschofenig = wrote: >>=20 >>> Hi all, >>>=20 >>> Goeran raised a question in the charter discussion about when to >>> investigate suitability of the solution regarding proxies. >>>=20 >>> With version 0.5 of the charter I suggested to explore the proxy = issues* >>> after a candidate solution had been selected. >>>=20 >>> He suggested, however, to deal with proxies already during as part = of >>> the requirements/use case/design considerations phase. >>>=20 >>> What would you like to do? >>>=20 >>> Ciao >>> Hannes >>>=20 >>> PS: We discussed various types of proxies on the list. Some proxies = were >>> protocol translation proxies that provided the ability to interface = with >>> other protocols (e.g., HTTP) and deployed infrastructure (some = backend >>> authentication/authorization infrastructure) and yet other proxies = were >>> part of the CoAP protocol. >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Mar 13 10:22:59 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E511A0A4A for ; Thu, 13 Mar 2014 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QPKqSGvXCyJ for ; Thu, 13 Mar 2014 10:22:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D74841A0A42 for ; Thu, 13 Mar 2014 10:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2DHMjIr027555; Thu, 13 Mar 2014 18:22:45 +0100 (CET) Received: from [192.168.217.105] (p54890E27.dip0.t-ipconnect.de [84.137.14.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8C756CB4; Thu, 13 Mar 2014 18:22:44 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <5321E1BF.7060708@gmx.net> Date: Thu, 13 Mar 2014 18:22:42 +0100 X-Mao-Original-Outgoing-Id: 416424162.78889-acf872fe1ac1cf2eaa7c8273dfb72717 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> <1148.1394721425@sandelman.ca> <5321D2B5.3070003@gmx.net> <9167D48D-3791-475D-90B1-E80D61BEA2D4@tzi.org> <5321E1BF.7060708@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/BZaXPjN2byOSWn-X2ADsKwvkWPk Cc: Michael Richardson , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:22:57 -0000 On 13 Mar 2014, at 17:50, Hannes Tschofenig = wrote: > The use cases/requirements/etc. document would then get roughly > published at the same time as the solution spec. That is a good goal. Recalling my experience as a co-chair of 6LoWPAN, we managed to get out = a use cases (RFC 6568) and a requirements (RFC 6606) document only after = the main work was done (RFC 4944, RFC 6282; only RFC 6775 came in even = later). Of course we had them around as drafts much of the time we were = working on the solutions, but it was hard to sustain the energy to = actually publish the informational documents in the end. It helped that = we had a short early =93problem statement, assumptions and goals=94 = document out (RFC 4919), which solidified some of the terms that got = used later, without trying to be the definitive requirements set. I=92m with Margaret in that I=92d also=20 > rather see the use cases and requirements published as = informationalRFCs. We just have to be aware that it=92s not easy to keep up the energy on = these. (We also have to be wary of =93requirements engineering=94, i.e. = manipulation of the requirements to favor one or the other solution. Fortunately, we never tried to establish formal =93requirements=94 in = 6LoWPAN, so we circumvented this cliff.) Gr=FC=DFe, Carsten From nobody Thu Mar 13 12:56:31 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EF11A0A36 for ; Thu, 13 Mar 2014 12:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY0yYHANQtc0 for ; Thu, 13 Mar 2014 12:56:27 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 12E911A07CF for ; Thu, 13 Mar 2014 12:56:27 -0700 (PDT) X-ASG-Debug-ID: 1394740579-06daaa24ad294760001-Yzt3Th Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id w6xcd0zvhOJWLYw5 for ; Thu, 13 Mar 2014 15:56:19 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Mar 2014 15:57:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Mar 2014 15:57:02 -0400 X-ASG-Orig-Subj: RE: [Ace] When to deal with proxies? Message-ID: In-Reply-To: <5321E32C.2040706@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ace] When to deal with proxies? Thread-Index: Ac8+3d5+VbI4IentScyehkm7t/xMsAAFtTHA References: <53210A20.6090709@gmx.net> <5321E32C.2040706@gmx.net> From: "Rahman, Akbar" To: "Hannes Tschofenig" , "Phil Hunt" X-OriginalArrivalTime: 13 Mar 2014 19:57:03.0697 (UTC) FILETIME=[67896C10:01CF3EF6] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1394740579 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.3848 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ZBbkQWj1NtpJFvW4055Cv4oNFqc Cc: ace@ietf.org Subject: Re: [Ace] When to deal with proxies? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 19:56:29 -0000 Hi Hannes, > I think proxies should be discussed up front. I'm not a big fan of them, so discussing why we think we need them seems important. I agree with this point from Phil. And it overlaps with the point that I previously brought up regarding extensive support of proxies in the current CoAP spec: http://www.ietf.org/mail-archive/web/ace/current/msg00360.html Since neither Zach/Carsten (i.e. CoAP experts) have responded yet, I would like to draw your attention to the following section of the CoAP spec which specifically discusses CoAP Proxies and DTLS. Please see especially the 3rd paragraph which refers specifically to "access control considerations": http://tools.ietf.org/html/draft-ietf-core-coap-18#section-11.2 Best Regards, Akbar -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, March 13, 2014 12:56 PM To: Phil Hunt Cc: ace@ietf.org Subject: Re: [Ace] When to deal with proxies? Thanks for your feedback, Phil. Dual-protocol endpoints might be a bit challenging for some of the devices that folks have in mind. CoAP was developed since there was the believe HTTP stacks do not fit on some of these very constrained devices. Telling these people now that they should now add HTTP to it because of interworking with legacy infrastructure might make them jump up-and-down. Ciao Hannes On 03/13/2014 05:54 PM, Phil Hunt wrote: > I think proxies should be discussed up front. I'm not a big fan of them, so discussing why we think we need them seems important. >=20 > My belief is that dual-protocol endpoints rather than gateways/proxies is what will be simplest and most secure.=20 >=20 > But again, discussion will bring out what we mean by proxy and what the benefits are. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > On 2014-03-12, at 6:30 PM, Hannes Tschofenig wrote: >=20 >> Hi all, >> >> Goeran raised a question in the charter discussion about when to=20 >> investigate suitability of the solution regarding proxies. >> >> With version 0.5 of the charter I suggested to explore the proxy=20 >> issues* after a candidate solution had been selected. >> >> He suggested, however, to deal with proxies already during as part of >> the requirements/use case/design considerations phase. >> >> What would you like to do? >> >> Ciao >> Hannes >> >> PS: We discussed various types of proxies on the list. Some proxies=20 >> were protocol translation proxies that provided the ability to=20 >> interface with other protocols (e.g., HTTP) and deployed=20 >> infrastructure (some backend authentication/authorization=20 >> infrastructure) and yet other proxies were part of the CoAP protocol. >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 From nobody Thu Mar 13 23:43:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6911A0058 for ; Thu, 13 Mar 2014 23:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lFDDX0eahuR for ; Thu, 13 Mar 2014 23:43:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 76A0C1A0056 for ; Thu, 13 Mar 2014 23:43:35 -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.7-GA FastPath queued) with ESMTP id BCB21987; Fri, 14 Mar 2014 06:43:27 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Mar 2014 06:42:28 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Mar 2014 06:43:25 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Fri, 14 Mar 2014 14:43:20 +0800 From: Likepeng To: Hannes Tschofenig , Olaf Bergmann Thread-Topic: [Ace] Authorization server: a constrained device? Thread-Index: AQHPPsCBy2qaH7QWRkaykfN2h4t1sZrfJB83//+FBYCAAUgHUA== Date: Fri, 14 Mar 2014 06:43:19 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B04A12@SZXEMA501-MBS.china.huawei.com> References: <5321B255.3070801@gmx.net> <87eh26glu6.fsf@tzi.org> <5321D7D5.2000503@gmx.net> In-Reply-To: <5321D7D5.2000503@gmx.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ny8tqJY5FLv7BHdnLnhB3YpDOQU Cc: "ace@ietf.org" Subject: Re: [Ace] Authorization server: a constrained device? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 06:43:38 -0000 SWYgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaXMgYWxzbyBjb25zdHJhaW5lZCwgdGhlcmUgaXMgbm8g bXVjaCBiZW5lZml0IHRvIGhhdmUgaXQgaW4gdGhlIGFyY2hpdGVjdHVyZS4NCg0KS2luZCBSZWdh cmRzDQpLZXBlbmcNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBBY2UgW21haWx0 bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBIYW5uZXMgVHNjaG9mZW5pZw0KPiC3osvNyrG8 5DogMjAxNMTqM9TCMTTI1SAwOjA4DQo+IMrVvP7IyzogT2xhZiBCZXJnbWFubg0KPiCzrcvNOiBh Y2VAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtBY2VdIEF1dGhvcml6YXRpb24gc2VydmVyOiBhIGNv bnN0cmFpbmVkIGRldmljZT8NCj4gDQo+IEhpIE9sYWYsDQo+IA0KPiB0aGFua3MgZm9yIHNoYXJp bmcgeW91ciB2aWV3cy4NCj4gDQo+IFRoZSBkaXNjdXNzaW9ucyBiZWZvcmUgdGhlIEJPRiBoYXBw ZW5lZCBpbiBhIHJhdGhlciBzbWFsbCBncm91cCAobW9zdGx5DQo+IG9mZmxpbmUpIGFuZCBub3cg d2UgaGF2ZSBhIGxhcmdlciBhdWRpZW5jZSBhbmQgc28gaXQgc2VlbWVkIHRvIGJlIGZhaXIgdG8N Cj4gcmUtc3RhdGUgdGhlIHF1ZXN0aW9uIGFnYWluIChwYXJ0aWN1bGFybHkgYWZ0ZXIgcmVhZGlu ZyBTYW0ncyBlbWFpbCkuDQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0KPiANCj4gDQo+IE9uIDAzLzEz LzIwMTQgMDQ6MjcgUE0sIE9sYWYgQmVyZ21hbm4gd3JvdGU6DQo+ID4gSGFubmVzIFRzY2hvZmVu aWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyaXRlczoNCj4gPg0KPiA+PiByZWFkaW5n IHRocm91Z2ggU2FtJ3MgZW1haWwgYW5kIHZhcmlvdXMgY29tbWVudHMgZHVyaW5nIHRoZSBCT0Yg SSB3YXMNCj4gPj4gd29uZGVyaW5nIHdoZXRoZXIgdGhlIGdyb3VwIGhhcyBhIGNvbnNlbnN1cyB0 byBhc3N1bWUgdGhhdCB0aGUNCj4gPj4gYXV0aG9yaXphdGlvbiBpcyBub3QgYSBjb25zdHJhaW5l ZCBkZXZpY2UuDQo+ID4NCj4gPj5Gcm9tIHdoYXQgSSB0b29rIGZyb20gdGhlIGRpc2N1c3Npb25z IHNpbmNlIHRoZSBCZXJsaW4gSUVURiB0aGF0DQo+ID4gZXZlbnR1YWxseSBsZWQgdG8gdGhlIEFD RSBCb0YsIEkgYWx3YXlzIGhhZCB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZQ0KPiA+IEF1dGhvcml6 YXRpb24gU2VydmVyIGlzIHJlZ2FyZGVkIGFzIG5vdCBjb25zdHJhaW5lZCBpbiBub24tdHJpdmlh bA0KPiA+IHVzZS1jYXNlcy4NCj4gPg0KPiA+IEdydWVzc2UNCj4gPiBPbGFmDQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEFjZSBt YWlsaW5nIGxpc3QNCj4gPiBBY2VAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiA+DQoNCg== From nobody Fri Mar 14 00:10:45 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18031A0068 for ; Fri, 14 Mar 2014 00:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07dxZtMSqwRg for ; Fri, 14 Mar 2014 00:10:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B915B1A005C for ; Fri, 14 Mar 2014 00:10:39 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MLR30-1WNo1Y0pc2-000a42; Fri, 14 Mar 2014 08:10:10 +0100 Message-ID: <53220F15.9070705@gmx.net> Date: Thu, 13 Mar 2014 21:03:33 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Rahman, Akbar" , Phil Hunt References: <53210A20.6090709@gmx.net> <5321E32C.2040706@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HULqnV8xeaqq7hIGV2wpbsqD9eSupC0F8" X-Provags-ID: V03:K0:C6jHrlYHLLOifzjHRvPqqCQLG/uUOJqpe4sZghkZf9g1Y9LvJ2L ubGliUwnrnOmPea4fQJaA+BO9koEde3fbitQ4z6sEkrelKTyUi/17UfdzfUBZXzJNeFfGOK +qAMiQfwbdlnWnjSZRvzv9Dq1Fz751S7I4b3aU0PsGB9eYkTBsf0VFU9TeaJt5u/n1sTPoU JT81VjrLUSOK/1TKbRUJA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/enk1Kr5u1cH_h_ROvoS14cXPr-I Cc: ace@ietf.org Subject: Re: [Ace] When to deal with proxies? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 07:10:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HULqnV8xeaqq7hIGV2wpbsqD9eSupC0F8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Very good point since I am wondering now myself how a CoAP client authorizes the server when there is a CoAP proxy along the way. When I read through the security consideration section of the CoAP spec it just said that you compare the identifier used for the look-up with the one found in the certificate but unless the CoAP client knew about the proxy up-front this check will fail. If the CoAP client knew about the proxy then, in DTLS terms, it is actually treating the proxy as the server. Needless to say that this would be useless for the work we are doing in this group since the information would just be with the wrong party. Ciao Hannes On 03/13/2014 08:57 PM, Rahman, Akbar wrote: > Hi Hannes, >=20 >=20 >> I think proxies should be discussed up front. I'm not a big fan of > them, so discussing why we think we need them seems important. >=20 > I agree with this point from Phil. And it overlaps with the point that= > I previously brought up regarding extensive support of proxies in the > current CoAP spec: >=20 > http://www.ietf.org/mail-archive/web/ace/current/msg00360.html >=20 >=20 > Since neither Zach/Carsten (i.e. CoAP experts) have responded yet, I > would like to draw your attention to the following section of the CoAP > spec which specifically discusses CoAP Proxies and DTLS. Please see > especially the 3rd paragraph which refers specifically to "access > control considerations": >=20 > http://tools.ietf.org/html/draft-ietf-core-coap-18#section-11.2 >=20 >=20 >=20 >=20 > Best Regards, >=20 > Akbar >=20 >=20 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, March 13, 2014 12:56 PM > To: Phil Hunt > Cc: ace@ietf.org > Subject: Re: [Ace] When to deal with proxies? >=20 > Thanks for your feedback, Phil. >=20 > Dual-protocol endpoints might be a bit challenging for some of the > devices that folks have in mind. CoAP was developed since there was the= > believe HTTP stacks do not fit on some of these very constrained > devices. Telling these people now that they should now add HTTP to it > because of interworking with legacy infrastructure might make them jump= > up-and-down. >=20 > Ciao > Hannes >=20 >=20 > On 03/13/2014 05:54 PM, Phil Hunt wrote: >> I think proxies should be discussed up front. I'm not a big fan of > them, so discussing why we think we need them seems important. >> >> My belief is that dual-protocol endpoints rather than gateways/proxies= > is what will be simplest and most secure.=20 >> >> But again, discussion will bring out what we mean by proxy and what > the benefits are. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On 2014-03-12, at 6:30 PM, Hannes Tschofenig > wrote: >> >>> Hi all, >>> >>> Goeran raised a question in the charter discussion about when to=20 >>> investigate suitability of the solution regarding proxies. >>> >>> With version 0.5 of the charter I suggested to explore the proxy=20 >>> issues* after a candidate solution had been selected. >>> >>> He suggested, however, to deal with proxies already during as part of= >=20 >>> the requirements/use case/design considerations phase. >>> >>> What would you like to do? >>> >>> Ciao >>> Hannes >>> >>> PS: We discussed various types of proxies on the list. Some proxies=20 >>> were protocol translation proxies that provided the ability to=20 >>> interface with other protocols (e.g., HTTP) and deployed=20 >>> infrastructure (some backend authentication/authorization=20 >>> infrastructure) and yet other proxies were part of the CoAP protocol.= >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --HULqnV8xeaqq7hIGV2wpbsqD9eSupC0F8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIg8VAAoJEGhJURNOOiAtSXkH/A79RGGl1Uf5svR+0x0EuDoU b3HN1v9UAAZu1lYtQfeMugPKR43o8chugWhuGyvWysEbHB/1gwPevld+18amdb/O VbuyKX191r/AaczT6yR6zPoKrMTCuumsQ3hdZsMUz+rDyQ6Po0mH7hS2MDIyCAMd E0UD3bwHQyVi2piRPMQi/sg1hxTA/EDWjQbvUKTVl+ItoWpxlibPVUi7EBiQRpHs Tva4aIAwk0u67ABDCQGjEw8NTCTp8IvApusUwhc75Q8ORTM1+l1P7r1mb31aSPZl zVgeuvAy0sBbkpqsa34PsvxebhNojC7ufVn1fnXqgZmOr/TiJMkw/ZqlwdAagTU= =lwhT -----END PGP SIGNATURE----- --HULqnV8xeaqq7hIGV2wpbsqD9eSupC0F8-- From nobody Fri Mar 14 00:24:54 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7321A008B for ; Fri, 14 Mar 2014 00:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.885 X-Spam-Level: * X-Spam-Status: No, score=1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXmkEM77VoP9 for ; Fri, 14 Mar 2014 00:24:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 45BCC1A0059 for ; Fri, 14 Mar 2014 00:24:51 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MEo4s-1WLaFP205K-00G1pU; Fri, 14 Mar 2014 08:24:41 +0100 Message-ID: <5322127D.6080101@gmx.net> Date: Thu, 13 Mar 2014 21:18:05 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Likepeng , Olaf Bergmann References: <5321B255.3070801@gmx.net> <87eh26glu6.fsf@tzi.org> <5321D7D5.2000503@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B04A12@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B04A12@SZXEMA501-MBS.china.huawei.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KLfkeuedH0CJoOeHx5dxU4tj2nIVQaQFh" X-Provags-ID: V03:K0:wK59XvM+FyU5yexx4TByK/ZM+r0/NoBvhagsiSvV0LUx7/rQbLq vXsSZUsFlHD309fqvL6Z8SAjBhVwzyyu5E33nTf3tBGKCQxOetB2snubQ/JYLdvg+VZW94+ QhOhELSlFIxtti42HNcx0uFPNAIFMHlDKwD4BRVIRmLj6LMhoiVuoSckozDU3Peq72HRv6z APgepmX49wtFu5t5WJaEw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Qtp2zmtjRyK61b6VPypwbfRBdoc Cc: "ace@ietf.org" Subject: Re: [Ace] Authorization server: a constrained device? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 07:24:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KLfkeuedH0CJoOeHx5dxU4tj2nIVQaQFh Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable There is still a lot of benefit since it allows to centrally manage authorization, which is from a usability point of view a big plus. Today, with the pairing approach you need to introduce each device to any other device (leading to the handshake problem with n(n-1)/2 combinations). Having said that I am fine with just assuming that the authorization server is not constrained. Ciao Hannes On 03/14/2014 07:43 AM, Likepeng wrote: > If Authorization Server is also constrained, there is no much benefit t= o have it in the architecture. >=20 > Kind Regards > Kepeng >=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Ace [mailto:ace-bounces@ietf.org] =B4=FA=B1=ED Han= nes Tschofenig >> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA3=D4=C214=C8=D5 0:08 >> =CA=D5=BC=FE=C8=CB: Olaf Bergmann >> =B3=AD=CB=CD: ace@ietf.org >> =D6=F7=CC=E2: Re: [Ace] Authorization server: a constrained device? >> >> Hi Olaf, >> >> thanks for sharing your views. >> >> The discussions before the BOF happened in a rather small group (mostl= y >> offline) and now we have a larger audience and so it seemed to be fair= to >> re-state the question again (particularly after reading Sam's email). >> >> Ciao >> Hannes >> >> >> On 03/13/2014 04:27 PM, Olaf Bergmann wrote: >>> Hannes Tschofenig writes: >>> >>>> reading through Sam's email and various comments during the BOF I wa= s >>>> wondering whether the group has a consensus to assume that the >>>> authorization is not a constrained device. >>> >>> >From what I took from the discussions since the Berlin IETF that >>> eventually led to the ACE BoF, I always had the impression that the >>> Authorization Server is regarded as not constrained in non-trivial >>> use-cases. >>> >>> Gruesse >>> Olaf >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --KLfkeuedH0CJoOeHx5dxU4tj2nIVQaQFh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIhJ9AAoJEGhJURNOOiAtEGoH/iq6BAnHfuGVczzjr6Zu3T1m A0MtWaW+iLkzNpuK8e9nQrqWsphZhiEdosh+5dGMelXipfVi4DpszOAO2IWXTSt1 fQADQYusY8X76hfgQawL3fkXyliXAcHbwB8hLR+sFpORPoKxKf+n64th+V5ovQz4 KpJz2np3YJ4Yyrtp0U1zn1dq88rfLnkv+axES1BAXYnlCaqMI89zUSP3rw5GQnVB STcymycDWlSLVMVPxwXjGqg+J0W+7xuOG/3am5SN9c4AOmXNsv0edqzNunrUKxgW oVu0BElORKlx/uNSamHcHDk9OVnLwuSPCFkpbDksNHzOcLXEJ+LnjLUMz7BRWNE= =Jcr5 -----END PGP SIGNATURE----- --KLfkeuedH0CJoOeHx5dxU4tj2nIVQaQFh-- From nobody Fri Mar 14 01:31:09 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934731A00AD for ; Fri, 14 Mar 2014 01:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N5ykIC8EDh5 for ; Fri, 14 Mar 2014 01:31:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0C91A00A6 for ; Fri, 14 Mar 2014 01:30:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-42-5322be3c6ebd Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 56.43.10875.C3EB2235; Fri, 14 Mar 2014 09:30:52 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 09:30:52 +0100 From: =?windows-1254?Q?G=F6ran_Selander?= To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] ACE Charter - connectivity assumptions Thread-Index: AQHPPQv384KEX3YIRUSd5/kxwiLycZrd45yAgAJhtoA= Date: Fri, 14 Mar 2014 08:30:52 +0000 Message-ID: References: <5320CCD5.2040006@gmx.net> In-Reply-To: <5320CCD5.2040006@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="windows-1254" Content-ID: <44585436A87C264085EBD8CFE8500EDA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvja7NPqVgg5MrzC2+f+thtli68x6r A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJXxb8smpoK12hUHfuU2MH5X6mLk5JAQMJF4 tugZC4QtJnHh3nq2LkYuDiGBQ4wSczrOsUA4Sxgl1vR3s4JUsQm4S8zZuxKsQ0QgSOJw42s2 EFtYwFJiya39zBBxK4kLK++zwtgNU+4xgtgsAqoSa24uYQexeQXMJX6s+wI2R0ggRGL9nCVg vZwC6hJ73/8DizMCXfT91BomEJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B/YLlEBPYl7j+ZC faMocXX6cqheA4kj526yQtjWEutXTGSDsLUlli18zQxxj6DEyZlPWCYwis9Csm4WkvZZSNpn IWmfhaR9ASPrKkb23MTMnPRyw02MwJg6uOW37g7GU+dEDjFKc7AoifN+eOscJCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoHR4iZXy9XNh+reiUXrtvWbSW2yPrJqwj+jRwsT/YX8zrczfIye cK34kfSBDWXHkr9x7n6/Y9lGrr7NbU+uKf1kL5iz6LOaPOtPNV2JWX2sK3dmBy3ZeTK7MPah R/ClNQ1GmTwlh4oynmcfLH9gr7+3mM1QufT3FGXLpVJ9Kc9Yly6453jAn+OIEktxRqKhFnNR cSIAhPvQWHcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fmnEn0A8Vrb05F3x4cMh8GJ0iT8 Subject: Re: [Ace] ACE Charter - connectivity assumptions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 08:31:06 -0000 Hi Hannes Good questions.=20 A general comment: I think this is largely a question of mindset. If we assume constant connectivity for all devices at no cost, we will come up with a different solution than if we assume that there is a non-negligable cost. (With =93cost=94 including: fees to connectivity provider, configurat= ion in network and/or device to enable connectivity, performance aspects of constrained devices such as battery life time etc.) In some applications it may be feasible to make a trade off between e.g. immediate revocation and cost. More inline. On 12/03/14 22:08, "Hannes Tschofenig" wrote: >Hi Goeran, > >thanks for moving this difficult point forward. > >Comments inline. > > >On 03/11/2014 10:26 AM, G=F6ran Selander wrote: >>=20 >> During the BOF it was requested to be more specific about the >>connectivity >> assumptions of the various nodes, more specifically whether it could be >> assumed that the RS or the Client could connect to the AS. The >>discussion >> was very focused on the particular use case presented at the BOF. Here >>are >> some starting points for further discussion. >>=20 >> 1. The discussion relates to Client or RS connectivity to the AS for >> obtaining relevant authorization information. If valid authorization >>info >> is already available to the RS, it should not be necessary to connect to >> the AS.=20 > >Yes, if the authorization information + keying material is already >cached then it does not need to be retrieved again. > >There is, however, a trade-off when it comes to revocation: the longer >you are able to cache the more difficult it will be to quickly revoke. Agree=20 > >>=20 >> 2. It was acknowledged that in the particular use case (container >> transport at sea) Internet connectivity could not be assumed. Even if >>this >> hadn=B9t been the case, e.g. truck/train transport or other use case, we >> should not take for granted that billions of devices are always >>connected >> just because it is theoretically possible. Internet connectivity has a >> cost and low cost is one of the reasons why constrained devices are at >>all >> used. There may be some need for configuration needed to secure >> connectivity, which may be missing if the environment changes as was >> illustrated by the use case. Etc. . With this in mind, we should assume >> that for certain use cases the constrained Client or RS may be >> disconnected from the Internet for periods of time. > >What about having connectivity to an authorization server that is on >board the ship? To translate this to the home networking case you it is >one thing to assume connectivity to some server on the Internet and a >different aspect to assume connectivity to an authorization in the >user's home network. Yes, that is the smartphone / home server case I mention below. Both options (cloud AS or local AS) are possible. The case of local AS temporarily without Internet connectivity would be able to serve RS with missing access policies, but if the Resource Owner need to update its policies, the local AS would need Internet connectivity (unless the RO is also =93on board=94).=20 I think we should allow different service providers to decide on different architectures to address their respective need for prompt access, immediate revocation etc. > >Needless to say with your assumption is that if you do not have Internet >connectivity then some value of Internet connected devices (e.g., remote >monitoring, remote configuration) goes away. Agree. > >>=20 >> 3. Even if the AS is not a constrained device it may be disconnected >>from >> time to other. For some use cases, AS functionality may be implemented >>in >> devices which are not always available, e.g. the Resource Owner=B9s >> smartphone, home server or some other device which may be occasionally >> switched off or disconnected. > >Do we accept the side effect that the solution will not work in some of >those cases? If there is no information cached at client<->RS then >without connectivity to the AS the entire mechanism will not work. Again, there are trade-offs to make. We could allow this, if it can be made clear what the consequence is. Alternatively we could assume there must be a local AS available, which however may not always be connected to the Internet. > > >> In general we should assume that Client and RS may have intermittent >> connectivity with the AS, and in particular that it cannot be >>guaranteed >> that there is connectivity to the AS at the time of the access request. > >You are saying that with some requests you assume there is connectivity >and with other requests there isn't. That does not sound right to me. Let me say it in fewer words: At the time of the C->RS access request it cannot be guaranteed that C or RS can access AS. (If we allow this, see above.) > >The client / RS needs to obtain authorization information and keying >material from the AS. They also need to peridically check the revocation >status. They are also likely to require time information. >This will not work without some level of connectivity. Yes, time was brought up in the BOF. Let=92s make that a separate thread. G=F6ran > >Ciao >Hannes > >>=20 >>=20 >> G=F6ran >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 From nobody Fri Mar 14 03:57:04 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3CE1A0125 for ; Fri, 14 Mar 2014 03:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwSzIR4wrS7v for ; Fri, 14 Mar 2014 03:57:00 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan22.extendcp.co.uk [176.32.226.68]) by ietfa.amsl.com (Postfix) with ESMTP id 67BE91A0122 for ; Fri, 14 Mar 2014 03:56:59 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WOPnH-0004NJ-IF; Fri, 14 Mar 2014 10:56:51 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WOPnG-00056B-Sz; Fri, 14 Mar 2014 10:56:51 +0000 Received: from host86-149-120-43.range86-149.btcentralplus.com ([86.149.120.43] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WOPnF-0000PK-6s; Fri, 14 Mar 2014 10:56:49 +0000 Message-ID: <5322E0A4.90606@gridmerge.com> Date: Fri, 14 Mar 2014 10:57:40 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hannes Tschofenig , ace@ietf.org References: <5317357B.6020407@gmx.net> <625803CB-22FE-49A7-9ACE-03115E98C050@gmail.com> <7540.1394293121@sandelman.ca> <531F6CBF.2000600@gridmerge.com> <531F6730.3050604@gmx.net> In-Reply-To: <531F6730.3050604@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070701070500050709030803" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/S3Do-w1hYvzyVz4-AEcm6qoSSco Subject: Re: [Ace] Scope of the ACE Charter X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 10:57:03 -0000 This is a cryptographically signed message in MIME format. --------------ms070701070500050709030803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, Comments inline. Robert On 11/03/2014 7:42 PM, Hannes Tschofenig wrote: > Goeran, Robert, > > Here is the challenge (based on my experience from OAuth): > > 1) You need to tie the application layer security to the channel > security since otherwise you introduce attacks. Yes, if you are relying on the security properties of the channel.=20 A proxy is a MITM so I would imagine in that case, that reliance cannot=20 be assumed therefore application layer/object security would need to=20 provide its own end-to-end protection > > 2) You need to tie the application layer security to the actual request= =2E > Doing protocol translation in-between makes this somewhat challenging. Agreed; I would not expect translation to occur > > My fear is that while it sounds like a nice idea to do this protocol > translation it makes the entire security story brittle and more complex= =2E > > I am fine with investigating these proxy cases but we shouldn't be > astonished if they do not work in the way we had hoped. Agreed. My understanding of G=F6ran's concept of "object security" is tha= t=20 there is no translation at the application layer. This certainly=20 complicates the model, as there are now layers within layers but I have=20 come across this situation a number of times and has to find a solution=20 for it. Maybe it is not necessary to consider these cases in detail from the=20 get-go but simply to bear them in mind when it comes to developing=20 solutions. > > Ciao > Hannes > > PS: The term 'trusted' and 'untrusted' intermediary is somewhat fuzzy. > As I stated earlier this year on this mailing list, you have to indicat= e > WHO trust WHOM for WHAT. > > On 03/11/2014 09:06 PM, Robert Cragie wrote: >> My view is generally that interface II will typically be CoAP/DTLS but= >> could easily be HTTP/TLS and from the point of view of provisioning >> credentials and access right information, I can't see there would be a= >> huge difference. >> >> I am ambivalent regarding I and III from a >> transfer/transaction/transport protocol point of view but I echo G=F6r= an's >> view on considering object security to achieve end-to-end security >> through proxies, plus it would of course still work if directly >> connected. An alternative approach which could be considered for proxi= es >> is the ability to tunnel through proxies. This might be useful for >> reusing existing auth/z protocols through proxies. >> >> Robert >> >> On 10/03/2014 9:00 AM, G=F6ran Selander wrote: >>> Hi Michael >>> >>> Just on untrusted intermediaries: >>> >>> Since the AS needs to protect certain information end-to-end =8B e.g= =2E >>> authorisation information to be consumed by the RS, key management >>> information to be consumed by the Client =8B hop-by-hop transport lay= er >>> security would not be sufficient. This case could be handled with obj= ect >>> secure information (some sort of ticket/access token) integrity prote= cted >>> or encrypted on application layer. As the secure object can't be chan= ged >>> by an intermediary, it need to be formatted for transfer to the inten= ded >>> consumer already by the AS, which in particular may need to take into= >>> account a constrained environment. >>> >>> >>> G=F6ran >>> >>> >>> >>> On 08/03/14 16:38, "Michael Richardson" wrote= : >>> >>>> This is what I understand about the concern about scope. >>>> (Gotta love emacs picture-mode... outlook users will need a fixed fo= nt) >>>> >>>> >>>> +---------------+ >>>> | Authorization | >>>> +------------------+-------->| Server | >>>> | (I) / +---------------+ >>>> | authz / ^ >>>> | / | >>>> /--------\ / | >>>> (IV) | oauth | / | III >>>> | proxy | / | authz >>>> \--------/ / | >>>> |----------/ | >>>> v v >>>> +-----------+ (access) +-----+-----+ >>>> | | /------\ (II) | Resource | >>>> | Client | <...|https/|.......>| Server | >>>> +-----------+ | coap | +-----------+ >>>> | dtls | >>>> |proxy | (V) >>>> \------/ >>>> >>>> =3D=3D=3D=3D >>>> >>>> IV - is some kind of translator that can take/process OAUTH2 (or som= e >>>> other system!) requests into our authorization protocol. It m= ight >>>> be that teaching the authorization server itself to speak OAUT= H2 >>>> is really the only answer, and that would be fine with me. >>>> >>>> V - this is an HTTPS(with OAUTH2 token) to COAP/DTLS (with ACE token= ) >>>> proxy. >>>> >>>> It would be nice if (V) did not have to have god/superuser access to= the >>>> authorization server. I.e. it would be nice if that proxy could be >>>> untrusted >>>> by both the client and the authorization server. >>>> >>>> Does this diagram match what others have been asking about? >>>> (I have intentionally left out the SEP2.0 stuff out of this diagram,= >>>> as I >>>> have no idea what it uses for authorization) >>>> >>>> --=20 >>>> Michael Richardson >>>> -on the road- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> --------------ms070701070500050709030803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMTQxMDU3NDBaMCMGCSqGSIb3DQEJBDEWBBQBDwqrlSap8VFPguz8ODoXZKCWszBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAGdS/+lITSEQ80TfwZUy17r89+5oAUulCNuDfids+Uu6kmt2 oZ9dQH10s67WdoCO1ErEhDmNQmo7jKpR6Ddhbp5miEABEOCoy2u7PVs0uOb/dpqDLrK6j455 /7HGLZDP+IbKW6IuCoIMDQ8VFC3Bqplp0coREWWs+ASFk1QbzC+yhiw9/XUP3jNDg1Ohz0Rn Gt77bEXRbtAsYcl1qa3WD7d61HQxyqTbPIbgxgEnZN9i3+Mhhh+h1upOaA9naeCyAXfkNd5d p7GmTJ5mAwue0/gRxcE0FRKhAEvXyqlYJN4AhphCyz1Nhv+UsSoehwkMeFBtRgEhdEnuBYMq H2OMw+cAAAAAAAA= --------------ms070701070500050709030803-- From nobody Fri Mar 14 04:02:52 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAB01A0119 for ; Fri, 14 Mar 2014 04:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjizX9ZoWAEu for ; Fri, 14 Mar 2014 04:02:47 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09B1A0110 for ; Fri, 14 Mar 2014 04:02:46 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-e5-5322e1cf24b3 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4E.A3.23809.FC1E2235; Fri, 14 Mar 2014 12:02:39 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 12:02:39 +0100 From: =?windows-1254?Q?G=F6ran_Selander?= To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] Design Consideration Document as one milestone? Thread-Index: AQHPPrewRMKjLCAMGkyGQgBzpjAjyZrfHJ+AgAABaQCAAU5cgA== Date: Fri, 14 Mar 2014 11:02:38 +0000 Message-ID: References: <53210566.60100@gmx.net> <5321D764.5010000@gmx.net> In-Reply-To: <5321D764.5010000@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje75h0rBBjN2GFt8/9bDbLF05z1W ByaPxZv2s3ksWfKTKYApissmJTUnsyy1SN8ugSuj79ontoJzOhVfHk5hb2BcqNLFyMkhIWAi sWbBVzYIW0ziwr31QDYXh5DAIUaJidNvMEE4Sxgl9nZcYgGpYhNwl5izdyWYLSIQJHG48TVY t7CAk8Ta97PZIeLOEosPLmGEsJ0kTm48BBZnEVCV6HzyAGgoBwevgLnEr5NgRwgJ5Eo0NJ8F G8MpoC4x5c1hZhCbEeig76fWMIHYzALiEreezGeCOFRAYsme88wQtqjEy8f/WEFsUQE9iXuP 5rJAxBUlPr7axwjRayBx5NxNVgjbWuLfg49QcW2JZQtfg83hFRCUODnzCcsERvFZSNbNQtI+ C0n7LCTts5C0L2BkXcXInpuYmZNebrSJERhTB7f8Vt3BeOecyCFGaQ4WJXHeD2+dg4QE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwilfNd6l0jF9b1/Vnstuj3WYtbGasDW5ME/nrW9/cUXuy 3axb95Wqmd13V/UpW4X2T7SuWGe+6ZmG1PQFM1ccXDgr7qWGwcdLkrfZTrApbbN6OnVZ1vyu givT+y7aia1frlm13qtf7fIVHi1/39tXHD6d9dX5aGj6tNHn9NeHIVMYmD6FqSZeUGIpzkg0 1GIuKk4EAHm69K13AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ekTc6-IIG44hCIm2A9dtH_4LE0g Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 11:02:50 -0000 Hi Hannes More good comments. There are two things here: 1. One is to describe how properties of a security protocol impact the "performance=94 of constrained devices in scope of this work, and what trad= e offs are possible. 2. The other is to list and motivate assumptions and design choices made in the work to select/profile the security protocol to be made by this group. The motivations in 2. should be based on the understanding to the properties in 1. Whether we need to actually document 1. or not depend on if we assume that people who will review 2 have this knowledge. While we cannot optimise the protocol for each given system, I claim that there is some basic knowledge about constrained devices which may speak for/against certain protocol candidates. Maybe we should have tutorials on this too? I think Klaus=92 draft on practical issues with DTLS, although not speaking about security protocols in general, is a good starting point: http://tools.ietf.org/id/draft-hartke-dice-practical-issues-00.txt More comments inline On 13/03/14 17:05, "Hannes Tschofenig" wrote: >Hi Goeran, > >you raise another difficult question that relates a bit to the type of >IoT devices have in mind. I fully agree with the challenge you >identified regarding symmetric vs. asymmetric key crypto. It will be >difficult to reach a consensus on that topic since most people in the >group are actually not building devices themselves and therefore just >use what fits their solution best. > >The cost of transmission that you mention is also important but the >implication of just having fewer round-trips is a bit too simplistic >since a constrained resource server will obviously suffer a lot since he >has to listen for incoming connection attempts. Yes, round trips is too simplistic, e.g. size of messages has a large impact too considering fragmentation. Even =93listening" is too simplistic, since there are various aspects of discontinuous reception, low-power listening etc. So what can we say? There is expertise on specific platforms and although there may be differences, my expectation is that there is some common features like e.g. the cost for communication vs symmetric crypto in a security protocol. G=F6ran > >So, I fear that (while these are super important aspects) we will have a >hard time to make any useful decisions about them is two-fold: > > * We are not designing complete systems in the IETF and the energy >assumption relates to the overall system (rather than a single >protocol). Most of it is outside the IETF protocol design. > > * The processing capability obviously depends on the hardware and we >are not making any statement about hardware in the group. Looking at >Carsten's presentation from the BOF it also relates to cost, which is >again a very complicated topic since hardware cost is not the only cost >in product development. > >The classes in the LWIG terminology document do not go into any level of >details regarding computational power and energy consumption. Only the >memory requirements are listed in more detail and they seem to be rather >hand-wavy. > >Ciao >Hannes > > >On 03/13/2014 04:00 PM, G=F6ran Selander wrote: >> Hi Hannes >>=20 >> Thanks for bringing this up. Let me give some context. >>=20 >> In the preparation for the BOF (and as was later shown in the BOF) it >>was >> clear that there are strong opinions about the (in)feasibility of >>/public >> key/ crypto in constrained devices. Some people state that =B3there will >> only be two public key operations in the lifetime of this device=B2, >> referring to the high cost for asymmetric crypto so that they are only >> used to establishing secret keys that are used thereafter. Yet other >> people state =B3the cost for public key crypto is negligable in today=B9= s >> devices=B2=20 >>=20 >> Looking into the literature it is clear that public key crypto is in >>many >> cases affordable, but also that it does not come for free. Moreover, >>when >> comparing e.g. with message transmission and reception in wireless >> embedded devices, you get another picture what may be expensive in >> security protocol execution from an energy consumption point of view. >> Section 3.2.2 discusses this in a symmetric crypto context. >>=20 >> This draft was put together in a rush a few days before cutoff and >> contains mainly obvious things. As said, I=B9m happy to use this as a >>basis >> for a Wiki or restart the discussion. What I would like to see >>documented >> is the (non-obvious) cost comparisons and trade-offs between e.g. >> round-trips and crypto operations, symmetric vs asymmetric operations >>etc. >> to be able to refer to in future discussions when we need to assess the >> feasibility of a particular security protocol in a constrained >>environment. >>=20 >>=20 >> G=F6ran >>=20 >>=20 >> On 13/03/14 02:09, "Hannes Tschofenig" >>wrote: >>=20 >>> Goeran raised a question about adding a milestone for a document that >>> captures assumptions and design criteria. >>> >>> He contributed an initial version of such a document with >>> https://tools.ietf.org/html/draft-seitz-ace-design-considerations-00 >>> >>> What does the rest of the group think about that idea? >>> >>> Would you be willing to review such a document? >>> Would you be willing to contribute to such a document? >>> >>> Ciao >>> Hannes >>> >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 > From nobody Fri Mar 14 05:55:59 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B04F1A0135 for ; Fri, 14 Mar 2014 05:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOUCJcQ68Wnu for ; Fri, 14 Mar 2014 05:55:51 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 79C111A0103 for ; Fri, 14 Mar 2014 05:55:51 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id w8so2396146qac.41 for ; Fri, 14 Mar 2014 05:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=rOMsP9tLKBEiKGqpmnxkjBCShdZc0EZrsFwG1vr7jJ8=; b=zjpuys8AlFlQ9vG3Au+JGELnecoSMMrO03iKvHRcGtFTG5Zc0WZTaKFqydDBaM7MTc mG2B9bdk9FqR9E+eUdIeGf4YOYLyS84SnuLFNnV3JgZce2SfoJ9M/lD7YiqeRlddo+qr HcJMGXkCnqYYYi8Ev4a8B2/6j2QpnIAta7B/bG43jRaEOO+VL0uR7hnU6tz6gTtUNRc1 8PUJ7mOuI3zZW9eLzJaXVbjMhGUUIXTnJ2xUoX1YffOaWKCUQKtx+4LI+JTsUrKHnz/S n+BnJOChZArS3ohvTViUWN5NcsLUUYlVQlu/R1GzEpmYwv4NBTxIdDLyrGrPdCxk8Bwq BWvw== X-Received: by 10.224.36.18 with SMTP id r18mr9645361qad.74.1394801744593; Fri, 14 Mar 2014 05:55:44 -0700 (PDT) Received: from new-host.home (pool-108-7-235-60.bstnma.fios.verizon.net. [108.7.235.60]) by mx.google.com with ESMTPSA id u7sm15928465qap.5.2014.03.14.05.55.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 05:55:44 -0700 (PDT) From: Margaret Wasserman Content-Type: multipart/alternative; boundary="Apple-Mail=_3BDFC2F4-41FE-4CDE-9015-D5E65263C9EF" Message-Id: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> Date: Fri, 14 Mar 2014 08:55:50 -0400 To: "ace@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/CafaX9A6c9Ysv_0rJemyAOu4svg Subject: [Ace] Constrained Authorization Server? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 12:55:53 -0000 --Apple-Mail=_3BDFC2F4-41FE-4CDE-9015-D5E65263C9EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In an offline discussion, I was asked whether I think the ACE effort = should consider situations where the Authorization Server is a = constrained node. I wrote the following answer, and I thought it might = be useful to share it here: > I think that depends on what you mean by "constrained". I don't think = an authorization server needs to have a user input device, necessarily=85 = It could be embedded in a home gateway, or a building control system or = an irrigation controller. However, i don't think that you will want to = have a battery-operated, intermittently connected authorization server, = because it might not be available when the client and server want to = talk to one another. >=20 > If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier. :-) >=20 > I see the point of this effort as figuring out how the bulk of those = operations can be handled by a less-constrained server that is storing = the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes. >=20 > So, no, I don't think of the authorization server as being a = constrained node in the same sense as battery-operated sensors, = actuators, etc. Margaret= --Apple-Mail=_3BDFC2F4-41FE-4CDE-9015-D5E65263C9EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I think that depends on what you mean = by "constrained".  I don't think an authorization server needs to = have a user input device, necessarily=85  It could be embedded in a = home gateway, or a building control system or an irrigation controller. =  However, i don't think that you will want to have a = battery-operated, intermittently connected authorization server, because = it might not be available when the client and server want to talk to one = another.

If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier.  :-)

I see the point of this effort as figuring out how the bulk = of those operations can be handled by a less-constrained server that is = storing the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes.

So, no, I don't think of the = authorization server as being a constrained node in the same sense as = battery-operated sensors, actuators, = etc.
Margaret
= --Apple-Mail=_3BDFC2F4-41FE-4CDE-9015-D5E65263C9EF-- From nobody Fri Mar 14 06:06:31 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92961A0151 for ; Fri, 14 Mar 2014 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asxkaLs1VYLV for ; Fri, 14 Mar 2014 06:06:03 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC991A013B for ; Fri, 14 Mar 2014 06:06:02 -0700 (PDT) Received: from [10.0.1.55] ([99.110.37.26]) by p3plsmtpa09-06.prod.phx3.secureserver.net with id dR5s1n00F0ZqqBn01R5tVe; Fri, 14 Mar 2014 06:05:55 -0700 From: Pat Kinney Content-Type: multipart/alternative; boundary="Apple-Mail=_92FE66B0-3C06-4D51-A148-2C16BD11680E" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Fri, 14 Mar 2014 08:05:51 -0500 References: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> To: "ace@ietf.org" In-Reply-To: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/AeB_hBh50F1eBr8OUJYLHkRzVFQ Subject: Re: [Ace] Constrained Authorization Server? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:06:19 -0000 --Apple-Mail=_92FE66B0-3C06-4D51-A148-2C16BD11680E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree with Margaret's analysis with one exception, what about an = emergency situation where mains power has been lost? A network of = battery-powered devices could be providing a critical service, so the = Authorization Server might be on a short-lived UPS. In this case it = could be considered "constrained". Given this, is it reasonable to = expect the network to continue operating without the authorization = server? I.E. in an established network can the Authorization Server be = intermittent? Pat Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 pat.kinney@kinneyconsultingllc.com On Mar 14, 2014, at 7:55 AM, Margaret Wasserman = wrote: In an offline discussion, I was asked whether I think the ACE effort = should consider situations where the Authorization Server is a = constrained node. I wrote the following answer, and I thought it might = be useful to share it here: > I think that depends on what you mean by "constrained". I don't think = an authorization server needs to have a user input device, necessarily=85 = It could be embedded in a home gateway, or a building control system or = an irrigation controller. However, i don't think that you will want to = have a battery-operated, intermittently connected authorization server, = because it might not be available when the client and server want to = talk to one another. >=20 > If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier. :-) >=20 > I see the point of this effort as figuring out how the bulk of those = operations can be handled by a less-constrained server that is storing = the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes. >=20 > So, no, I don't think of the authorization server as being a = constrained node in the same sense as battery-operated sensors, = actuators, etc. Margaret _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_92FE66B0-3C06-4D51-A148-2C16BD11680E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree with Margaret's analysis with one exception, what about an = emergency situation where mains power has been lost?  A network of = battery-powered devices could be providing a critical service, so the = Authorization Server might be on a short-lived UPS.  In this case = it could be considered "constrained".  Given this, is it reasonable = to expect the network to continue operating without the authorization = server?  I.E. in an established network can the Authorization = Server be intermittent?

Pat

Pat Kinney
Kinney = Consulting LLC
IEEE 802.15 WG vice chair, TG = chair
ISA100.11a WG chair
O: = +1.847.960.3715

I think that depends on what you mean = by "constrained".  I don't think an authorization server needs to = have a user input device, necessarily=85  It could be embedded in a = home gateway, or a building control system or an irrigation controller. =  However, i don't think that you will want to have a = battery-operated, intermittently connected authorization server, because = it might not be available when the client and server want to talk to one = another.

If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier.  :-)

I see the point of this effort as figuring out how the bulk = of those operations can be handled by a less-constrained server that is = storing the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes.

So, no, I don't think of the = authorization server as being a constrained node in the same sense as = battery-operated sensors, actuators, = etc.
Margaret
_______________= ________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mail= man/listinfo/ace

= --Apple-Mail=_92FE66B0-3C06-4D51-A148-2C16BD11680E-- From nobody Fri Mar 14 06:11:05 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE01A0145 for ; Fri, 14 Mar 2014 06:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J1YxAIK1cIz for ; Fri, 14 Mar 2014 06:11:01 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id B65AD1A0133 for ; Fri, 14 Mar 2014 06:11:01 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id m5so2440390qaj.39 for ; Fri, 14 Mar 2014 06:10:54 -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; bh=YmHmABd+bESh+t3zJPeXNURimTombGM+ZNfNG0dP9Pk=; b=RJV4hCxgNP17PgLhKh4Ysmhe3+sPmLxoe+l/jhr/qKIRrLQQVBwMlk6ZqPcDjZj89i VNJCNH8R51TmugwV9cx0RMQmKFhCf+L5ammtn/3B/ZD0YGj946zXLwupF4jQdoBViz5m e+fWy2yb61HX5t2BQNqwNA/OC29QA1eymTkbjMYwal6VL1Owv1Z2GA95/Zb7J1GyZDHG e4GIPdsSe7889vi5GY2U+Q5JzTX7kGEUNKI3P5HSHU26CAAetrbxaKopWFTnLlCz4Ii0 sYfrKOofHIkVs5DqTeQBHm/LzrMDliB9+u9oUec7tnM0JRofRLS5xr6rmSGxv+DBI0XT 7jbw== X-Received: by 10.224.123.212 with SMTP id q20mr2235903qar.95.1394802654739; Fri, 14 Mar 2014 06:10:54 -0700 (PDT) Received: from new-host.home (pool-108-7-235-60.bstnma.fios.verizon.net. [108.7.235.60]) by mx.google.com with ESMTPSA id 110sm7876415qgv.19.2014.03.14.06.10.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:10:54 -0700 (PDT) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3969CF8B-0A6B-4694-A2FD-D6A2EF0E130E@gmail.com> Date: Fri, 14 Mar 2014 09:11:00 -0400 To: "ace@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/vdLgmgqCzz28liE1aQWbTprf8BA Subject: [Ace] Wi-Fi Systems on a Chip X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:11:03 -0000 Just so that people who haven't working in the low-end embedded space = understand the sort of limitations that a low-end, low-power wi-fi = system might have, I thought it might be useful for folks to see the = specs of a few common SoCs (Systems on a Chip) and/or modules that are = available today. =20 http://www.gainspan.com/gs1011soc1 = http://www.semiconductorstore.com/pages/asp/DownloadDirect.asp?sid=3D13947= 77188416 = http://www.embeddedworks.net/wlan308.html?gclid=3DCOeprveLkr0CFYt9Ogod6ncA= ug [Note: in high volumes, these chips/modules might cost 10-20% of the = low-volume prices indicated.] I have no interest at all in these companies -- I'm not even using any = of their products at the moment. I just compiled this list from a quick = web search for "low-power wi-fi SoC". This doesn't represent a full = survey of the market by any means -- these are just a few examples to = give people an idea of the constraints we might be dealing with in a = sensor, actuator or other battery-operated device. Margaret From nobody Fri Mar 14 06:24:37 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7211A0145 for ; Fri, 14 Mar 2014 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0U1pM9mis1p for ; Fri, 14 Mar 2014 06:24:31 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id B1E711A0151 for ; Fri, 14 Mar 2014 06:24:31 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so2826838qcx.35 for ; Fri, 14 Mar 2014 06:24:24 -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; bh=erSS42MMCoacS1FPNq1J3MojfMkQ4b9a3ErYal1WyKs=; b=qszHO0+un8DdDsX6GtUbmqsaFEek3+2pNJEQcFHjJhMx5tNHYns98xE5e64xsAGf1H gDmLaZPh0+SrEzNuFinKvHu6eDNc/Uv005ut5jxIFSLHsEv7zhl8+oCB/G16GuU58HlB 6PHsjGFE40I9AfDzJ/U+GWf60u9bYqI9MLupyC4zir9NLYvkAmpEMqK0EV/t9804t/pr UhtsaMR7w0pJdfq+K5+kiJ3s0kHzspiRLZSpTVYed8FYlQeafd+SzvGUJvizkIdvgLtm SHtH7NCTlBIuP89+v8A8EtDTkXsfpZMs8g4mq4B08lBfbN4rJLwwGVsERnabkb8pJ3Ld 13dQ== X-Received: by 10.140.98.97 with SMTP id n88mr9240494qge.8.1394803464603; Fri, 14 Mar 2014 06:24:24 -0700 (PDT) Received: from [10.86.246.70] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id x5sm12540881qaj.9.2014.03.14.06.24.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:24:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <3969CF8B-0A6B-4694-A2FD-D6A2EF0E130E@gmail.com> Date: Fri, 14 Mar 2014 09:24:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3969CF8B-0A6B-4694-A2FD-D6A2EF0E130E@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0iynsBu81DZVJvKVjWGeB-q1-_g Cc: ace@ietf.org Subject: Re: [Ace] Wi-Fi Systems on a Chip X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:24:35 -0000 Corresponding info for IEEE802.15.4: = http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=3DMC13224V&= fsrch=3D1 = http://store.redwirellc.com/collections/frontpage/products/m12-mc13224v-6l= owpan-module I'm working with a team at Purdue to implement a ZigBee-IP stack on an = earlier, prototyping version of the 6LowPAN module. - Ralph PS Following up on Cartsen's slide from his WG presentation, if you = added 30MB of disk (dual RK05 and a 3rd party fixed disk) and doubled = the RAM, it would look pretty much like a PDP 11-34 running Sixth = Edition UNIX. The key is doubling the RAM. We're finding it a little = tough to wedge a full Z-IP stack into the 96KB of RAM on the mc13224v. = It can be done, as the Z-IP interop and cert tests have shown... On Mar 14, 2014, at 9:11 AM 3/14/14, Margaret Wasserman = wrote: >=20 > Just so that people who haven't working in the low-end embedded space = understand the sort of limitations that a low-end, low-power wi-fi = system might have, I thought it might be useful for folks to see the = specs of a few common SoCs (Systems on a Chip) and/or modules that are = available today. =20 >=20 > http://www.gainspan.com/gs1011soc1 > = http://www.semiconductorstore.com/pages/asp/DownloadDirect.asp?sid=3D13947= 77188416 > = http://www.embeddedworks.net/wlan308.html?gclid=3DCOeprveLkr0CFYt9Ogod6ncA= ug >=20 > [Note: in high volumes, these chips/modules might cost 10-20% of the = low-volume prices indicated.] >=20 > I have no interest at all in these companies -- I'm not even using any = of their products at the moment. I just compiled this list from a quick = web search for "low-power wi-fi SoC". This doesn't represent a full = survey of the market by any means -- these are just a few examples to = give people an idea of the constraints we might be dealing with in a = sensor, actuator or other battery-operated device. >=20 > Margaret >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Fri Mar 14 06:25:59 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC471A014E for ; Fri, 14 Mar 2014 06:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHnIxgiNSixH for ; Fri, 14 Mar 2014 06:25:55 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2921A0140 for ; Fri, 14 Mar 2014 06:25:55 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so7350142qgd.1 for ; Fri, 14 Mar 2014 06:25:48 -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 :message-id:references:to; bh=IBJZ4pCs1QEpXZxC9XIhl8Y3LFgEmoQ/55wEeZlIQeI=; b=G9xwqRdw9rPJpX/vcX3dCwn/Gbn6aBxBSFUhgokT2/4IHqCI2sOWqHUIwpR0sgLQEf 09pCljewoy0ta2Ly3TENrNJEd7fg23pDaEBihat6VC0bkjpaDjp0OtMRzxOCTSVtD5pO MlopipYi2GPAuRPMMHguYCgMKiZJQF0PJXM9hATaC/JtsaaAlHSia1F1DVek3t/wFY9s 0G5NFdfJ4842eTQs+pnHBAkjM+a6TQVqvUT9KkDmK+JlIQCoeEyO24S2eRGgefb4PzH9 sCdQSz1C2KRGE9h69dNG5wA9DolGvz8EOOMqGwPKZWgeRuR10rR6Tgm+FmheuM3sZiQ6 uEow== X-Received: by 10.229.183.200 with SMTP id ch8mr9744252qcb.17.1394803548136; Fri, 14 Mar 2014 06:25:48 -0700 (PDT) Received: from new-host.home (pool-108-7-235-60.bstnma.fios.verizon.net. [108.7.235.60]) by mx.google.com with ESMTPSA id c60sm7943558qge.11.2014.03.14.06.25.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:25:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_42CD28D0-4948-471E-84BD-E410D5BC9ED8" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Wasserman In-Reply-To: Date: Fri, 14 Mar 2014 09:25:54 -0400 Message-Id: References: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> To: Pat Kinney X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Eo9RawogE3PnjS-jM7XnuWuCbEo Cc: "ace@ietf.org" Subject: Re: [Ace] Constrained Authorization Server? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:25:58 -0000 --Apple-Mail=_42CD28D0-4948-471E-84BD-E410D5BC9ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Pat, Depending on what security mechanisms we use, and how the applications = are written, it is possible that existing associations between the = battery operated nodes could survive as long as the session keys (or = whatever temporary credentials they are using for ongoing communication) = remain valid. The nodes would not be able to establish a new = authenticated session without an Authentication Server, and no new nodes = could usefully join the network (since they couldn't establish secure = communication with any other nodes), but ongoing associations would = survive, perhaps for quite a long time (depending on the key lifetimes). = Would that be sufficient for the case described below? Of course, many systems that are truly critical will be plugged into a = UPS that is sufficient to power the system until an emergency generator = can come online. =20 Margaret On Mar 14, 2014, at 9:05 AM, Pat Kinney = wrote: > I agree with Margaret's analysis with one exception, what about an = emergency situation where mains power has been lost? A network of = battery-powered devices could be providing a critical service, so the = Authorization Server might be on a short-lived UPS. In this case it = could be considered "constrained". Given this, is it reasonable to = expect the network to continue operating without the authorization = server? I.E. in an established network can the Authorization Server be = intermittent? >=20 > Pat >=20 > Pat Kinney > Kinney Consulting LLC > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com >=20 >=20 > On Mar 14, 2014, at 7:55 AM, Margaret Wasserman = wrote: >=20 >=20 > In an offline discussion, I was asked whether I think the ACE effort = should consider situations where the Authorization Server is a = constrained node. I wrote the following answer, and I thought it might = be useful to share it here: >=20 >> I think that depends on what you mean by "constrained". I don't = think an authorization server needs to have a user input device, = necessarily=85 It could be embedded in a home gateway, or a building = control system or an irrigation controller. However, i don't think that = you will want to have a battery-operated, intermittently connected = authorization server, because it might not be available when the client = and server want to talk to one another. >>=20 >> If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier. :-) >>=20 >> I see the point of this effort as figuring out how the bulk of those = operations can be handled by a less-constrained server that is storing = the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes. >>=20 >> So, no, I don't think of the authorization server as being a = constrained node in the same sense as battery-operated sensors, = actuators, etc. >=20 > Margaret > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_42CD28D0-4948-471E-84BD-E410D5BC9ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 pat.kinney@kinneyconsul= tingllc.com> wrote:

I = agree with Margaret's analysis with one exception, what about an = emergency situation where mains power has been lost?  A network of = battery-powered devices could be providing a critical service, so the = Authorization Server might be on a short-lived UPS.  In this case = it could be considered "constrained".  Given this, is it reasonable = to expect the network to continue operating without the authorization = server?  I.E. in an established network can the Authorization = Server be intermittent?

Pat

Pat = Kinney
Kinney Consulting LLC
IEEE = 802.15 WG vice chair, TG chair
ISA100.11a WG = chair
O: +1.847.960.3715

I think that depends on what you mean = by "constrained".  I don't think an authorization server needs to = have a user input device, necessarily=85  It could be embedded in a = home gateway, or a building control system or an irrigation controller. =  However, i don't think that you will want to have a = battery-operated, intermittently connected authorization server, because = it might not be available when the client and server want to talk to one = another.

If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier.  :-)

I see the point of this effort as figuring out how the bulk = of those operations can be handled by a less-constrained server that is = storing the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes.

So, no, I don't think of the = authorization server as being a constrained node in the same sense as = battery-operated sensors, actuators, = etc.

Margaret
_______________= ________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ace

____________________= ___________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mail= man/listinfo/ace

= --Apple-Mail=_42CD28D0-4948-471E-84BD-E410D5BC9ED8-- From nobody Fri Mar 14 06:40:37 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45B51A014E for ; Fri, 14 Mar 2014 06:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGhoyTZAOpWR for ; Fri, 14 Mar 2014 06:40:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 503681A0150 for ; Fri, 14 Mar 2014 06:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2EDeLQ6000708; Fri, 14 Mar 2014 14:40:21 +0100 (CET) Received: from eduroam-pool7-0603.wlan.uni-bremen.de (eduroam-pool7-0603.wlan.uni-bremen.de [134.102.114.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 51046165; Fri, 14 Mar 2014 14:40:21 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Fri, 14 Mar 2014 14:40:11 +0100 X-Mao-Original-Outgoing-Id: 416497211.442738-ee019a0261be9d1b3d8898004bf0ccde Content-Transfer-Encoding: quoted-printable Message-Id: References: <3969CF8B-0A6B-4694-A2FD-D6A2EF0E130E@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/2LjY4XjVDSOVc2GHGsP917bVSbg Cc: ace@ietf.org Subject: Re: [Ace] Wi-Fi Systems on a Chip X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:40:37 -0000 On 14 Mar 2014, at 14:24, Ralph Droms wrote: > We're finding it a little tough to wedge a full Z-IP stack into the = 96KB of RAM on the mc13224v.=20 It may be worth pointing out that the MC13224V is a bit unusual due to = its serial flash architecture: At boot time, the program code is copied from the serial flash to the = RAM, which is shared by both code and data. =20 This differs sharply from most other SoCs in this space, which can = execute right out of Flash, but only have 8-16 KiB (or 32 KiB if you are = very lucky) RAM. That=92s why the LWIG terminology class table gives separate numbers for = RAM and Code; on the MC13224V you could theoretically use 64 KiB for = state data and 32 KiB for code, if that were useful in any way. (Hey, = you could even use an overlay linker, if someone here remembers what = that is =97 the serial Flash is 128 KiB and WKdm style compression works = reasonably well=85) Gr=FC=DFe, Carsten From nobody Fri Mar 14 06:47:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99B61A014F for ; Fri, 14 Mar 2014 06:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PnadUb902vK for ; Fri, 14 Mar 2014 06:47:43 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 645871A014E for ; Fri, 14 Mar 2014 06:47:43 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id w5so2478091qac.20 for ; Fri, 14 Mar 2014 06:47:36 -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; bh=USML/WYPnoqwBJzWPfO/ttj9pGAAzLznYkU+p1w70F4=; b=oJJ7n3m++2Czip+n0rbbgRaDCA7hp/TMtSnduMDKdqCBEnKNLv09+wiqbI2tRn+hZz /oz9aIBzjtPbcx/tLN55vOFDd/D+9v96fC4u3GWuzYILsG3JSsxLQ/NSwBcEqEXREaXH EyZyas/03jYh1kKsDvAFwdB8uGNr5c26zGGaYomeP1z3EN+iM+RzNOt8alxW/eZ9TMyj s9wM/t0vzaMAATlST1dE6kskDaRtqh1P8QAICACNm26ERTpDGAlEPvw+sH2rrc8/sz/e zW5fnOTdACRV7EatM+EisuipICEccbVrDS1HOeFdWk8tUgGpnHWyXAfAOqAh7TqcRA/T WEwQ== X-Received: by 10.224.4.130 with SMTP id 2mr9917407qar.45.1394804856309; Fri, 14 Mar 2014 06:47:36 -0700 (PDT) Received: from [10.86.246.70] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id 110sm8011808qgv.19.2014.03.14.06.47.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:47:34 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: Date: Fri, 14 Mar 2014 09:47:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <282EF8C2-1D73-4DEB-A3EF-3FA3402D5C30@gmail.com> References: <3969CF8B-0A6B-4694-A2FD-D6A2EF0E130E@gmail.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/8DN4PrfRPXijWeiNWCSd4jTUhGw Cc: ace@ietf.org Subject: Re: [Ace] Wi-Fi Systems on a Chip X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:47:44 -0000 On Mar 14, 2014, at 9:40 AM 3/14/14, Carsten Bormann = wrote: > On 14 Mar 2014, at 14:24, Ralph Droms wrote: >=20 >> We're finding it a little tough to wedge a full Z-IP stack into the = 96KB of RAM on the mc13224v.=20 >=20 > It may be worth pointing out that the MC13224V is a bit unusual due to = its serial flash architecture: > At boot time, the program code is copied from the serial flash to the = RAM, which is shared by both code and data. =20 Right - to be precise, I should have described the MC13224V as having = 96KB of program+data space. >=20 >=20 > This differs sharply from most other SoCs in this space, which can = execute right out of Flash, but only have 8-16 KiB (or 32 KiB if you are = very lucky) RAM. Even so, the 96KB is in the ballpark of the program+data space available = on other SoCs. And 8-16KB of data space can be limiting... >=20 > That=92s why the LWIG terminology class table gives separate numbers = for RAM and Code; on the MC13224V you could theoretically use 64 KiB for = state data and 32 KiB for code, if that were useful in any way. (Hey, = you could even use an overlay linker, if someone here remembers what = that is =97 the serial Flash is 128 KiB and WKdm style compression works = reasonably well=85) Yeah, we've thought about the overlay strategy. It would take a pretty = significant redesign of the code to gain much benefit. >=20 > Gr=FC=DFe, Carsten >=20 From nobody Fri Mar 14 07:38:27 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7707C1A015F for ; Fri, 14 Mar 2014 07:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG2UouHsClGi for ; Fri, 14 Mar 2014 07:38:13 -0700 (PDT) Received: from p3plsmtpa08-01.prod.phx3.secureserver.net (p3plsmtpa08-01.prod.phx3.secureserver.net [173.201.193.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3E81A0154 for ; Fri, 14 Mar 2014 07:38:13 -0700 (PDT) Received: from [10.0.1.55] ([99.110.37.26]) by p3plsmtpa08-01.prod.phx3.secureserver.net with id dSe41n0090ZqqBn01Se4AE; Fri, 14 Mar 2014 07:38:06 -0700 From: Pat Kinney Content-Type: multipart/alternative; boundary="Apple-Mail=_503EFEDF-881B-4347-8695-66F98139AB6E" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Fri, 14 Mar 2014 09:38:03 -0500 References: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> To: "ace@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0v4kYSXVXKOyJ3llGElNY4uNoKc Subject: Re: [Ace] Constrained Authorization Server? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 14:38:22 -0000 --Apple-Mail=_503EFEDF-881B-4347-8695-66F98139AB6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 To your first point, would that be sufficient? I think it can work as = long as the system designer understands this point. =20 To your second point, in my experience, counting on an emergency = generator is not really a good idea, the mains went away for a reason, = assuming that back-up generator is totally redundant is a bad = assumption. I know this a an extreme case but recall Fukushima, in = addition to the mains the emergency generators also went down, sensors = indicating critical temperatures and such would still be required. Pat Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 pat.kinney@kinneyconsultingllc.com On Mar 14, 2014, at 8:25 AM, Margaret Wasserman = wrote: Hi Pat, Depending on what security mechanisms we use, and how the applications = are written, it is possible that existing associations between the = battery operated nodes could survive as long as the session keys (or = whatever temporary credentials they are using for ongoing communication) = remain valid. The nodes would not be able to establish a new = authenticated session without an Authentication Server, and no new nodes = could usefully join the network (since they couldn't establish secure = communication with any other nodes), but ongoing associations would = survive, perhaps for quite a long time (depending on the key lifetimes). = Would that be sufficient for the case described below? Of course, many systems that are truly critical will be plugged into a = UPS that is sufficient to power the system until an emergency generator = can come online. =20 Margaret On Mar 14, 2014, at 9:05 AM, Pat Kinney = wrote: > I agree with Margaret's analysis with one exception, what about an = emergency situation where mains power has been lost? A network of = battery-powered devices could be providing a critical service, so the = Authorization Server might be on a short-lived UPS. In this case it = could be considered "constrained". Given this, is it reasonable to = expect the network to continue operating without the authorization = server? I.E. in an established network can the Authorization Server be = intermittent? >=20 > Pat >=20 > Pat Kinney > Kinney Consulting LLC > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com >=20 >=20 > On Mar 14, 2014, at 7:55 AM, Margaret Wasserman = wrote: >=20 >=20 > In an offline discussion, I was asked whether I think the ACE effort = should consider situations where the Authorization Server is a = constrained node. I wrote the following answer, and I thought it might = be useful to share it here: >=20 >> I think that depends on what you mean by "constrained". I don't = think an authorization server needs to have a user input device, = necessarily=85 It could be embedded in a home gateway, or a building = control system or an irrigation controller. However, i don't think that = you will want to have a battery-operated, intermittently connected = authorization server, because it might not be available when the client = and server want to talk to one another. >>=20 >> If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier. :-) >>=20 >> I see the point of this effort as figuring out how the bulk of those = operations can be handled by a less-constrained server that is storing = the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes. >>=20 >> So, no, I don't think of the authorization server as being a = constrained node in the same sense as battery-operated sensors, = actuators, etc. >=20 > Margaret > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_503EFEDF-881B-4347-8695-66F98139AB6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 To = your first point, would that be sufficient?  I think it can work as = long as the system designer understands this point. =  

To your second point, in my experience, = counting on an emergency generator is not really a good idea, the mains = went away for a reason, assuming that back-up generator is totally = redundant is a bad assumption.  I know this a an extreme case but = recall Fukushima, in addition to the mains the emergency generators also = went down, sensors indicating critical temperatures and such would still = be required.

Pat

Pat Kinney
Kinney = Consulting LLC
IEEE 802.15 WG vice chair, TG = chair
ISA100.11a WG chair
O: = +1.847.960.3715





pat.kinney@kinneyconsul= tingllc.com> wrote:

I = agree with Margaret's analysis with one exception, what about an = emergency situation where mains power has been lost?  A network of = battery-powered devices could be providing a critical service, so the = Authorization Server might be on a short-lived UPS.  In this case = it could be considered "constrained".  Given this, is it reasonable = to expect the network to continue operating without the authorization = server?  I.E. in an established network can the Authorization = Server be intermittent?

Pat

Pat = Kinney
Kinney Consulting LLC
IEEE = 802.15 WG vice chair, TG chair
ISA100.11a WG = chair
O: +1.847.960.3715

I think that depends on what you mean = by "constrained".  I don't think an authorization server needs to = have a user input device, necessarily=85  It could be embedded in a = home gateway, or a building control system or an irrigation controller. =  However, i don't think that you will want to have a = battery-operated, intermittently connected authorization server, because = it might not be available when the client and server want to talk to one = another.

If you assume that a "constrained" node can be = always-on/always-connected, can have enough data storage to hold = authentication and authorization information for a network of nodes, and = has enough CPU to run crypto operations to service every connection that = those nodes want to make to each other or to the outside=85 Well, if you = assume that a constrained node can do those things, the problem becomes = a lot easier.  :-)

I see the point of this effort as figuring out how the bulk = of those operations can be handled by a less-constrained server that is = storing the auth information and doing most of the authorization and = authentication work on behalf of the constrained nodes.

So, no, I don't think of the = authorization server as being a constrained node in the same sense as = battery-operated sensors, actuators, = etc.

Margaret
_______________= ________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ace

____________________= ___________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ace

_____________= __________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mail= man/listinfo/ace

= --Apple-Mail=_503EFEDF-881B-4347-8695-66F98139AB6E-- From nobody Fri Mar 14 08:02:24 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22691A015B for ; Fri, 14 Mar 2014 08:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2wk6t5_PnRg for ; Fri, 14 Mar 2014 08:02:08 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan23.extendcp.co.uk [176.32.226.69]) by ietfa.amsl.com (Postfix) with ESMTP id B002A1A0158 for ; Fri, 14 Mar 2014 08:02:07 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WOTcV-00012W-QF for ace@ietf.org; Fri, 14 Mar 2014 15:01:59 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WOTcR-00046n-7g for ace@ietf.org; Fri, 14 Mar 2014 15:01:59 +0000 Received: from host86-149-120-43.range86-149.btcentralplus.com ([86.149.120.43] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WOTcP-0006U4-Sf for ace@ietf.org; Fri, 14 Mar 2014 15:01:55 +0000 Message-ID: <53231A15.4070000@gridmerge.com> Date: Fri, 14 Mar 2014 15:02:45 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ace@ietf.org References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> In-Reply-To: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020200060105020809000302" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/88MLfVCf2mn0ifCzecOiRBkdrUg Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:02:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020200060105020809000302 Content-Type: multipart/alternative; boundary="------------030304060505070305010108" This is a multi-part message in MIME format. --------------030304060505070305010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 to both Margaret's statements. Robert On 13/03/2014 10:55 AM, Margaret Wasserman wrote: > Personally, I would also rather see the use cases and requirements=20 > published as informationalRFCs. I think that a wiki might be a good=20 > way to collect them at first, but I would prefer to be sure that we=20 > have consensus on the problem(s) we are trying to solve. I also think = > it will be useful to have these things in archival form later. > > I do not think the other work of the group should be gated on the=20 > requirements, though, as I think that it makes sense to explore how=20 > existing technologies could or couldn't meet the requirements to=20 > insure that our requirements are reality-based. > > Margaret > > > > -------- Original message -------- > From Likepeng > Date: 03/13/2014 4:28 AM (GMT-05:00) > To Hannes Tschofenig ,G=F6ran Selander=20 > ,Zach Shelby > Cc ace@ietf.org > Subject Re: [Ace] ACE Charter Proposal v0.5 > > > My personal opinion is that the use case and requirements document can = > help people to understand what kind of issues we are trying to resolve.= > > I can see some values to publish it into RFCs. If it is a wiki page,=20 > we will have less people to review it or improve it. > > Especially the use case and requirement document is already in a good=20 > shape and it is referenced several times in the mailing list to=20 > introduce our work to outside. > > Thanks, > > Kind Regards > Kepeng > > > -----????----- > > ???: Ace [mailto:ace-bounces@ietf.org] ?? Hannes Tschofenig > > ????: 2014?3?13? 4:33 > > ???: G=F6ran Selander; Zach Shelby > > ??: ace@ietf.org > > ??: Re: [Ace] ACE Charter Proposal v0.5 > > > > Hi Goeran, > > > > I read a little bit between the lines of your mail and your main=20 > concern is that > > you want to have an RFC published with your name on it. > > A wiki page to document the requirements, and use cases is not good=20 > enough > > for you. > > > > For you putting the draft text on a WG wiki feels like wasted time. > > It is just a different form of documenting the work. > > > > My experience with use cases and requirements has not been great in=20 > the IETF. > > In essence everyone quickly moves on once the group decides about a > > particular solution direction. It then becomes very hard (for the > > chairs) to finish the requirements work since nobody wants to review = > or look > > at them anymore. > > > > Use cases and requirements are great during the initial part of the=20 > work to get > > an understanding of the main challenges. > > > > Having said that I will leave it to the group to decide what they=20 > want to do: > > RFCs or Wiki page > > > > Ciao > > Hannes > > > > PS: Regarding your other comment about pointing to the constraint=20 > nature to > > every item. We can do that if you feel better but the entire charter = > page > > already says 10 times that we are focusing on the constraint space. > > I am sure that the reader will have understood that when they get to = > the task > > list. > > > > > > On 03/12/2014 10:32 AM, G=F6ran Selander wrote: > > > Hannes, Zach and all, > > > > > > I must say I don=B9t find the task list of the current charter very= =20 > helpful: > > > > > > =B3The working group has the following tasks (in this order): > > > > > > 1) The working group Wiki pages will be used to document use cases,= > > > requirements, and protocol design criteria. This work will guide th= e > > > identification of suitable protocol mechanisms. > > > > > > 2) Selection of an authentication and authorization protocol for > > > constrained environments. > > > > > > 3) Evaluation of the candidate solution for use with HTTP/TLS and > > > proxy deployments.=B2 > > > > > > This list does not give much more details about the work to be > > > conducted than is already given by the title of the WG. To a person= > > > not having followed the discussion, the impression is that the work= > > > starts from scratch and there is no clear understanding of what to = do. > > > > > > If we can=B9t formulate the problem statement and first step toward= s a > > > solution in some degree of detail before starting the WG that will > > > anyway be the first task to do, so let=B9s try to get something in = > writing. > > > > > > > > > "1) The working group Wiki pages will be used to document use cases= , > > > requirements, and protocol design criteria. This work will guide th= e > > > identification of suitable protocol mechanisms." > > > > > > This is hiding the fact that there has been 6 months of work on the= > > > use case and requirements draft (the first version of this draft wa= s > > > submitted to CoRE in IETF88), which no one has disagreed is setting= > > > the stage for this work. Look at parallel threads on this mailing l= ist > > > where people ask whether their particular security-for-IoT draft fi= ts > > > into ACE. The answer Hannes is giving is correctly: the scope of th= is > > > work is what is outlined by the use case and requirements draft. I > > > don=B9t mind using the Wiki as a working tool but this does not giv= e > > > traceability a year later. And I don=B9t see the point if copying t= he > > > use case document into a Wiki page - read the draft and provide you= r > > comments! > > > > > > When it comes to protocol design criteria, I agree that more work i= s > > > needed, for which the Wiki may be suitable. Nevertheless I insist o= n > > > documenting the design criteria and its rationale since that provid= es > > > a means for traceability. Make it a milestone to have a draft with > > > assumptions and design criteria (you may include =B3architecture=B2= in > > > this document). This work is anyway a pre-requisite for coming to a= > > > solution, and once you have this content, the candidate solutions a= re > > > much easier evaluated. > > > > > > So, change 1) to state something like > > > > > > "1=B9 ) > > > a) complete the work on use case and requirements > > > b) use Wiki pages for listing assumptions and protocol design > > > criteria, document the result in a draft" > > > > > > Proxy deployment aspects fits well into 1b) [more in separate > > > upcoming mail] > > > > > > > > > 2) Selection of an authentication and authorization protocol for > > > constrained environments. > > > > > > Here I=B9m missing among other things the specific problem statemen= t. > > > The preliminary conclusions from the use case and requirements draf= t > > > formed the basis for the problem statement as presented in the BOF:= We > > > lack a mechanism for dynamic and fine grained access control for > > > constrained environments. > > > > > > The process here should be to: > > > "2=B9) identify suitable protocol mechanisms and match candidate > > > authentication and authorization protocols against requirements and= > > > design criteria, in particular addressing dynamic and fine grained > > > access control suitable for CoAP resource access requests in=20 > constrained > > environments." > > > > > > > > > > > > 3) Evaluation of the candidate solution for use with HTTP/TLS and > > > proxy deployments.=B2 > > > > > > > > > As mentioned above, proxy deployments could be considered as part o= f > > 1=B9b). > > > In 2=B9) it is already stated that in particular we should consider= CoAP > > > on interface (II). As for use of other protocols besides CoAP that > > > issue is orthogonal to this so I leave that out from this discussio= n. > > > > > > > > > > > > G=F6ran > > > > > > > > > > > > > > > > > > On 11/03/14 16:49, "Zach Shelby" wrote: > > > > > >> Hannes, > > >> > > >> I am happy with this charter with one exception. The proxy item he= re > > >> seems to be more of a distraction than anything else, and will > > >> probably result in increased complexity. Was proxy support maybe j= ust > > >> a misunderstanding? Do we really see the need for a proxy in the > > >> middle of I or III? > > >> > > >> I think what we really want here is to make sure that e.g. even > > >> through I is based on HTTP/TLS, II and III for example can run > > >> CoAP/DTLS. In other words, some interfaces can be constrained whil= e > > >> others are not. I think the charter already covers this fine. > > >> > > >> So my proposal would be to remove the mention of protocol translat= ion > > >> proxies. If we really see the need for this some day in the future= , > > >> it could be tackled then. > > >> > > >> Zach > > >> > > >> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig > > >> wrote: > > >> > > >>> Hi all, > > >>> > > >>> I have taken the feedback from the meeting and the recent > > >>> discussions on the mailing list and produced a new strawman=20 > proposal. > > >>> > > >>> The changes include: > > >>> * Added the focus on DTLS/CoAP with an indication that we will ch= eck > > >>> a candidate solution for suitability with HTTP/TLS. > > >>> * Added text to indicate that we will also verify the suitability= of > > >>> the solution for use with protocol translation proxies. > > >>> * Simplified the task list by removing solution specific items. > > >>> * Merged several items on the task list (use cases, requirements,= > > >>> and protocol design guidelines). Followed the suggestion to use o= f a > > >>> Wiki for capturing those. > > >>> > > >>> What do you think? > > >>> > > >>> ----- > > >>> > > >>> Draft Charter V0.5 - Authentication and Authorization for > > >>> Constrained Environment (ACE) > > >>> > > >>> The IETF has recently developed protocols for use in environments= > > >>> where network nodes are limited in CPU, memory, and power. It was= > > >>> observed that Internet protocols can be applied to these constrai= ned > > >>> environments, often only requiring minor tweaking and profiling. = In > > >>> other cases, new protocols have been defined to address the speci= fic > > >>> requirements of constrained devices and networks. An example of s= uch > > >>> a protocol is the Constrained Application Protocol (CoAP). > > >>> components > > >>> As in other environments, authentication and authorization questi= on > > >>> also arise in environments with constrained nodes and networks. F= or > > >>> example, a door lock has to authorize the person seeking access > > >>> using a "digital key". Where are the authorization decisions stor= ed? > > >>> How does the digital key communicate with the lock? Does the lock= > > >>> interact with an authorization server to obtain authorization > > >>> information? How can access be granted to other persons temporari= ly? > > How can access be revoked? > > >>> These types of questions have been answered by existing protocols= > > >>> for use cases outside the constrained environment. But in > > >>> constrained environment, additional requirements pose challenges = for > > >>> the use of various security protocols. > > >>> > > >>> The IETF has a long history in developing three party authenticat= ion > > >>> and authorization protocols for distributed environments. Example= s > > >>> include Kerberos, the Public Key Infrastructure (PKI), the > > >>> Authentication, Authorization, and Accounting (AAA) infrastructur= e, > > >>> and the Web Authorization Protocol (OAuth). All these protocols > > >>> enjoy widespread deployment on the Internet. Although they all ai= m > > >>> to solve a similar goal, at an abstract level, they offer quite > > >>> different functions and utilize different message exchanges. Thes= e > > >>> differences are motivated by the main deployment use cases they w= ere > > designed for. > > >>> > > >>> Requirements derived from use cases indicate the suitability of > > >>> already existing work, such as OAuth, as a solution for constrain= ed > > >>> environments. These protocols were, however, not optimized for > > >>> constrained environments. Additional requirements that need to be= > > >>> taken into account are the lack of a suitable user-interface for > > >>> obtaining the consent of the user and the inability of embedded > > >>> devices to contact an authorization server in real-time with ever= y > > >>> access request due to intermittent connectivity, etc. > > >>> > > >>> This working group therefore aims for a standardized solution for= > > >>> authentication and authorization to enable authorized access to > > >>> resources in constrained environments. As a starting point, the > > >>> working group will assume that access to resources offered by a > > >>> resource server by a client devices takes place using CoAP and=20 > is protected > > by DTLS. > > >>> Both resource server and client may be resource constraint. This > > >>> access will be mediated by an authorization server, which does no= t > > >>> suffer from the same resource limitations. > > >>> > > >>> Existing authentication and authorization protocols are used and > > >>> re-applied for use with constrained devices, where applicable. Th= is > > >>> requires relevant specifications to be reviewed for suitability, > > >>> selecting a subset of them, restricting the options within each o= f > > >>> the specifications. Some functionalities may, however, not be > > >>> available in existing protocols and for those cases new > > >>> functionality has to be standardized. Thus, existing work can be > > >>> leveraged and the group benefits from available security analysis= , > > >>> implementation, and deployment experience. Moreover, a standardiz= ed > > >>> solution for federated authentication and authorization will help= to > > >>> stimulate the deployment of IoT devices offering increased securi= ty. > > >>> > > >>> Once progress in identifying suitable candidate solutions has bee= n > > >>> made the working group will verify whether the same mechanism are= > > >>> also applicable beyond the use of CoAP and DTLS. In particular, t= he > > >>> ability to use the developed solution over HTTP and TLS will be > > investigated. > > >>> Furthermore, to guarantee smooth transition the integration with > > >>> existing deployment will be studied. This particularly concerns t= he > > >>> use of protocol translation proxies. > > >>> > > >>> To be successful this working group requires expertise in securit= y, > > >>> privacy, and a good understanding of usability in the constrained= > > >>> environment space. This work does not make the assumption that th= e > > >>> party offering application layer services is always the same part= y > > >>> offering network access services. > > >>> > > >>> The working group has the following tasks (in this order): > > >>> > > >>> 1) The working group Wiki pages will be used to document use case= s, > > >>> requirements, and protocol design criteria. This work will guide = the > > >>> identification of suitable protocol mechanisms. > > >>> > > >>> 2) Selection of an authentication and authorization protocol for > > >>> constrained environments. > > >>> > > >>> 3) Evaluation of the candidate solution for use with HTTP/TLS and= > > >>> proxy deployments. > > >>> > > >>> ----- > > >>> > > >>> Ciao > > >>> Hannes > > >>> > > >>> _______________________________________________ > > >>> Ace mailing list > > >>> Ace@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ace > > >> > > >> Zach Shelby > > >> Director of Technology > > >> ARM Internet of Things BU > > >> www.arm.com > > >> mobile: +1 (408) 203-9434 > > >> Skype: zdshelby > > >> LinkedIn: fi.linkedin.com/in/zachshelby/ > > >> > > >> > > >> -- IMPORTANT NOTICE: The contents of this email and any attachment= s > > >> are confidential and may also be privileged. If you are not the > > >> intended recipient, please notify the sender immediately and do no= t > > >> disclose the contents to any other person, use it for any purpose,= or > > >> store or copy the information in any medium. Thank you. > > >> > > >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9N= J, > > >> Registered in England & Wales, Company No: 2557590 ARM Holdings pl= c, > > >> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered= in > > >> England & Wales, Company No: 2548782 > > >> > > >> _______________________________________________ > > >> Ace mailing list > > >> Ace@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ace > > > > > > _______________________________________________ > > > Ace mailing list > > > Ace@ietf.org > > > https://www.ietf.org/mailman/listinfo/ace > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------030304060505070305010108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 to both Margaret's statements.

Robert

On 13/03/2014 10:55 AM, Margaret Wasserman wrote:
Personally, I would also rather see the use cases and requirements published as informationalRFCs.  I think that a wiki might be = a good way to collect them at first, but I would prefer to be sure that we have consensus on the problem(s) we are trying to solve.  I also think it will be useful to have these things in archiv= al form later.

I do not think the other work of the group should be gated on the requirements, though, as I think that it makes sense to explore how existing technologies could or couldn't meet the requirements to insure that our requirements are reality-based.

Margaret



-------- Original message --------
From Likepeng <likepeng@huawei.com>
Date: 03/13/2014 4:28 AM (GMT-05:00)
To Hannes Tschofenig <hannes.tschofenig@gmx.net>,G&ou= ml;ran Selander <goran.selander@ericsson.com>,Zach Shelby <Zach.Shelby@arm.com>
Cc ace@ietf.org
Subject Re: [Ace] ACE Charter Proposal v0.5


My personal opinion is that the use case and requirements document can help people to understand what kind of issues we are trying to resolve.

I can see some values to publish it into RFCs. If it is a wiki page, we will have less people to review it or improve it.

Especially the use case and requirement document is already in a good shape and it is referenced several times in the mailing list to introduce our work to outside.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:ace-bounces@ietf.org]= 代表 Hannes Tschofenig
> 发送时间: 2014年3月13Ą= 85; 4:33
> 收件人: Göran Selander; Zach Shelby
= > 抄送: ace@ietf.org
> 主题: Re: [Ace] ACE Charter Proposal v0.5
>
> Hi Goeran,
>
> I read a little bit between the lines of your mail and your main concern is that
> you want to have an RFC published with your name on it.
> A wiki page to document the requirements, and use cases is not good enough
> for you.
>
> For you putting the draft text on a WG wiki feels like wasted time.
> It is just a different form of documenting the work.
>
> My experience with use cases and requirements has not been great in the IETF.
> In essence everyone quickly moves on once the group decides about a
> particular solution direction. It then becomes very hard (for the
> chairs) to finish the requirements work since nobody wants to review or look
> at them anymore.
>
> Use cases and requirements are great during the initial part of the work to get
> an understanding of the main challenges.
>
> Having said that I will leave it to the group to decide what they want to do:
> RFCs or Wiki page
>
> Ciao
> Hannes
>
> PS: Regarding your other comment about pointing to the constraint nature to
> every item. We can do that if you feel better but the entire charter page
> already says 10 times that we are focusing on the constraint space.
> I am sure that the reader will have understood that when they get to the task
> list.
>
>
> On 03/12/2014 10:32 AM, Göran Selander wrote:
> > Hannes, Zach and all,
> >
> > I must say I don¹t find the task list of the current= charter very helpful:
> >
> > ³The working group has the following tasks (in this order):
> >
> > 1) The working group Wiki pages will be used to document use cases,
> > requirements, and protocol design criteria. This work will guide the
> > identification of suitable protocol mechanisms.
> >
> > 2) Selection of an authentication and authorization protocol for
> > constrained environments.
> >
> > 3) Evaluation of the candidate solution for use with HTTP/TLS and
> > proxy deployments.²
> >
> > This list does not give much more details about the work to be
> > conducted than is already given by the title of the WG. To a person
> > not having followed the discussion, the impression is that the work
> > starts from scratch and there is no clear understanding of what to do.
> >
> > If we can¹t formulate the problem statement and firs= t step towards a
> > solution in some degree of detail before starting the WG that will
> > anyway be the first task to do, so let¹s try to get something in writing.
> >
> >
> > "1) The working group Wiki pages will be used to document use cases,
> > requirements, and protocol design criteria. This work will guide the
> > identification of suitable protocol mechanisms."
> >
> > This is hiding the fact that there has been 6 months of work on the
> > use case and requirements draft (the first version of this draft was
> > submitted to CoRE in IETF88), which no one has disagreed is setting
> > the stage for this work. Look at parallel threads on this mailing list
> > where people ask whether their particular security-for-IoT draft fits
> > into ACE. The answer Hannes is giving is correctly: the scope of this
> > work is what is outlined by the use case and requirements draft. I
> > don¹t mind using the Wiki as a working tool but this= does not give
> > traceability a year later. And I don¹t see the point= if copying the
> > use case document into a Wiki page - read the draft and provide your
> comments!
> >
> > When it comes to protocol design criteria, I agree that more work is
> > needed, for which the Wiki may be suitable. Nevertheless I insist on
> > documenting the design criteria and its rationale since that provides
> > a means for traceability. Make it a milestone to have a draft with
> > assumptions and design criteria  (you may include ³architecture² in
> > this document). This work is anyway a pre-requisite for coming to a
> > solution, and once you have this content, the candidate solutions are
> > much easier evaluated.
> >
> > So, change 1) to state something like
> >
> > "1¹ )
> > a) complete the work on use case and requirements
> > b) use Wiki pages for listing assumptions and protocol design
> > criteria, document the result in a draft"
> >
> > Proxy deployment aspects fits well into 1b)  [more i= n separate
> > upcoming mail]
> >
> >
> > 2) Selection of an authentication and authorization protocol for
> > constrained environments.
> >
> > Here I¹m missing among other things the specific pro= blem statement.
> > The preliminary conclusions from the use case and requirements draft
> > formed the basis for the problem statement as presented in the BOF: We
> > lack a mechanism for dynamic and fine grained access control for
> > constrained environments.
> >
> > The process here should be to:
> > "2¹) identify suitable protocol mechanisms and match= candidate
> > authentication and authorization protocols against requirements and
> > design criteria, in particular addressing dynamic and fine grained
> > access control suitable for CoAP resource access requests in constrained
> environments."
> >
> >
> >
> > 3) Evaluation of the candidate solution for use with HTTP/TLS and
> > proxy deployments.²
> >
> >
> > As mentioned above, proxy deployments could be considered as part of
> 1¹b).
> > In 2¹) it is already stated that in particular we sh= ould consider CoAP
> > on interface (II). As for use of other protocols besides CoAP that
> > issue is orthogonal to this so I leave that out from this discussion.
> >
> >
> >
> > Göran
> >
> >
> >
> >
> >
> > On 11/03/14 16:49, "Zach Shelby" <Zach.Shelby@arm.com> wrote:
> >
> >> Hannes,
> >>
> >> I am happy with this charter with one exception. The proxy item here
> >> seems to be more of a distraction than anything else, and will
> >> probably result in increased complexity. Was proxy support maybe just
> >> a misunderstanding? Do we really see the need for a proxy in the
> >> middle of I or III?
> >>
> >> I think what we really want here is to make sure that e.g. even
> >> through I is based on HTTP/TLS, II and III for example can run
> >> CoAP/DTLS. In other words, some interfaces can be constrained while
> >> others are not. I think the charter already covers this fine.
> >>
> >> So my proposal would be to remove the mention of protocol translation
> >> proxies. If we really see the need for this some day in the future,
> >> it could be tackled then.
> >>
> >> Zach
> >>
> >> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig
> >> <hannes.tschofenig@gmx.net> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I have taken the feedback from the meeting and the recent
> >>> discussions on the mailing list and produced a new strawman proposal.
> >>>
> >>> The changes include:
> >>> * Added the focus on DTLS/CoAP with an indication that we will check
> >>> a candidate solution for suitability with HTTP/TLS.
> >>> * Added text to indicate that we will also verify the suitability of
> >>> the solution for use with protocol translation proxies.
> >>> * Simplified the task list by removing solution specific items.
> >>> * Merged several items on the task list (use cases, requirements,
> >>> and protocol design guidelines). Followed the suggestion to use of a
> >>> Wiki for capturing those.
> >>>
> >>> What do you think?
> >>>
> >>> -----
> >>>
> >>> Draft Charter V0.5 - Authentication and Authorization for
> >>> Constrained Environment (ACE)
> >>>
> >>> The IETF has recently developed protocols for use in environments
> >>> where network nodes are limited in CPU, memory, and power. It was
> >>> observed that Internet protocols can be applied to these constrained
> >>> environments, often only requiring minor tweaking and profiling. In
> >>> other cases, new protocols have been defined to address the specific
> >>> requirements of constrained devices and networks. An example of such
> >>> a protocol is the Constrained Application Protocol (CoAP).
> >>> components
> >>> As in other environments, authentication and authorization question
> >>> also arise in environments with constrained nodes and networks. For
> >>> example, a door lock has to authorize the person seeking access
> >>> using a "digital key". Where are the authorization decisions stored?
> >>> How does the digital key communicate with the lock? Does the lock
> >>> interact with an authorization server to obtain authorization
> >>> information? How can access be granted to other persons temporarily?
> How can access be revoked?
> >>> These types of questions have been answered by existing protocols
> >>> for use cases outside the constrained environment. But in
> >>> constrained environment, additional requirements pose challenges for
> >>> the use of various security protocols.
> >>>
> >>> The IETF has a long history in developing three party authentication
> >>> and authorization protocols for distributed environments. Examples
> >>> include Kerberos, the Public Key Infrastructure (PKI), the
> >>> Authentication, Authorization, and Accounting (AAA) infrastructure,
> >>> and the Web Authorization Protocol (OAuth). All these protocols
> >>> enjoy widespread deployment on the Internet. Although they all aim
> >>> to solve a similar goal, at an abstract level, they offer quite
> >>> different functions and utilize different message exchanges. These
> >>> differences are motivated by the main deployment use cases they were
> designed for.
> >>>
> >>> Requirements derived from use cases indicate the suitability of
> >>> already existing work, such as OAuth, as a solution for constrained
> >>> environments. These protocols were, however, not optimized for
> >>> constrained environments. Additional requirements that need to be
> >>> taken into account are the lack of a suitable user-interface for
> >>> obtaining the consent of the user and the inability of embedded
> >>> devices to contact an authorization server in real-time with every
> >>> access request due to intermittent connectivity, etc.
> >>>
> >>> This working group therefore aims for a standardized solution for
> >>> authentication and authorization to enable authorized access to
> >>> resources in constrained environments. As a starting point, the
> >>> working group will assume that access to resources offered by a
> >>> resource server by a client devices takes place using CoAP and is protected
> by DTLS.
> >>> Both resource server and client may be resource constraint. This
> >>> access will be mediated by an authorization server, which does not
> >>> suffer from the same resource limitations.
> >>>
> >>> Existing authentication and authorization protocols are used and
> >>> re-applied for use with constrained devices, where applicable. This
> >>> requires relevant specifications to be reviewed for suitability,
> >>> selecting a subset of them, restricting the options within each of
> >>> the specifications. Some functionalities may, however, not be
> >>> available in existing protocols and for those cases new
> >>> functionality has to be standardized. Thus, existing work can be
> >>> leveraged and the group benefits from available security analysis,
> >>> implementation, and deployment experience. Moreover, a standardized
> >>> solution for federated authentication and authorization will help to
> >>> stimulate the deployment of IoT devices offering increased security.
> >>>
> >>> Once progress in identifying suitable candidate solutions has been
> >>> made the working group will verify whether the same mechanism are
> >>> also applicable beyond the use of CoAP and DTLS. In particular, the
> >>> ability to use the developed solution over HTTP and TLS will be
> investigated.
> >>> Furthermore, to guarantee smooth transition the integration with
> >>> existing deployment will be studied. This particularly concerns the
> >>> use of protocol translation proxies.
> >>>
> >>> To be successful this working group requires expertise in security,
> >>> privacy, and a good understanding of usability in the constrained
> >>> environment space. This work does not make the assumption that the
> >>> party offering application layer services is always the same party
> >>> offering network access services.
> >>>
> >>> The working group has the following tasks (in this order):
> >>>
> >>> 1) The working group Wiki pages will be used to document use cases,
> >>> requirements, and protocol design criteria. This work will guide the
> >>> identification of suitable protocol mechanisms. > >>>
> >>> 2) Selection of an authentication and authorization protocol for
> >>> constrained environments.
> >>>
> >>> 3) Evaluation of the candidate solution for use with HTTP/TLS and
> >>> proxy deployments.
> >>>
> >>> -----
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>> <signature.asc>______________________________________________= _
> >>> Ace mailing list
> >>> Ace@ietf.org
> >>> https://www.ietf.org/mailman/listinf= o/ace
> >>
> >> Zach Shelby
> >> Director of Technology
> >> ARM Internet of Things BU
> >> www.arm.com
> >> mobile: +1 (408) 203-9434
> >> Skype: zdshelby
> >> LinkedIn: fi.linkedin.com/in/zachshelby/
> >>
> >>
> >> -- IMPORTANT NOTICE: The contents of this email and any attachments
> >> are confidential and may also be privileged. If you are not the
> >> intended recipient, please notify the sender immediately and do not
> >> disclose the contents to any other person, use it for any purpose, or
> >> store or copy the information in any medium.  Th= ank you.
> >>
> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> >> Registered in England & Wales, Company No:  2557590 ARM Holdings plc,
> >> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
> >> England & Wales, Company No:  2548782
> >>
> >> _______________________________________________
> >> Ace mailing list
> >> Ace@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ac= e
> >
> > _______________________________________________
> > Ace mailing list
> > Ace@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace
> >

_______________________________________________
Ace mailing list
= Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


_______________________________________________
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace

--------------030304060505070305010108-- --------------ms020200060105020809000302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMTQxNTAyNDVaMCMGCSqGSIb3DQEJBDEWBBQ3C5r+5ad+vejPs8cGQHWzH4GhzTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBADOjq/JREOplWjBYyLR6rr4JTT2zsKW0qa9q6/JTblxQyyHX D3WwcRmTidtuNzRJuw4DXyKuBQfs/2pAOzxYDAF1ekmUcMv30BhIsBIqVd7+V05TcHNrQsfi RDo6vz638JAlq5NUGlijLYgsXsgENIDWe4y8QPzkbEP1HNqsK+I+dPMJ+UHDYGYogDI1rbf1 1JKqe82e6a6BttLv/sv3TkzpfeYiRqG2eoN4MYzYxuYqxaXKvr79GGpE6fNYnoVmNmPtTuLj 3a3uSm7gSyH1/N8MK1plX1kS+EmF5ySeTk0mn2m4NxgBv2uctjRPxPZzg7+tpdjvAy5yfPlC idCbLYMAAAAAAAA= --------------ms020200060105020809000302-- From nobody Fri Mar 14 08:16:33 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714991A017A for ; Fri, 14 Mar 2014 08:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKstQ7oUeUSb for ; Fri, 14 Mar 2014 08:16:28 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan20.extendcp.co.uk [176.32.226.66]) by ietfa.amsl.com (Postfix) with ESMTP id EE0031A0177 for ; Fri, 14 Mar 2014 08:16:27 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WOTqO-0000S4-F7; Fri, 14 Mar 2014 15:16:20 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WOTqN-0002wz-Cf; Fri, 14 Mar 2014 15:16:20 +0000 Received: from host86-149-120-43.range86-149.btcentralplus.com ([86.149.120.43] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WOTqM-0003qe-4C; Fri, 14 Mar 2014 15:16:18 +0000 Message-ID: <53231D75.9050501@gridmerge.com> Date: Fri, 14 Mar 2014 15:17:09 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Margaret Wasserman , "ace@ietf.org" References: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> In-Reply-To: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050406020608000404050607" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/PRI_P_cHkifQrstlXGFwvQZdxs8 Subject: Re: [Ace] Constrained Authorization Server? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:16:31 -0000 This is a cryptographically signed message in MIME format. --------------ms050406020608000404050607 Content-Type: multipart/alternative; boundary="------------010201000205020605050707" This is a multi-part message in MIME format. --------------010201000205020605050707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Margaret, I agree it depends what you mean by "constrained". LWIG has a=20 terminology document which tries to put some context to the adjective:=20 http://tools.ietf.org/html/draft-ietf-lwig-terminology-07. I think what is important to consider is how constrained the AS itself=20 is (as a node and device) and how constrained the connection to the AS=20 is. If the client/RS is first communicating through a constrained node=20 network then via a border router, it may still be expedient to consider=20 a protocol which can run on a constrained node network, as this becomes=20 the limiting factor unless some sort of caching or distribution can be=20 considered. This is independent to what resources the AS itself has for=20 processing. Robert On 14/03/2014 12:55 PM, Margaret Wasserman wrote: > > In an offline discussion, I was asked whether I think the ACE effort=20 > should consider situations where the Authorization Server is a=20 > constrained node. I wrote the following answer, and I thought it=20 > might be useful to share it here: > >> I think that depends on what you mean by "constrained". I don't=20 >> think an authorization server needs to have a user input device,=20 >> necessarily... It could be embedded in a home gateway, or a building = >> control system or an irrigation controller. However, i don't think=20 >> that you will want to have a battery-operated, intermittently=20 >> connected authorization server, because it might not be available=20 >> when the client and server want to talk to one another. >> >> If you assume that a "constrained" node can be=20 >> always-on/always-connected, can have enough data storage to hold=20 >> authentication and authorization information for a network of nodes,=20 >> and has enough CPU to run crypto operations to service every=20 >> connection that those nodes want to make to each other or to the=20 >> outside... Well, if you assume that a constrained node can do those=20 >> things, the problem becomes a lot easier. :-) >> >> I see the point of this effort as figuring out how the bulk of those=20 >> operations can be handled by a less-constrained server that is=20 >> storing the auth information and doing most of the authorization and=20 >> authentication work on behalf of the constrained nodes. >> >> So, no, I don't think of the authorization server as being a=20 >> constrained node in the same sense as battery-operated sensors,=20 >> actuators, etc. > > Margaret > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------010201000205020605050707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Margaret,

I agree it depends what you mean by "constrained". LWIG has a terminology document which tries to put some context to the adjective: http://tools.ietf.org/html/draft-ietf-lw= ig-terminology-07.

I think what is important to consider is how constrained the AS itself is (as a node and device) and how constrained the connection to the AS is. If the client/RS is first communicating through a constrained node network then via a border router, it may still be expedient to consider a protocol which can run on a constrained node network, as this becomes the limiting factor unless some sort of caching or distribution can be considered. This is independent to what resources the AS itself has for processing.

Robert

On 14/03/2014 12:55 PM, Margaret Wasserman wrote:

In an offline discussion, I was asked whether I think the ACE effort should consider situations where the Authorization Server is a constrained node.  I wrote the following answer, and I thought it might be useful to share it here:



If you assume that a "constrained" node can be always-on/always-connected, can have enough data storage to hold authentication and authorization information for a network of nodes, and has enough CPU to run crypto operations to service every connection that those nodes want to make to each other or to the outside… Well, if you assume that a constrained nod= e can do those things, the problem becomes a lot easier.  :-)<= /span>

I see the point of thi= s effort as figuring out how the bulk of those operations can be handled by a less-constrained server that is storing the auth information and doing most of the authorization and authentication work on behalf of the constrained nodes.

So, no, I don't think of the authorization server as being a constrained node in the same sense as battery-operated sensors, actuators, etc.

Margaret


_______________________________________________
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace

--------------010201000205020605050707-- --------------ms050406020608000404050607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMTQxNTE3MDlaMCMGCSqGSIb3DQEJBDEWBBRiBX17jxXaJfhZ7C6P1m2tC6nd3DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBADeR2iyHA3mfF8rRIGoUCR3uE4f7jEqIlE8xX9DJn2+CA9+P TTS17O67BWIATUcCI5KVeU0hZOj0bgeIy/sHHynClZV5DrH18f/jGafsyw9sLAlvQ0x1/IT6 9Hamhbx1QivnAq5Kk9DuMKnGpyX7dM9axUxuaObg5+XKyk1x1aj91Em3/rvWuAnbu+NTCTh6 cFe6dWtNL4fsL91Oqmotolu1fYVTwnCYThZWhv2ltKaBHHBAaXs8+5cOymBXFVvZ6ID3vWyG azcqLrxR4Pvb6GuZ7huL3qkfCpYqUGCDq2a6Et+m+hWoFPDDpXkAU7H4gkIYtLd8FA3qWYh2 XDxjYREAAAAAAAA= --------------ms050406020608000404050607-- From nobody Fri Mar 14 08:32:06 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC461A0165 for ; Fri, 14 Mar 2014 08:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbOBenMT7vOG for ; Fri, 14 Mar 2014 08:32:00 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8253B1A015B for ; Fri, 14 Mar 2014 08:31:59 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Fri, 14 Mar 2014 15:31:51 +0000 Received: from usa-sjc-gw2.usa.Arm.com (10.72.50.52) by usa-sjc-gw1.usa.Arm.com (10.72.50.51) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 14 Mar 2014 08:31:58 -0700 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Fri, 14 Mar 2014 08:31:58 -0700 From: Zach Shelby To: "robert.cragie@gridmerge.com" Date: Fri, 14 Mar 2014 08:31:47 -0700 Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: Ac8/mok6VcSPi8DvQ7St3xwmK8p0zQ== Message-ID: <1939837E-246E-42BC-AA15-2ADD776B627F@arm.com> References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53231A15.4070000@gridmerge.com> In-Reply-To: <53231A15.4070000@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114031415315203902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/r6xJV75-7qiQP4VcIHw_BBJnYBc Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:32:04 -0000 QXMgSSBtZW50aW9uZWQgaW4gdGhlIEJvRiwgbXkgYWR2aWNlIHdvdWxkIGJlIHRvIGp1c3QgdXNl IGEgd2lraSB0byBjb2xsZWN0IHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzLg0KDQpOb3csIGlm IHdlIHdhbnQgdG8gd2FzdGUgdGhlIGZpcnN0IGhhbGYgeWVhciBicmluaW5nIHN1Y2ggZHJhZnRz IHRocm91Z2ggdGhlIFJGQyBwcm9jZXNzIHRoZW4gZ28gYWhlYWQuIEZyb20gbXkgZXhwZXJpZW5j ZSB0aGVzZSBraW5kcyBvZiB3b3JrIGl0ZW1zIGFyZSBqdXN0IGEgV0cgYmxhY2sgaG9sZS4gWW91 IGNhbiBhbHdheXMgZG9jdW1lbnQgdGhlIGFzc3VtZWQgdXNlIGNhc2VzIHdpdGhpbiB0aGUgYWN0 dWFsIHRlY2huaWNhbCBzcGVjaWZpY2F0aW9uIHRvIG1ha2UgaXQgY2xlYXIgd2hhdCBwcm9ibGVt IGl0IGlzIHRyeWluZyB0byBzb2x2ZS4NCg0KWmFjaA0KDQpPbiBNYXIgMTQsIDIwMTQsIGF0IDg6 MDIgQU0sIFJvYmVydCBDcmFnaWUgPHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbT4gd3JvdGU6 DQoNCj4gKzEgdG8gYm90aCBNYXJnYXJldCdzIHN0YXRlbWVudHMuDQo+DQo+IFJvYmVydA0KPg0K PiBPbiAxMy8wMy8yMDE0IDEwOjU1IEFNLCBNYXJnYXJldCBXYXNzZXJtYW4gd3JvdGU6DQo+PiBQ ZXJzb25hbGx5LCBJIHdvdWxkIGFsc28gcmF0aGVyIHNlZSB0aGUgdXNlIGNhc2VzIGFuZCByZXF1 aXJlbWVudHMgcHVibGlzaGVkIGFzIGluZm9ybWF0aW9uYWxSRkNzLiAgSSB0aGluayB0aGF0IGEg d2lraSBtaWdodCBiZSBhIGdvb2Qgd2F5IHRvIGNvbGxlY3QgdGhlbSBhdCBmaXJzdCwgYnV0IEkg d291bGQgcHJlZmVyIHRvIGJlIHN1cmUgdGhhdCB3ZSBoYXZlIGNvbnNlbnN1cyBvbiB0aGUgcHJv YmxlbShzKSB3ZSBhcmUgdHJ5aW5nIHRvIHNvbHZlLiAgSSBhbHNvIHRoaW5rIGl0IHdpbGwgYmUg dXNlZnVsIHRvIGhhdmUgdGhlc2UgdGhpbmdzIGluIGFyY2hpdmFsIGZvcm0gbGF0ZXIuDQo+Pg0K Pj4gSSBkbyBub3QgdGhpbmsgdGhlIG90aGVyIHdvcmsgb2YgdGhlIGdyb3VwIHNob3VsZCBiZSBn YXRlZCBvbiB0aGUgcmVxdWlyZW1lbnRzLCB0aG91Z2gsIGFzIEkgdGhpbmsgdGhhdCBpdCBtYWtl cyBzZW5zZSB0byBleHBsb3JlIGhvdyBleGlzdGluZyB0ZWNobm9sb2dpZXMgY291bGQgb3IgY291 bGRuJ3QgbWVldCB0aGUgcmVxdWlyZW1lbnRzIHRvIGluc3VyZSB0aGF0IG91ciByZXF1aXJlbWVu dHMgYXJlIHJlYWxpdHktYmFzZWQuDQo+Pg0KPj4gTWFyZ2FyZXQNCj4+DQo+Pg0KPj4NCj4+IC0t LS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0NCj4+IEZyb20gTGlrZXBlbmcgPGxpa2Vw ZW5nQGh1YXdlaS5jb20+DQo+PiBEYXRlOiAwMy8xMy8yMDE0IDQ6MjggQU0gKEdNVC0wNTowMCkN Cj4+IFRvIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PixHw7Zy YW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4sWmFjaCBTaGVsYnkgPFph Y2guU2hlbGJ5QGFybS5jb20+DQo+PiBDYyBhY2VAaWV0Zi5vcmcNCj4+IFN1YmplY3QgUmU6IFtB Y2VdIEFDRSBDaGFydGVyIFByb3Bvc2FsIHYwLjUNCj4+DQo+Pg0KPj4gTXkgcGVyc29uYWwgb3Bp bmlvbiBpcyB0aGF0IHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGNhbiBo ZWxwIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQga2luZCBvZiBpc3N1ZXMgd2UgYXJlIHRyeWlu ZyB0byByZXNvbHZlLg0KPj4NCj4+IEkgY2FuIHNlZSBzb21lIHZhbHVlcyB0byBwdWJsaXNoIGl0 IGludG8gUkZDcy4gSWYgaXQgaXMgYSB3aWtpIHBhZ2UsIHdlIHdpbGwgaGF2ZSBsZXNzIHBlb3Bs ZSB0byByZXZpZXcgaXQgb3IgaW1wcm92ZSBpdC4NCj4+DQo+PiBFc3BlY2lhbGx5IHRoZSB1c2Ug Y2FzZSBhbmQgcmVxdWlyZW1lbnQgZG9jdW1lbnQgaXMgYWxyZWFkeSBpbiBhIGdvb2Qgc2hhcGUg YW5kIGl0IGlzIHJlZmVyZW5jZWQgc2V2ZXJhbCB0aW1lcyBpbiB0aGUgbWFpbGluZyBsaXN0IHRv IGludHJvZHVjZSBvdXIgd29yayB0byBvdXRzaWRlLg0KPj4NCj4+IFRoYW5rcywNCj4+DQo+PiBL aW5kIFJlZ2FyZHMNCj4+IEtlcGVuZw0KPj4NCj4+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K Pj4gPiDlj5Hku7bkuro6IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDku6Pooagg SGFubmVzIFRzY2hvZmVuaWcNCj4+ID4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0M+aciDEz5pelIDQ6 MzMNCj4+ID4g5pS25Lu25Lq6OiBHw7ZyYW4gU2VsYW5kZXI7IFphY2ggU2hlbGJ5DQo+PiA+IOaK hOmAgTogYWNlQGlldGYub3JnDQo+PiA+IOS4u+mimDogUmU6IFtBY2VdIEFDRSBDaGFydGVyIFBy b3Bvc2FsIHYwLjUNCj4+ID4NCj4+ID4gSGkgR29lcmFuLA0KPj4gPg0KPj4gPiBJIHJlYWQgYSBs aXR0bGUgYml0IGJldHdlZW4gdGhlIGxpbmVzIG9mIHlvdXIgbWFpbCBhbmQgeW91ciBtYWluIGNv bmNlcm4gaXMgdGhhdA0KPj4gPiB5b3Ugd2FudCB0byBoYXZlIGFuIFJGQyBwdWJsaXNoZWQgd2l0 aCB5b3VyIG5hbWUgb24gaXQuDQo+PiA+IEEgd2lraSBwYWdlIHRvIGRvY3VtZW50IHRoZSByZXF1 aXJlbWVudHMsIGFuZCB1c2UgY2FzZXMgaXMgbm90IGdvb2QgZW5vdWdoDQo+PiA+IGZvciB5b3Uu DQo+PiA+DQo+PiA+IEZvciB5b3UgcHV0dGluZyB0aGUgZHJhZnQgdGV4dCBvbiBhIFdHIHdpa2kg ZmVlbHMgbGlrZSB3YXN0ZWQgdGltZS4NCj4+ID4gSXQgaXMganVzdCBhIGRpZmZlcmVudCBmb3Jt IG9mIGRvY3VtZW50aW5nIHRoZSB3b3JrLg0KPj4gPg0KPj4gPiBNeSBleHBlcmllbmNlIHdpdGgg dXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgaGFzIG5vdCBiZWVuIGdyZWF0IGluIHRoZSBJRVRG Lg0KPj4gPiBJbiBlc3NlbmNlIGV2ZXJ5b25lIHF1aWNrbHkgbW92ZXMgb24gb25jZSB0aGUgZ3Jv dXAgZGVjaWRlcyBhYm91dCBhDQo+PiA+IHBhcnRpY3VsYXIgc29sdXRpb24gZGlyZWN0aW9uLiBJ dCB0aGVuIGJlY29tZXMgdmVyeSBoYXJkIChmb3IgdGhlDQo+PiA+IGNoYWlycykgdG8gZmluaXNo IHRoZSByZXF1aXJlbWVudHMgd29yayBzaW5jZSBub2JvZHkgd2FudHMgdG8gcmV2aWV3IG9yIGxv b2sNCj4+ID4gYXQgdGhlbSBhbnltb3JlLg0KPj4gPg0KPj4gPiBVc2UgY2FzZXMgYW5kIHJlcXVp cmVtZW50cyBhcmUgZ3JlYXQgZHVyaW5nIHRoZSBpbml0aWFsIHBhcnQgb2YgdGhlIHdvcmsgdG8g Z2V0DQo+PiA+IGFuIHVuZGVyc3RhbmRpbmcgb2YgdGhlIG1haW4gY2hhbGxlbmdlcy4NCj4+ID4N Cj4+ID4gSGF2aW5nIHNhaWQgdGhhdCBJIHdpbGwgbGVhdmUgaXQgdG8gdGhlIGdyb3VwIHRvIGRl Y2lkZSB3aGF0IHRoZXkgd2FudCB0byBkbzoNCj4+ID4gUkZDcyBvciBXaWtpIHBhZ2UNCj4+ID4N Cj4+ID4gQ2lhbw0KPj4gPiBIYW5uZXMNCj4+ID4NCj4+ID4gUFM6IFJlZ2FyZGluZyB5b3VyIG90 aGVyIGNvbW1lbnQgYWJvdXQgcG9pbnRpbmcgdG8gdGhlIGNvbnN0cmFpbnQgbmF0dXJlIHRvDQo+ PiA+IGV2ZXJ5IGl0ZW0uIFdlIGNhbiBkbyB0aGF0IGlmIHlvdSBmZWVsIGJldHRlciBidXQgdGhl IGVudGlyZSBjaGFydGVyIHBhZ2UNCj4+ID4gYWxyZWFkeSBzYXlzIDEwIHRpbWVzIHRoYXQgd2Ug YXJlIGZvY3VzaW5nIG9uIHRoZSBjb25zdHJhaW50IHNwYWNlLg0KPj4gPiBJIGFtIHN1cmUgdGhh dCB0aGUgcmVhZGVyIHdpbGwgaGF2ZSB1bmRlcnN0b29kIHRoYXQgd2hlbiB0aGV5IGdldCB0byB0 aGUgdGFzaw0KPj4gPiBsaXN0Lg0KPj4gPg0KPj4gPg0KPj4gPiBPbiAwMy8xMi8yMDE0IDEwOjMy IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiA+ID4gSGFubmVzLCBaYWNoIGFuZCBhbGws DQo+PiA+ID4NCj4+ID4gPiBJIG11c3Qgc2F5IEkgZG9uwrl0IGZpbmQgdGhlIHRhc2sgbGlzdCBv ZiB0aGUgY3VycmVudCBjaGFydGVyIHZlcnkgaGVscGZ1bDoNCj4+ID4gPg0KPj4gPiA+IMKzVGhl IHdvcmtpbmcgZ3JvdXAgaGFzIHRoZSBmb2xsb3dpbmcgdGFza3MgKGluIHRoaXMgb3JkZXIpOg0K Pj4gPiA+DQo+PiA+ID4gMSkgVGhlIHdvcmtpbmcgZ3JvdXAgV2lraSBwYWdlcyB3aWxsIGJlIHVz ZWQgdG8gZG9jdW1lbnQgdXNlIGNhc2VzLA0KPj4gPiA+IHJlcXVpcmVtZW50cywgYW5kIHByb3Rv Y29sIGRlc2lnbiBjcml0ZXJpYS4gVGhpcyB3b3JrIHdpbGwgZ3VpZGUgdGhlDQo+PiA+ID4gaWRl bnRpZmljYXRpb24gb2Ygc3VpdGFibGUgcHJvdG9jb2wgbWVjaGFuaXNtcy4NCj4+ID4gPg0KPj4g PiA+IDIpIFNlbGVjdGlvbiBvZiBhbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBw cm90b2NvbCBmb3INCj4+ID4gPiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuDQo+PiA+ID4NCj4+ ID4gPiAzKSBFdmFsdWF0aW9uIG9mIHRoZSBjYW5kaWRhdGUgc29sdXRpb24gZm9yIHVzZSB3aXRo IEhUVFAvVExTIGFuZA0KPj4gPiA+IHByb3h5IGRlcGxveW1lbnRzLsKyDQo+PiA+ID4NCj4+ID4g PiBUaGlzIGxpc3QgZG9lcyBub3QgZ2l2ZSBtdWNoIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgd29y ayB0byBiZQ0KPj4gPiA+IGNvbmR1Y3RlZCB0aGFuIGlzIGFscmVhZHkgZ2l2ZW4gYnkgdGhlIHRp dGxlIG9mIHRoZSBXRy4gVG8gYSBwZXJzb24NCj4+ID4gPiBub3QgaGF2aW5nIGZvbGxvd2VkIHRo ZSBkaXNjdXNzaW9uLCB0aGUgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSB3b3JrDQo+PiA+ID4gc3Rh cnRzIGZyb20gc2NyYXRjaCBhbmQgdGhlcmUgaXMgbm8gY2xlYXIgdW5kZXJzdGFuZGluZyBvZiB3 aGF0IHRvIGRvLg0KPj4gPiA+DQo+PiA+ID4gSWYgd2UgY2Fuwrl0IGZvcm11bGF0ZSB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgYW5kIGZpcnN0IHN0ZXAgdG93YXJkcyBhDQo+PiA+ID4gc29sdXRpb24g aW4gc29tZSBkZWdyZWUgb2YgZGV0YWlsIGJlZm9yZSBzdGFydGluZyB0aGUgV0cgdGhhdCB3aWxs DQo+PiA+ID4gYW55d2F5IGJlIHRoZSBmaXJzdCB0YXNrIHRvIGRvLCBzbyBsZXTCuXMgdHJ5IHRv IGdldCBzb21ldGhpbmcgaW4gd3JpdGluZy4NCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4gIjEpIFRo ZSB3b3JraW5nIGdyb3VwIFdpa2kgcGFnZXMgd2lsbCBiZSB1c2VkIHRvIGRvY3VtZW50IHVzZSBj YXNlcywNCj4+ID4gPiByZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEu IFRoaXMgd29yayB3aWxsIGd1aWRlIHRoZQ0KPj4gPiA+IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRh YmxlIHByb3RvY29sIG1lY2hhbmlzbXMuIg0KPj4gPiA+DQo+PiA+ID4gVGhpcyBpcyBoaWRpbmcg dGhlIGZhY3QgdGhhdCB0aGVyZSBoYXMgYmVlbiA2IG1vbnRocyBvZiB3b3JrIG9uIHRoZQ0KPj4g PiA+IHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZHJhZnQgKHRoZSBmaXJzdCB2ZXJzaW9uIG9m IHRoaXMgZHJhZnQgd2FzDQo+PiA+ID4gc3VibWl0dGVkIHRvIENvUkUgaW4gSUVURjg4KSwgd2hp Y2ggbm8gb25lIGhhcyBkaXNhZ3JlZWQgaXMgc2V0dGluZw0KPj4gPiA+IHRoZSBzdGFnZSBmb3Ig dGhpcyB3b3JrLiBMb29rIGF0IHBhcmFsbGVsIHRocmVhZHMgb24gdGhpcyBtYWlsaW5nIGxpc3QN Cj4+ID4gPiB3aGVyZSBwZW9wbGUgYXNrIHdoZXRoZXIgdGhlaXIgcGFydGljdWxhciBzZWN1cml0 eS1mb3ItSW9UIGRyYWZ0IGZpdHMNCj4+ID4gPiBpbnRvIEFDRS4gVGhlIGFuc3dlciBIYW5uZXMg aXMgZ2l2aW5nIGlzIGNvcnJlY3RseTogdGhlIHNjb3BlIG9mIHRoaXMNCj4+ID4gPiB3b3JrIGlz IHdoYXQgaXMgb3V0bGluZWQgYnkgdGhlIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZHJhZnQu IEkNCj4+ID4gPiBkb27CuXQgbWluZCB1c2luZyB0aGUgV2lraSBhcyBhIHdvcmtpbmcgdG9vbCBi dXQgdGhpcyBkb2VzIG5vdCBnaXZlDQo+PiA+ID4gdHJhY2VhYmlsaXR5IGEgeWVhciBsYXRlci4g QW5kIEkgZG9uwrl0IHNlZSB0aGUgcG9pbnQgaWYgY29weWluZyB0aGUNCj4+ID4gPiB1c2UgY2Fz ZSBkb2N1bWVudCBpbnRvIGEgV2lraSBwYWdlIC0gcmVhZCB0aGUgZHJhZnQgYW5kIHByb3ZpZGUg eW91cg0KPj4gPiBjb21tZW50cyENCj4+ID4gPg0KPj4gPiA+IFdoZW4gaXQgY29tZXMgdG8gcHJv dG9jb2wgZGVzaWduIGNyaXRlcmlhLCBJIGFncmVlIHRoYXQgbW9yZSB3b3JrIGlzDQo+PiA+ID4g bmVlZGVkLCBmb3Igd2hpY2ggdGhlIFdpa2kgbWF5IGJlIHN1aXRhYmxlLiBOZXZlcnRoZWxlc3Mg SSBpbnNpc3Qgb24NCj4+ID4gPiBkb2N1bWVudGluZyB0aGUgZGVzaWduIGNyaXRlcmlhIGFuZCBp dHMgcmF0aW9uYWxlIHNpbmNlIHRoYXQgcHJvdmlkZXMNCj4+ID4gPiBhIG1lYW5zIGZvciB0cmFj ZWFiaWxpdHkuIE1ha2UgaXQgYSBtaWxlc3RvbmUgdG8gaGF2ZSBhIGRyYWZ0IHdpdGgNCj4+ID4g PiBhc3N1bXB0aW9ucyBhbmQgZGVzaWduIGNyaXRlcmlhICAoeW91IG1heSBpbmNsdWRlIMKzYXJj aGl0ZWN0dXJlwrIgaW4NCj4+ID4gPiB0aGlzIGRvY3VtZW50KS4gVGhpcyB3b3JrIGlzIGFueXdh eSBhIHByZS1yZXF1aXNpdGUgZm9yIGNvbWluZyB0byBhDQo+PiA+ID4gc29sdXRpb24sIGFuZCBv bmNlIHlvdSBoYXZlIHRoaXMgY29udGVudCwgdGhlIGNhbmRpZGF0ZSBzb2x1dGlvbnMgYXJlDQo+ PiA+ID4gbXVjaCBlYXNpZXIgZXZhbHVhdGVkLg0KPj4gPiA+DQo+PiA+ID4gU28sIGNoYW5nZSAx KSB0byBzdGF0ZSBzb21ldGhpbmcgbGlrZQ0KPj4gPiA+DQo+PiA+ID4gIjHCuSApDQo+PiA+ID4g YSkgY29tcGxldGUgdGhlIHdvcmsgb24gdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50cw0KPj4gPiA+ IGIpIHVzZSBXaWtpIHBhZ2VzIGZvciBsaXN0aW5nIGFzc3VtcHRpb25zIGFuZCBwcm90b2NvbCBk ZXNpZ24NCj4+ID4gPiBjcml0ZXJpYSwgZG9jdW1lbnQgdGhlIHJlc3VsdCBpbiBhIGRyYWZ0Ig0K Pj4gPiA+DQo+PiA+ID4gUHJveHkgZGVwbG95bWVudCBhc3BlY3RzIGZpdHMgd2VsbCBpbnRvIDFi KSAgW21vcmUgaW4gc2VwYXJhdGUNCj4+ID4gPiB1cGNvbWluZyBtYWlsXQ0KPj4gPiA+DQo+PiA+ ID4NCj4+ID4gPiAyKSBTZWxlY3Rpb24gb2YgYW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24gcHJvdG9jb2wgZm9yDQo+PiA+ID4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KPj4g PiA+DQo+PiA+ID4gSGVyZSBJwrltIG1pc3NpbmcgYW1vbmcgb3RoZXIgdGhpbmdzIHRoZSBzcGVj aWZpYyBwcm9ibGVtIHN0YXRlbWVudC4NCj4+ID4gPiBUaGUgcHJlbGltaW5hcnkgY29uY2x1c2lv bnMgZnJvbSB0aGUgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50cyBkcmFmdA0KPj4gPiA+IGZvcm1l ZCB0aGUgYmFzaXMgZm9yIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhcyBwcmVzZW50ZWQgaW4gdGhl IEJPRjogV2UNCj4+ID4gPiBsYWNrIGEgbWVjaGFuaXNtIGZvciBkeW5hbWljIGFuZCBmaW5lIGdy YWluZWQgYWNjZXNzIGNvbnRyb2wgZm9yDQo+PiA+ID4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRz Lg0KPj4gPiA+DQo+PiA+ID4gVGhlIHByb2Nlc3MgaGVyZSBzaG91bGQgYmUgdG86DQo+PiA+ID4g IjLCuSkgaWRlbnRpZnkgc3VpdGFibGUgcHJvdG9jb2wgbWVjaGFuaXNtcyBhbmQgbWF0Y2ggY2Fu ZGlkYXRlDQo+PiA+ID4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xz IGFnYWluc3QgcmVxdWlyZW1lbnRzIGFuZA0KPj4gPiA+IGRlc2lnbiBjcml0ZXJpYSwgaW4gcGFy dGljdWxhciBhZGRyZXNzaW5nIGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZA0KPj4gPiA+IGFjY2Vz cyBjb250cm9sIHN1aXRhYmxlIGZvciBDb0FQIHJlc291cmNlIGFjY2VzcyByZXF1ZXN0cyBpbiBj b25zdHJhaW5lZA0KPj4gPiBlbnZpcm9ubWVudHMuIg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPg0K Pj4gPiA+IDMpIEV2YWx1YXRpb24gb2YgdGhlIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdXNlIHdp dGggSFRUUC9UTFMgYW5kDQo+PiA+ID4gcHJveHkgZGVwbG95bWVudHMuwrINCj4+ID4gPg0KPj4g PiA+DQo+PiA+ID4gQXMgbWVudGlvbmVkIGFib3ZlLCBwcm94eSBkZXBsb3ltZW50cyBjb3VsZCBi ZSBjb25zaWRlcmVkIGFzIHBhcnQgb2YNCj4+ID4gMcK5YikuDQo+PiA+ID4gSW4gMsK5KSBpdCBp cyBhbHJlYWR5IHN0YXRlZCB0aGF0IGluIHBhcnRpY3VsYXIgd2Ugc2hvdWxkIGNvbnNpZGVyIENv QVANCj4+ID4gPiBvbiBpbnRlcmZhY2UgKElJKS4gQXMgZm9yIHVzZSBvZiBvdGhlciBwcm90b2Nv bHMgYmVzaWRlcyBDb0FQIHRoYXQNCj4+ID4gPiBpc3N1ZSBpcyBvcnRob2dvbmFsIHRvIHRoaXMg c28gSSBsZWF2ZSB0aGF0IG91dCBmcm9tIHRoaXMgZGlzY3Vzc2lvbi4NCj4+ID4gPg0KPj4gPiA+ DQo+PiA+ID4NCj4+ID4gPiBHw7ZyYW4NCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPg0K Pj4gPiA+DQo+PiA+ID4gT24gMTEvMDMvMTQgMTY6NDksICJaYWNoIFNoZWxieSIgPFphY2guU2hl bGJ5QGFybS5jb20+IHdyb3RlOg0KPj4gPiA+DQo+PiA+ID4+IEhhbm5lcywNCj4+ID4gPj4NCj4+ ID4gPj4gSSBhbSBoYXBweSB3aXRoIHRoaXMgY2hhcnRlciB3aXRoIG9uZSBleGNlcHRpb24uIFRo ZSBwcm94eSBpdGVtIGhlcmUNCj4+ID4gPj4gc2VlbXMgdG8gYmUgbW9yZSBvZiBhIGRpc3RyYWN0 aW9uIHRoYW4gYW55dGhpbmcgZWxzZSwgYW5kIHdpbGwNCj4+ID4gPj4gcHJvYmFibHkgcmVzdWx0 IGluIGluY3JlYXNlZCBjb21wbGV4aXR5LiBXYXMgcHJveHkgc3VwcG9ydCBtYXliZSBqdXN0DQo+ PiA+ID4+IGEgbWlzdW5kZXJzdGFuZGluZz8gRG8gd2UgcmVhbGx5IHNlZSB0aGUgbmVlZCBmb3Ig YSBwcm94eSBpbiB0aGUNCj4+ID4gPj4gbWlkZGxlIG9mIEkgb3IgSUlJPw0KPj4gPiA+Pg0KPj4g PiA+PiBJIHRoaW5rIHdoYXQgd2UgcmVhbGx5IHdhbnQgaGVyZSBpcyB0byBtYWtlIHN1cmUgdGhh dCBlLmcuIGV2ZW4NCj4+ID4gPj4gdGhyb3VnaCBJIGlzIGJhc2VkIG9uIEhUVFAvVExTLCBJSSBh bmQgSUlJIGZvciBleGFtcGxlIGNhbiBydW4NCj4+ID4gPj4gQ29BUC9EVExTLiBJbiBvdGhlciB3 b3Jkcywgc29tZSBpbnRlcmZhY2VzIGNhbiBiZSBjb25zdHJhaW5lZCB3aGlsZQ0KPj4gPiA+PiBv dGhlcnMgYXJlIG5vdC4gSSB0aGluayB0aGUgY2hhcnRlciBhbHJlYWR5IGNvdmVycyB0aGlzIGZp bmUuDQo+PiA+ID4+DQo+PiA+ID4+IFNvIG15IHByb3Bvc2FsIHdvdWxkIGJlIHRvIHJlbW92ZSB0 aGUgbWVudGlvbiBvZiBwcm90b2NvbCB0cmFuc2xhdGlvbg0KPj4gPiA+PiBwcm94aWVzLiBJZiB3 ZSByZWFsbHkgc2VlIHRoZSBuZWVkIGZvciB0aGlzIHNvbWUgZGF5IGluIHRoZSBmdXR1cmUsDQo+ PiA+ID4+IGl0IGNvdWxkIGJlIHRhY2tsZWQgdGhlbi4NCj4+ID4gPj4NCj4+ID4gPj4gWmFjaA0K Pj4gPiA+Pg0KPj4gPiA+PiBPbiBNYXIgMTEsIDIwMTQsIGF0IDEyOjUwIEFNLCBIYW5uZXMgVHNj aG9mZW5pZw0KPj4gPiA+PiA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQo+PiA+ ID4+DQo+PiA+ID4+PiBIaSBhbGwsDQo+PiA+ID4+Pg0KPj4gPiA+Pj4gSSBoYXZlIHRha2VuIHRo ZSBmZWVkYmFjayBmcm9tIHRoZSBtZWV0aW5nIGFuZCB0aGUgcmVjZW50DQo+PiA+ID4+PiBkaXNj dXNzaW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBwcm9kdWNlZCBhIG5ldyBzdHJhd21hbiBw cm9wb3NhbC4NCj4+ID4gPj4+DQo+PiA+ID4+PiBUaGUgY2hhbmdlcyBpbmNsdWRlOg0KPj4gPiA+ Pj4gKiBBZGRlZCB0aGUgZm9jdXMgb24gRFRMUy9Db0FQIHdpdGggYW4gaW5kaWNhdGlvbiB0aGF0 IHdlIHdpbGwgY2hlY2sNCj4+ID4gPj4+IGEgY2FuZGlkYXRlIHNvbHV0aW9uIGZvciBzdWl0YWJp bGl0eSB3aXRoIEhUVFAvVExTLg0KPj4gPiA+Pj4gKiBBZGRlZCB0ZXh0IHRvIGluZGljYXRlIHRo YXQgd2Ugd2lsbCBhbHNvIHZlcmlmeSB0aGUgc3VpdGFiaWxpdHkgb2YNCj4+ID4gPj4+IHRoZSBz b2x1dGlvbiBmb3IgdXNlIHdpdGggcHJvdG9jb2wgdHJhbnNsYXRpb24gcHJveGllcy4NCj4+ID4g Pj4+ICogU2ltcGxpZmllZCB0aGUgdGFzayBsaXN0IGJ5IHJlbW92aW5nIHNvbHV0aW9uIHNwZWNp ZmljIGl0ZW1zLg0KPj4gPiA+Pj4gKiBNZXJnZWQgc2V2ZXJhbCBpdGVtcyBvbiB0aGUgdGFzayBs aXN0ICh1c2UgY2FzZXMsIHJlcXVpcmVtZW50cywNCj4+ID4gPj4+IGFuZCBwcm90b2NvbCBkZXNp Z24gZ3VpZGVsaW5lcykuIEZvbGxvd2VkIHRoZSBzdWdnZXN0aW9uIHRvIHVzZSBvZiBhDQo+PiA+ ID4+PiBXaWtpIGZvciBjYXB0dXJpbmcgdGhvc2UuDQo+PiA+ID4+Pg0KPj4gPiA+Pj4gV2hhdCBk byB5b3UgdGhpbms/DQo+PiA+ID4+Pg0KPj4gPiA+Pj4gLS0tLS0NCj4+ID4gPj4+DQo+PiA+ID4+ PiBEcmFmdCBDaGFydGVyIFYwLjUgLSBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBm b3INCj4+ID4gPj4+IENvbnN0cmFpbmVkIEVudmlyb25tZW50IChBQ0UpDQo+PiA+ID4+Pg0KPj4g PiA+Pj4gVGhlIElFVEYgaGFzIHJlY2VudGx5IGRldmVsb3BlZCBwcm90b2NvbHMgZm9yIHVzZSBp biBlbnZpcm9ubWVudHMNCj4+ID4gPj4+IHdoZXJlIG5ldHdvcmsgbm9kZXMgYXJlIGxpbWl0ZWQg aW4gQ1BVLCBtZW1vcnksIGFuZCBwb3dlci4gSXQgd2FzDQo+PiA+ID4+PiBvYnNlcnZlZCB0aGF0 IEludGVybmV0IHByb3RvY29scyBjYW4gYmUgYXBwbGllZCB0byB0aGVzZSBjb25zdHJhaW5lZA0K Pj4gPiA+Pj4gZW52aXJvbm1lbnRzLCBvZnRlbiBvbmx5IHJlcXVpcmluZyBtaW5vciB0d2Vha2lu ZyBhbmQgcHJvZmlsaW5nLiBJbg0KPj4gPiA+Pj4gb3RoZXIgY2FzZXMsIG5ldyBwcm90b2NvbHMg aGF2ZSBiZWVuIGRlZmluZWQgdG8gYWRkcmVzcyB0aGUgc3BlY2lmaWMNCj4+ID4gPj4+IHJlcXVp cmVtZW50cyBvZiBjb25zdHJhaW5lZCBkZXZpY2VzIGFuZCBuZXR3b3Jrcy4gQW4gZXhhbXBsZSBv ZiBzdWNoDQo+PiA+ID4+PiBhIHByb3RvY29sIGlzIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlv biBQcm90b2NvbCAoQ29BUCkuDQo+PiA+ID4+PiBjb21wb25lbnRzDQo+PiA+ID4+PiBBcyBpbiBv dGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHF1ZXN0 aW9uDQo+PiA+ID4+PiBhbHNvIGFyaXNlIGluIGVudmlyb25tZW50cyB3aXRoIGNvbnN0cmFpbmVk IG5vZGVzIGFuZCBuZXR3b3Jrcy4gRm9yDQo+PiA+ID4+PiBleGFtcGxlLCBhIGRvb3IgbG9jayBo YXMgdG8gYXV0aG9yaXplIHRoZSBwZXJzb24gc2Vla2luZyBhY2Nlc3MNCj4+ID4gPj4+IHVzaW5n IGEgImRpZ2l0YWwga2V5Ii4gV2hlcmUgYXJlIHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBz dG9yZWQ/DQo+PiA+ID4+PiBIb3cgZG9lcyB0aGUgZGlnaXRhbCBrZXkgY29tbXVuaWNhdGUgd2l0 aCB0aGUgbG9jaz8gRG9lcyB0aGUgbG9jaw0KPj4gPiA+Pj4gaW50ZXJhY3Qgd2l0aCBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciB0byBvYnRhaW4gYXV0aG9yaXphdGlvbg0KPj4gPiA+Pj4gaW5mb3Jt YXRpb24/IEhvdyBjYW4gYWNjZXNzIGJlIGdyYW50ZWQgdG8gb3RoZXIgcGVyc29ucyB0ZW1wb3Jh cmlseT8NCj4+ID4gSG93IGNhbiBhY2Nlc3MgYmUgcmV2b2tlZD8NCj4+ID4gPj4+IFRoZXNlIHR5 cGVzIG9mIHF1ZXN0aW9ucyBoYXZlIGJlZW4gYW5zd2VyZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xz DQo+PiA+ID4+PiBmb3IgdXNlIGNhc2VzIG91dHNpZGUgdGhlIGNvbnN0cmFpbmVkIGVudmlyb25t ZW50LiBCdXQgaW4NCj4+ID4gPj4+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50LCBhZGRpdGlvbmFs IHJlcXVpcmVtZW50cyBwb3NlIGNoYWxsZW5nZXMgZm9yDQo+PiA+ID4+PiB0aGUgdXNlIG9mIHZh cmlvdXMgc2VjdXJpdHkgcHJvdG9jb2xzLg0KPj4gPiA+Pj4NCj4+ID4gPj4+IFRoZSBJRVRGIGhh cyBhIGxvbmcgaGlzdG9yeSBpbiBkZXZlbG9waW5nIHRocmVlIHBhcnR5IGF1dGhlbnRpY2F0aW9u DQo+PiA+ID4+PiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVu dmlyb25tZW50cy4gRXhhbXBsZXMNCj4+ID4gPj4+IGluY2x1ZGUgS2VyYmVyb3MsIHRoZSBQdWJs aWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGUNCj4+ID4gPj4+IEF1dGhlbnRpY2F0aW9u LCBBdXRob3JpemF0aW9uLCBhbmQgQWNjb3VudGluZyAoQUFBKSBpbmZyYXN0cnVjdHVyZSwNCj4+ ID4gPj4+IGFuZCB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgKE9BdXRoKS4gQWxsIHRo ZXNlIHByb3RvY29scw0KPj4gPiA+Pj4gZW5qb3kgd2lkZXNwcmVhZCBkZXBsb3ltZW50IG9uIHRo ZSBJbnRlcm5ldC4gQWx0aG91Z2ggdGhleSBhbGwgYWltDQo+PiA+ID4+PiB0byBzb2x2ZSBhIHNp bWlsYXIgZ29hbCwgYXQgYW4gYWJzdHJhY3QgbGV2ZWwsIHRoZXkgb2ZmZXIgcXVpdGUNCj4+ID4g Pj4+IGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kIHV0aWxpemUgZGlmZmVyZW50IG1lc3NhZ2UgZXhj aGFuZ2VzLiBUaGVzZQ0KPj4gPiA+Pj4gZGlmZmVyZW5jZXMgYXJlIG1vdGl2YXRlZCBieSB0aGUg bWFpbiBkZXBsb3ltZW50IHVzZSBjYXNlcyB0aGV5IHdlcmUNCj4+ID4gZGVzaWduZWQgZm9yLg0K Pj4gPiA+Pj4NCj4+ID4gPj4+IFJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGlu ZGljYXRlIHRoZSBzdWl0YWJpbGl0eSBvZg0KPj4gPiA+Pj4gYWxyZWFkeSBleGlzdGluZyB3b3Jr LCBzdWNoIGFzIE9BdXRoLCBhcyBhIHNvbHV0aW9uIGZvciBjb25zdHJhaW5lZA0KPj4gPiA+Pj4g ZW52aXJvbm1lbnRzLiBUaGVzZSBwcm90b2NvbHMgd2VyZSwgaG93ZXZlciwgbm90IG9wdGltaXpl ZCBmb3INCj4+ID4gPj4+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQWRkaXRpb25hbCByZXF1 aXJlbWVudHMgdGhhdCBuZWVkIHRvIGJlDQo+PiA+ID4+PiB0YWtlbiBpbnRvIGFjY291bnQgYXJl IHRoZSBsYWNrIG9mIGEgc3VpdGFibGUgdXNlci1pbnRlcmZhY2UgZm9yDQo+PiA+ID4+PiBvYnRh aW5pbmcgdGhlIGNvbnNlbnQgb2YgdGhlIHVzZXIgYW5kIHRoZSBpbmFiaWxpdHkgb2YgZW1iZWRk ZWQNCj4+ID4gPj4+IGRldmljZXMgdG8gY29udGFjdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBp biByZWFsLXRpbWUgd2l0aCBldmVyeQ0KPj4gPiA+Pj4gYWNjZXNzIHJlcXVlc3QgZHVlIHRvIGlu dGVybWl0dGVudCBjb25uZWN0aXZpdHksIGV0Yy4NCj4+ID4gPj4+DQo+PiA+ID4+PiBUaGlzIHdv cmtpbmcgZ3JvdXAgdGhlcmVmb3JlIGFpbXMgZm9yIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZv cg0KPj4gPiA+Pj4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gdG8gZW5hYmxlIGF1 dGhvcml6ZWQgYWNjZXNzIHRvDQo+PiA+ID4+PiByZXNvdXJjZXMgaW4gY29uc3RyYWluZWQgZW52 aXJvbm1lbnRzLiBBcyBhIHN0YXJ0aW5nIHBvaW50LCB0aGUNCj4+ID4gPj4+IHdvcmtpbmcgZ3Jv dXAgd2lsbCBhc3N1bWUgdGhhdCBhY2Nlc3MgdG8gcmVzb3VyY2VzIG9mZmVyZWQgYnkgYQ0KPj4g PiA+Pj4gcmVzb3VyY2Ugc2VydmVyIGJ5IGEgY2xpZW50IGRldmljZXMgdGFrZXMgcGxhY2UgdXNp bmcgQ29BUCBhbmQgaXMgcHJvdGVjdGVkDQo+PiA+IGJ5IERUTFMuDQo+PiA+ID4+PiBCb3RoIHJl c291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1heSBiZSByZXNvdXJjZSBjb25zdHJhaW50LiBUaGlz DQo+PiA+ID4+PiBhY2Nlc3Mgd2lsbCBiZSBtZWRpYXRlZCBieSBhbiBhdXRob3JpemF0aW9uIHNl cnZlciwgd2hpY2ggZG9lcyBub3QNCj4+ID4gPj4+IHN1ZmZlciBmcm9tIHRoZSBzYW1lIHJlc291 cmNlIGxpbWl0YXRpb25zLg0KPj4gPiA+Pj4NCj4+ID4gPj4+IEV4aXN0aW5nIGF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyBhcmUgdXNlZCBhbmQNCj4+ID4gPj4+IHJl LWFwcGxpZWQgZm9yIHVzZSB3aXRoIGNvbnN0cmFpbmVkIGRldmljZXMsIHdoZXJlIGFwcGxpY2Fi bGUuIFRoaXMNCj4+ID4gPj4+IHJlcXVpcmVzIHJlbGV2YW50IHNwZWNpZmljYXRpb25zIHRvIGJl IHJldmlld2VkIGZvciBzdWl0YWJpbGl0eSwNCj4+ID4gPj4+IHNlbGVjdGluZyBhIHN1YnNldCBv ZiB0aGVtLCByZXN0cmljdGluZyB0aGUgb3B0aW9ucyB3aXRoaW4gZWFjaCBvZg0KPj4gPiA+Pj4g dGhlIHNwZWNpZmljYXRpb25zLiBTb21lIGZ1bmN0aW9uYWxpdGllcyBtYXksIGhvd2V2ZXIsIG5v dCBiZQ0KPj4gPiA+Pj4gYXZhaWxhYmxlIGluIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZm9yIHRo b3NlIGNhc2VzIG5ldw0KPj4gPiA+Pj4gZnVuY3Rpb25hbGl0eSBoYXMgdG8gYmUgc3RhbmRhcmRp emVkLiBUaHVzLCBleGlzdGluZyB3b3JrIGNhbiBiZQ0KPj4gPiA+Pj4gbGV2ZXJhZ2VkIGFuZCB0 aGUgZ3JvdXAgYmVuZWZpdHMgZnJvbSBhdmFpbGFibGUgc2VjdXJpdHkgYW5hbHlzaXMsDQo+PiA+ ID4+PiBpbXBsZW1lbnRhdGlvbiwgYW5kIGRlcGxveW1lbnQgZXhwZXJpZW5jZS4gTW9yZW92ZXIs IGEgc3RhbmRhcmRpemVkDQo+PiA+ID4+PiBzb2x1dGlvbiBmb3IgZmVkZXJhdGVkIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdpbGwgaGVscCB0bw0KPj4gPiA+Pj4gc3RpbXVsYXRl IHRoZSBkZXBsb3ltZW50IG9mIElvVCBkZXZpY2VzIG9mZmVyaW5nIGluY3JlYXNlZCBzZWN1cml0 eS4NCj4+ID4gPj4+DQo+PiA+ID4+PiBPbmNlIHByb2dyZXNzIGluIGlkZW50aWZ5aW5nIHN1aXRh YmxlIGNhbmRpZGF0ZSBzb2x1dGlvbnMgaGFzIGJlZW4NCj4+ID4gPj4+IG1hZGUgdGhlIHdvcmtp bmcgZ3JvdXAgd2lsbCB2ZXJpZnkgd2hldGhlciB0aGUgc2FtZSBtZWNoYW5pc20gYXJlDQo+PiA+ ID4+PiBhbHNvIGFwcGxpY2FibGUgYmV5b25kIHRoZSB1c2Ugb2YgQ29BUCBhbmQgRFRMUy4gSW4g cGFydGljdWxhciwgdGhlDQo+PiA+ID4+PiBhYmlsaXR5IHRvIHVzZSB0aGUgZGV2ZWxvcGVkIHNv bHV0aW9uIG92ZXIgSFRUUCBhbmQgVExTIHdpbGwgYmUNCj4+ID4gaW52ZXN0aWdhdGVkLg0KPj4g PiA+Pj4gRnVydGhlcm1vcmUsIHRvIGd1YXJhbnRlZSBzbW9vdGggdHJhbnNpdGlvbiB0aGUgaW50 ZWdyYXRpb24gd2l0aA0KPj4gPiA+Pj4gZXhpc3RpbmcgZGVwbG95bWVudCB3aWxsIGJlIHN0dWRp ZWQuIFRoaXMgcGFydGljdWxhcmx5IGNvbmNlcm5zIHRoZQ0KPj4gPiA+Pj4gdXNlIG9mIHByb3Rv Y29sIHRyYW5zbGF0aW9uIHByb3hpZXMuDQo+PiA+ID4+Pg0KPj4gPiA+Pj4gVG8gYmUgc3VjY2Vz c2Z1bCB0aGlzIHdvcmtpbmcgZ3JvdXAgcmVxdWlyZXMgZXhwZXJ0aXNlIGluIHNlY3VyaXR5LA0K Pj4gPiA+Pj4gcHJpdmFjeSwgYW5kIGEgZ29vZCB1bmRlcnN0YW5kaW5nIG9mIHVzYWJpbGl0eSBp biB0aGUgY29uc3RyYWluZWQNCj4+ID4gPj4+IGVudmlyb25tZW50IHNwYWNlLiBUaGlzIHdvcmsg ZG9lcyBub3QgbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZQ0KPj4gPiA+Pj4gcGFydHkgb2Zm ZXJpbmcgYXBwbGljYXRpb24gbGF5ZXIgc2VydmljZXMgaXMgYWx3YXlzIHRoZSBzYW1lIHBhcnR5 DQo+PiA+ID4+PiBvZmZlcmluZyBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlcy4NCj4+ID4gPj4+DQo+ PiA+ID4+PiBUaGUgd29ya2luZyBncm91cCBoYXMgdGhlIGZvbGxvd2luZyB0YXNrcyAoaW4gdGhp cyBvcmRlcik6DQo+PiA+ID4+Pg0KPj4gPiA+Pj4gMSkgVGhlIHdvcmtpbmcgZ3JvdXAgV2lraSBw YWdlcyB3aWxsIGJlIHVzZWQgdG8gZG9jdW1lbnQgdXNlIGNhc2VzLA0KPj4gPiA+Pj4gcmVxdWly ZW1lbnRzLCBhbmQgcHJvdG9jb2wgZGVzaWduIGNyaXRlcmlhLiBUaGlzIHdvcmsgd2lsbCBndWlk ZSB0aGUNCj4+ID4gPj4+IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3RvY29sIG1lY2hh bmlzbXMuDQo+PiA+ID4+Pg0KPj4gPiA+Pj4gMikgU2VsZWN0aW9uIG9mIGFuIGF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sIGZvcg0KPj4gPiA+Pj4gY29uc3RyYWluZWQg ZW52aXJvbm1lbnRzLg0KPj4gPiA+Pj4NCj4+ID4gPj4+IDMpIEV2YWx1YXRpb24gb2YgdGhlIGNh bmRpZGF0ZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggSFRUUC9UTFMgYW5kDQo+PiA+ID4+PiBwcm94 eSBkZXBsb3ltZW50cy4NCj4+ID4gPj4+DQo+PiA+ID4+PiAtLS0tLQ0KPj4gPiA+Pj4NCj4+ID4g Pj4+IENpYW8NCj4+ID4gPj4+IEhhbm5lcw0KPj4gPiA+Pj4NCj4+ID4gPj4+IDxzaWduYXR1cmUu YXNjPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ ID4+PiBBY2UgbWFpbGluZyBsaXN0DQo+PiA+ID4+PiBBY2VAaWV0Zi5vcmcNCj4+ID4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+PiA+ID4+DQo+PiA+ID4+ IFphY2ggU2hlbGJ5DQo+PiA+ID4+IERpcmVjdG9yIG9mIFRlY2hub2xvZ3kNCj4+ID4gPj4gQVJN IEludGVybmV0IG9mIFRoaW5ncyBCVQ0KPj4gPiA+PiB3d3cuYXJtLmNvbQ0KPj4gPiA+PiBtb2Jp bGU6ICsxICg0MDgpIDIwMy05NDM0DQo+PiA+ID4+IFNreXBlOiB6ZHNoZWxieQ0KPj4gPiA+PiBM aW5rZWRJbjogZmkubGlua2VkaW4uY29tL2luL3phY2hzaGVsYnkvDQo+PiA+ID4+DQo+PiA+ID4+ DQo+PiA+ID4+IC0tIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMNCj4+ID4gPj4gYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+PiA+ID4+IGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QN Cj4+ID4gPj4gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yDQo+PiA+ID4+IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0 aW9uIGluIGFueSBtZWRpdW0uICBUaGFuayB5b3UuDQo+PiA+ID4+DQo+PiA+ID4+IEFSTSBMaW1p dGVkLCBSZWdpc3RlcmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5 TkosDQo+PiA+ID4+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAg MjU1NzU5MCBBUk0gSG9sZGluZ3MgcGxjLA0KPj4gPiA+PiBSZWdpc3RlcmVkIG9mZmljZSAxMTAg RnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVyZWQgaW4NCj4+ID4gPj4g RW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAgMjU0ODc4Mg0KPj4gPiA+Pg0KPj4gPiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiA+PiBB Y2UgbWFpbGluZyBsaXN0DQo+PiA+ID4+IEFjZUBpZXRmLm9yZw0KPj4gPiA+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPj4gPiA+DQo+PiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gPiBBY2UgbWFpbGlu ZyBsaXN0DQo+PiA+ID4gQWNlQGlldGYub3JnDQo+PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hY2UNCj4+ID4gPg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBY2UgbWFpbGluZyBsaXN0DQo+PiBBY2VA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+ Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBBY2UgbWFpbGluZyBsaXN0DQo+Pg0KPj4gQWNlQGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPg0KPiA8c21pbWUucDdzPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFjZSBtYWlsaW5nIGxp c3QNCj4gQWNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYWNlDQoNClphY2ggU2hlbGJ5DQpEaXJlY3RvciBvZiBUZWNobm9sb2d5DQpBUk0gSW50ZXJu ZXQgb2YgVGhpbmdzIEJVDQp3d3cuYXJtLmNvbQ0KbW9iaWxlOiArMSAoNDA4KSAyMDMtOTQzNA0K U2t5cGU6IHpkc2hlbGJ5DQpMaW5rZWRJbjogZmkubGlua2VkaW4uY29tL2luL3phY2hzaGVsYnkv DQoNCg0KLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gIFRoYW5rIHlvdS4NCg0KQVJNIExp bWl0ZWQsIFJlZ2lzdGVyZWQgb2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0Ix IDlOSiwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMsIENvbXBhbnkgTm86ICAyNTU3NTkw DQpBUk0gSG9sZGluZ3MgcGxjLCBSZWdpc3RlcmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwg Q2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzLCBDb21wYW55 IE5vOiAgMjU0ODc4Mg0K From nobody Fri Mar 14 08:45:26 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AE31A0174 for ; Fri, 14 Mar 2014 08:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu8d8_lcRAjs for ; Fri, 14 Mar 2014 08:45:13 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan23.extendcp.co.uk [176.32.226.69]) by ietfa.amsl.com (Postfix) with ESMTP id 43C981A017B for ; Fri, 14 Mar 2014 08:45:12 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WOUID-0005ju-1C for ace@ietf.org; Fri, 14 Mar 2014 15:45:05 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WOUIB-0006xY-J5 for ace@ietf.org; Fri, 14 Mar 2014 15:45:05 +0000 Received: from host86-149-120-43.range86-149.btcentralplus.com ([86.149.120.43] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WOUIA-000545-LZ for ace@ietf.org; Fri, 14 Mar 2014 15:45:03 +0000 Message-ID: <53232432.9080906@gridmerge.com> Date: Fri, 14 Mar 2014 15:45:54 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ace@ietf.org References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53231A15.4070000@gridmerge.com> <1939837E-246E-42BC-AA15-2ADD776B627F@arm.com> In-Reply-To: <1939837E-246E-42BC-AA15-2ADD776B627F@arm.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040009080905070200010303" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1jzLHs44d_0x-2ig2v3jERhMORQ Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:45:20 -0000 This is a cryptographically signed message in MIME format. --------------ms040009080905070200010303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Use a Wiki to collect use cases and requirements, refine and produce a=20 concise list. Then that could be cut and pasted into a single RFC - or=20 if preferred, put into an annex in a technical specification - as long=20 as the work has an endpoint and is captured in some document and not=20 left in some nebulous Wiki. Someone mentioned homenet - I would not want = to see that process emulated at all. Robert On 14/03/2014 3:31 PM, Zach Shelby wrote: > As I mentioned in the BoF, my advice would be to just use a wiki to col= lect use cases and requirements. > > Now, if we want to waste the first half year brining such drafts throug= h the RFC process then go ahead. From my experience these kinds of work i= tems are just a WG black hole. You can always document the assumed use ca= ses within the actual technical specification to make it clear what probl= em it is trying to solve. > > Zach > > On Mar 14, 2014, at 8:02 AM, Robert Cragie wrote: > >> +1 to both Margaret's statements. >> >> Robert >> >> On 13/03/2014 10:55 AM, Margaret Wasserman wrote: >>> Personally, I would also rather see the use cases and requirements pu= blished as informationalRFCs. I think that a wiki might be a good way to= collect them at first, but I would prefer to be sure that we have consen= sus on the problem(s) we are trying to solve. I also think it will be us= eful to have these things in archival form later. >>> >>> I do not think the other work of the group should be gated on the req= uirements, though, as I think that it makes sense to explore how existing= technologies could or couldn't meet the requirements to insure that our = requirements are reality-based. >>> >>> Margaret >>> >>> >>> >>> -------- Original message -------- >>> From Likepeng >>> Date: 03/13/2014 4:28 AM (GMT-05:00) >>> To Hannes Tschofenig ,G=C3=B6ran Selander = ,Zach Shelby >>> Cc ace@ietf.org >>> Subject Re: [Ace] ACE Charter Proposal v0.5 >>> >>> >>> My personal opinion is that the use case and requirements document ca= n help people to understand what kind of issues we are trying to resolve.= >>> >>> I can see some values to publish it into RFCs. If it is a wiki page, = we will have less people to review it or improve it. >>> >>> Especially the use case and requirement document is already in a good= shape and it is referenced several times in the mailing list to introduc= e our work to outside. >>> >>> Thanks, >>> >>> Kind Regards >>> Kepeng >>> >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ace [mailto:ace-bounces@ietf.org] =E4=BB= =A3=E8=A1=A8 Hannes Tschofenig >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B43=E6=9C=8813=E6=97= =A5 4:33 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: G=C3=B6ran Selander; Zach Shelby >>>> =E6=8A=84=E9=80=81: ace@ietf.org >>>> =E4=B8=BB=E9=A2=98: Re: [Ace] ACE Charter Proposal v0.5 >>>> >>>> Hi Goeran, >>>> >>>> I read a little bit between the lines of your mail and your main con= cern is that >>>> you want to have an RFC published with your name on it. >>>> A wiki page to document the requirements, and use cases is not good = enough >>>> for you. >>>> >>>> For you putting the draft text on a WG wiki feels like wasted time. >>>> It is just a different form of documenting the work. >>>> >>>> My experience with use cases and requirements has not been great in = the IETF. >>>> In essence everyone quickly moves on once the group decides about a >>>> particular solution direction. It then becomes very hard (for the >>>> chairs) to finish the requirements work since nobody wants to review= or look >>>> at them anymore. >>>> >>>> Use cases and requirements are great during the initial part of the = work to get >>>> an understanding of the main challenges. >>>> >>>> Having said that I will leave it to the group to decide what they wa= nt to do: >>>> RFCs or Wiki page >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: Regarding your other comment about pointing to the constraint na= ture to >>>> every item. We can do that if you feel better but the entire charter= page >>>> already says 10 times that we are focusing on the constraint space. >>>> I am sure that the reader will have understood that when they get to= the task >>>> list. >>>> >>>> >>>> On 03/12/2014 10:32 AM, G=C3=B6ran Selander wrote: >>>>> Hannes, Zach and all, >>>>> >>>>> I must say I don=C2=B9t find the task list of the current charter v= ery helpful: >>>>> >>>>> =C2=B3The working group has the following tasks (in this order): >>>>> >>>>> 1) The working group Wiki pages will be used to document use cases,= >>>>> requirements, and protocol design criteria. This work will guide th= e >>>>> identification of suitable protocol mechanisms. >>>>> >>>>> 2) Selection of an authentication and authorization protocol for >>>>> constrained environments. >>>>> >>>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and >>>>> proxy deployments.=C2=B2 >>>>> >>>>> This list does not give much more details about the work to be >>>>> conducted than is already given by the title of the WG. To a person= >>>>> not having followed the discussion, the impression is that the work= >>>>> starts from scratch and there is no clear understanding of what to = do. >>>>> >>>>> If we can=C2=B9t formulate the problem statement and first step tow= ards a >>>>> solution in some degree of detail before starting the WG that will >>>>> anyway be the first task to do, so let=C2=B9s try to get something = in writing. >>>>> >>>>> >>>>> "1) The working group Wiki pages will be used to document use cases= , >>>>> requirements, and protocol design criteria. This work will guide th= e >>>>> identification of suitable protocol mechanisms." >>>>> >>>>> This is hiding the fact that there has been 6 months of work on the= >>>>> use case and requirements draft (the first version of this draft wa= s >>>>> submitted to CoRE in IETF88), which no one has disagreed is setting= >>>>> the stage for this work. Look at parallel threads on this mailing l= ist >>>>> where people ask whether their particular security-for-IoT draft fi= ts >>>>> into ACE. The answer Hannes is giving is correctly: the scope of th= is >>>>> work is what is outlined by the use case and requirements draft. I >>>>> don=C2=B9t mind using the Wiki as a working tool but this does not = give >>>>> traceability a year later. And I don=C2=B9t see the point if copyin= g the >>>>> use case document into a Wiki page - read the draft and provide you= r >>>> comments! >>>>> When it comes to protocol design criteria, I agree that more work i= s >>>>> needed, for which the Wiki may be suitable. Nevertheless I insist o= n >>>>> documenting the design criteria and its rationale since that provid= es >>>>> a means for traceability. Make it a milestone to have a draft with >>>>> assumptions and design criteria (you may include =C2=B3architectur= e=C2=B2 in >>>>> this document). This work is anyway a pre-requisite for coming to a= >>>>> solution, and once you have this content, the candidate solutions a= re >>>>> much easier evaluated. >>>>> >>>>> So, change 1) to state something like >>>>> >>>>> "1=C2=B9 ) >>>>> a) complete the work on use case and requirements >>>>> b) use Wiki pages for listing assumptions and protocol design >>>>> criteria, document the result in a draft" >>>>> >>>>> Proxy deployment aspects fits well into 1b) [more in separate >>>>> upcoming mail] >>>>> >>>>> >>>>> 2) Selection of an authentication and authorization protocol for >>>>> constrained environments. >>>>> >>>>> Here I=C2=B9m missing among other things the specific problem state= ment. >>>>> The preliminary conclusions from the use case and requirements draf= t >>>>> formed the basis for the problem statement as presented in the BOF:= We >>>>> lack a mechanism for dynamic and fine grained access control for >>>>> constrained environments. >>>>> >>>>> The process here should be to: >>>>> "2=C2=B9) identify suitable protocol mechanisms and match candidate= >>>>> authentication and authorization protocols against requirements and= >>>>> design criteria, in particular addressing dynamic and fine grained >>>>> access control suitable for CoAP resource access requests in constr= ained >>>> environments." >>>>> >>>>> >>>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and >>>>> proxy deployments.=C2=B2 >>>>> >>>>> >>>>> As mentioned above, proxy deployments could be considered as part o= f >>>> 1=C2=B9b). >>>>> In 2=C2=B9) it is already stated that in particular we should consi= der CoAP >>>>> on interface (II). As for use of other protocols besides CoAP that >>>>> issue is orthogonal to this so I leave that out from this discussio= n. >>>>> >>>>> >>>>> >>>>> G=C3=B6ran >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/03/14 16:49, "Zach Shelby" wrote: >>>>> >>>>>> Hannes, >>>>>> >>>>>> I am happy with this charter with one exception. The proxy item he= re >>>>>> seems to be more of a distraction than anything else, and will >>>>>> probably result in increased complexity. Was proxy support maybe j= ust >>>>>> a misunderstanding? Do we really see the need for a proxy in the >>>>>> middle of I or III? >>>>>> >>>>>> I think what we really want here is to make sure that e.g. even >>>>>> through I is based on HTTP/TLS, II and III for example can run >>>>>> CoAP/DTLS. In other words, some interfaces can be constrained whil= e >>>>>> others are not. I think the charter already covers this fine. >>>>>> >>>>>> So my proposal would be to remove the mention of protocol translat= ion >>>>>> proxies. If we really see the need for this some day in the future= , >>>>>> it could be tackled then. >>>>>> >>>>>> Zach >>>>>> >>>>>> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I have taken the feedback from the meeting and the recent >>>>>>> discussions on the mailing list and produced a new strawman propo= sal. >>>>>>> >>>>>>> The changes include: >>>>>>> * Added the focus on DTLS/CoAP with an indication that we will ch= eck >>>>>>> a candidate solution for suitability with HTTP/TLS. >>>>>>> * Added text to indicate that we will also verify the suitability= of >>>>>>> the solution for use with protocol translation proxies. >>>>>>> * Simplified the task list by removing solution specific items. >>>>>>> * Merged several items on the task list (use cases, requirements,= >>>>>>> and protocol design guidelines). Followed the suggestion to use o= f a >>>>>>> Wiki for capturing those. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> ----- >>>>>>> >>>>>>> Draft Charter V0.5 - Authentication and Authorization for >>>>>>> Constrained Environment (ACE) >>>>>>> >>>>>>> The IETF has recently developed protocols for use in environments= >>>>>>> where network nodes are limited in CPU, memory, and power. It was= >>>>>>> observed that Internet protocols can be applied to these constrai= ned >>>>>>> environments, often only requiring minor tweaking and profiling. = In >>>>>>> other cases, new protocols have been defined to address the speci= fic >>>>>>> requirements of constrained devices and networks. An example of s= uch >>>>>>> a protocol is the Constrained Application Protocol (CoAP). >>>>>>> components >>>>>>> As in other environments, authentication and authorization questi= on >>>>>>> also arise in environments with constrained nodes and networks. F= or >>>>>>> example, a door lock has to authorize the person seeking access >>>>>>> using a "digital key". Where are the authorization decisions stor= ed? >>>>>>> How does the digital key communicate with the lock? Does the lock= >>>>>>> interact with an authorization server to obtain authorization >>>>>>> information? How can access be granted to other persons temporari= ly? >>>> How can access be revoked? >>>>>>> These types of questions have been answered by existing protocols= >>>>>>> for use cases outside the constrained environment. But in >>>>>>> constrained environment, additional requirements pose challenges = for >>>>>>> the use of various security protocols. >>>>>>> >>>>>>> The IETF has a long history in developing three party authenticat= ion >>>>>>> and authorization protocols for distributed environments. Example= s >>>>>>> include Kerberos, the Public Key Infrastructure (PKI), the >>>>>>> Authentication, Authorization, and Accounting (AAA) infrastructur= e, >>>>>>> and the Web Authorization Protocol (OAuth). All these protocols >>>>>>> enjoy widespread deployment on the Internet. Although they all ai= m >>>>>>> to solve a similar goal, at an abstract level, they offer quite >>>>>>> different functions and utilize different message exchanges. Thes= e >>>>>>> differences are motivated by the main deployment use cases they w= ere >>>> designed for. >>>>>>> Requirements derived from use cases indicate the suitability of >>>>>>> already existing work, such as OAuth, as a solution for constrain= ed >>>>>>> environments. These protocols were, however, not optimized for >>>>>>> constrained environments. Additional requirements that need to be= >>>>>>> taken into account are the lack of a suitable user-interface for >>>>>>> obtaining the consent of the user and the inability of embedded >>>>>>> devices to contact an authorization server in real-time with ever= y >>>>>>> access request due to intermittent connectivity, etc. >>>>>>> >>>>>>> This working group therefore aims for a standardized solution for= >>>>>>> authentication and authorization to enable authorized access to >>>>>>> resources in constrained environments. As a starting point, the >>>>>>> working group will assume that access to resources offered by a >>>>>>> resource server by a client devices takes place using CoAP and is= protected >>>> by DTLS. >>>>>>> Both resource server and client may be resource constraint. This >>>>>>> access will be mediated by an authorization server, which does no= t >>>>>>> suffer from the same resource limitations. >>>>>>> >>>>>>> Existing authentication and authorization protocols are used and >>>>>>> re-applied for use with constrained devices, where applicable. Th= is >>>>>>> requires relevant specifications to be reviewed for suitability, >>>>>>> selecting a subset of them, restricting the options within each o= f >>>>>>> the specifications. Some functionalities may, however, not be >>>>>>> available in existing protocols and for those cases new >>>>>>> functionality has to be standardized. Thus, existing work can be >>>>>>> leveraged and the group benefits from available security analysis= , >>>>>>> implementation, and deployment experience. Moreover, a standardiz= ed >>>>>>> solution for federated authentication and authorization will help= to >>>>>>> stimulate the deployment of IoT devices offering increased securi= ty. >>>>>>> >>>>>>> Once progress in identifying suitable candidate solutions has bee= n >>>>>>> made the working group will verify whether the same mechanism are= >>>>>>> also applicable beyond the use of CoAP and DTLS. In particular, t= he >>>>>>> ability to use the developed solution over HTTP and TLS will be >>>> investigated. >>>>>>> Furthermore, to guarantee smooth transition the integration with >>>>>>> existing deployment will be studied. This particularly concerns t= he >>>>>>> use of protocol translation proxies. >>>>>>> >>>>>>> To be successful this working group requires expertise in securit= y, >>>>>>> privacy, and a good understanding of usability in the constrained= >>>>>>> environment space. This work does not make the assumption that th= e >>>>>>> party offering application layer services is always the same part= y >>>>>>> offering network access services. >>>>>>> >>>>>>> The working group has the following tasks (in this order): >>>>>>> >>>>>>> 1) The working group Wiki pages will be used to document use case= s, >>>>>>> requirements, and protocol design criteria. This work will guide = the >>>>>>> identification of suitable protocol mechanisms. >>>>>>> >>>>>>> 2) Selection of an authentication and authorization protocol for >>>>>>> constrained environments. >>>>>>> >>>>>>> 3) Evaluation of the candidate solution for use with HTTP/TLS and= >>>>>>> proxy deployments. >>>>>>> >>>>>>> ----- >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ace mailing list >>>>>>> Ace@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ace >>>>>> Zach Shelby >>>>>> Director of Technology >>>>>> ARM Internet of Things BU >>>>>> www.arm.com >>>>>> mobile: +1 (408) 203-9434 >>>>>> Skype: zdshelby >>>>>> LinkedIn: fi.linkedin.com/in/zachshelby/ >>>>>> >>>>>> >>>>>> -- IMPORTANT NOTICE: The contents of this email and any attachment= s >>>>>> are confidential and may also be privileged. If you are not the >>>>>> intended recipient, please notify the sender immediately and do no= t >>>>>> disclose the contents to any other person, use it for any purpose,= or >>>>>> store or copy the information in any medium. Thank you. >>>>>> >>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9N= J, >>>>>> Registered in England & Wales, Company No: 2557590 ARM Holdings p= lc, >>>>>> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered= in >>>>>> England & Wales, Company No: 2548782 >>>>>> >>>>>> _______________________________________________ >>>>>> Ace mailing list >>>>>> Ace@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ace >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > Zach Shelby > Director of Technology > ARM Internet of Things BU > www.arm.com > mobile: +1 (408) 203-9434 > Skype: zdshelby > LinkedIn: fi.linkedin.com/in/zachshelby/ > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are= confidential and may also be privileged. If you are not the intended rec= ipient, please notify the sender immediately and do not disclose the cont= ents to any other person, use it for any purpose, or store or copy the in= formation in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Re= gistered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9N= J, Registered in England & Wales, Company No: 2548782 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------ms040009080905070200010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMTQxNTQ1NTRaMCMGCSqGSIb3DQEJBDEWBBTRYChJbXE85p0tM07fQhcUCmcm5zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAAMTvCsT4ANjH/Xa28ETwkSQTGgxoczgUn4rdccMQDxzIRy+ Ogo6YdtBUi+Q+G5NM8OyHdEFT3Sh0Q/8tL6e+LOaot+xMMxH3GUGwgeaEq6ZjGD6twYnSpPt O1eZs24UAXeGxLjtxtaRc2exl1ZNN+8oM03jOusWldO30lqgCiSrGi2qW2NtG8mloUFQuMX9 C6p93z7vHjci2XeR+r7ooQFN9qF4581RqBooMq8Fn3ymDEo6U1SrQuhvziWpmXRz6UOXS+lR 3DkURokpmr7+ywcMQj1+h9N+Cvi6pJo/ma2OuteI3RMO+a8R0VSlq9i7D+fL8kO+hpSZHcao 3qBIOmoAAAAAAAA= --------------ms040009080905070200010303-- From nobody Fri Mar 14 08:52:23 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F301A017B for ; Fri, 14 Mar 2014 08:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBKpkw1pjFJu for ; Fri, 14 Mar 2014 08:52:04 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) by ietfa.amsl.com (Postfix) with ESMTP id D1BD81A018F for ; Fri, 14 Mar 2014 08:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1394812302; l=4741; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=jPOA+TlNmHiYg1Gd4FA/S4iWuCY=; b=w7iBUFfbW2pt3n9NA7JxJawmFbfZrrixxbTiEupdenblrKYs+5EqV1oZ+YuQRSlEKFF YBF73GTN93WE8+6TZLgaFZSF9UCeG12Tr6aHPhS9I3+ucvpS6A6HPELC5vYBghWYP2BkY 2/68JfMa+N35qhoqMdKHu21UtfIfEAvk5lM= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSE4QZmtuQ X-RZG-CLASS-ID: mo00 Received: from mail-qc0-f171.google.com ([209.85.216.171]) by smtp.strato.de (RZmta 32.27 AUTH) with ESMTPSA id d067deq2EFpdUp5 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - certificate not trusted)) (Client hostname not verified) for ; Fri, 14 Mar 2014 16:51:39 +0100 (CET) Received: by mail-qc0-f171.google.com with SMTP id x13so3078938qcv.2 for ; Fri, 14 Mar 2014 08:51:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uowlL73mIbEgyFDC+wUFlmsCqlqc8F+zDDF+qRZztCw=; b=F/EDuqQMm49NPGSjQdAafbYfB30VqIuaDFXlw2FCMWqkxvNQo12+9Ha3wVfzU/D682 Kd3hG9pSH6fr+e12ZxtbqRoRY6CATKRBwBQdW2JyBXXF/fJWMil5ZLY8QcwJCVYpZYCd irK4Nw8gyoUen+8ubGvAcDAFQq6MoeFJ16ewiAPmcrRlOWzAw5Wuik8spI9jHuZAfFOR kvRtHi4BrWVpwYYTrkRiOLTypyEazsKvsZ0hbzcivuTz63LlMwFUsfTRahF+mCK81BiU NN5Q2hPUbxD43yu7YQQx+rwugQTZA4Lyjw+URSRgaBDqt9LJyXVSJgal0TfwNizFnjQZ hxFQ== MIME-Version: 1.0 X-Received: by 10.229.134.198 with SMTP id k6mr10243421qct.13.1394812298626; Fri, 14 Mar 2014 08:51:38 -0700 (PDT) Received: by 10.224.31.80 with HTTP; Fri, 14 Mar 2014 08:51:38 -0700 (PDT) In-Reply-To: <5321E0C3.5020802@gmx.net> References: <53210566.60100@gmx.net> <5321D764.5010000@gmx.net> <61D7C04F-9B17-4EAF-A565-A25A45B97756@tzi.org> <5321E0C3.5020802@gmx.net> Date: Fri, 14 Mar 2014 16:51:38 +0100 Message-ID: From: Sandeep Kumar To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1133e4ca96907f04f4930b92 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/o2liAYH85A9VRERM-SN4-o7DlYQ Cc: Carsten Bormann , =?ISO-8859-1?Q?G=F6ran_Selander?= , "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:52:07 -0000 --001a1133e4ca96907f04f4930b92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hannes The interoperability challenge you describe will be as much as a client implementing "the chosen" option that talks to a resource server which does not implement any option since it does not have the resources to implement "the chosen" option. Given few options, it will be the system designers who needs to mix-and-match devices based on the appropriate security requirements into their system. Keep the number of options extremely small (maybe 2). Sandeep On Thu, Mar 13, 2014 at 5:45 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Carsten, > > while that's an interesting way to post pone the problem it introduces > interoperability problems. > > Clients implementing one option who talk to resource servers > implementing different options. > > Do you see the interop challenges there? > > Ciao > Hannes > > > On 03/13/2014 05:37 PM, Carsten Bormann wrote: > > On 13 Mar 2014, at 17:05, Hannes Tschofenig > wrote: > > > >> I fully agree with the challenge you > >> identified regarding symmetric vs. asymmetric key crypto. It will be > >> difficult to reach a consensus on that topic > > > > I don't think that such a decision is possible or desirable. > > We didn't do that for CoAP (which has security modes, and preferred > cipher suites, for both shared-key and public-key), and we shouldn't try = to > do that here. > > > > Gr=FC=DFe, Carsten > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a1133e4ca96907f04f4930b92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes

The interoperability chal= lenge you describe will be as much as a client implementing "the chose= n" option that talks to a resource server which does not implement any= option since it does not have the resources to implement "the chosen&= quot; option. Given few options, it will be the system designers who needs = to mix-and-match devices based on the appropriate security requirements int= o their system. Keep the number of options extremely small (maybe 2).

Sandeep


On Thu, Mar 13, 2014 at 5:45 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Carsten,

while that's an interesting way to post pone the problem it introduces<= br> interoperability problems.

Clients implementing one option who talk to resource servers
implementing different options.

Do you see the interop challenges there?

Ciao
Hannes


On 03/13/2014 05:37 PM, Carsten Bormann wrote:
> On 13 Mar 2014, at 17:05, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
>> I fully agree with the challenge you
>> identified regarding symmetric vs. asymmetric key crypto. It will = be
>> difficult to reach a consensus on that topic
>
> I don’t think that such a decision is possible or desirable.
> We didn’t do that for CoAP (which has security modes, and prefer= red cipher suites, for both shared-key and public-key), and we shouldn&rsqu= o;t try to do that here.
>
> Gr=FC=DFe, Carsten
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace


--001a1133e4ca96907f04f4930b92-- From nobody Fri Mar 14 09:39:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BBE1A017F for ; Fri, 14 Mar 2014 09:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e3IjxPiknzd for ; Fri, 14 Mar 2014 09:39:49 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id D44B21A019C for ; Fri, 14 Mar 2014 09:39:12 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Fri, 14 Mar 2014 16:39:04 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Fri, 14 Mar 2014 09:39:13 -0700 From: Zach Shelby To: "robert.cragie@gridmerge.com" Date: Fri, 14 Mar 2014 09:39:03 -0700 Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: Ac8/o+6wskCx2r/zRkWvo7dA0wySqQ== Message-ID: <18A68374-320D-4377-BAA0-BD759F93EA01@arm.com> References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53231A15.4070000@gridmerge.com> <1939837E-246E-42BC-AA15-2ADD776B627F@arm.com> <53232432.9080906@gridmerge.com> In-Reply-To: <53232432.9080906@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114031416390414702 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Uj4tlM6xc3JD1xy3pkSFkkN-79E Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:39:51 -0000 On Mar 14, 2014, at 8:45 AM, Robert Cragie wr= ote: > Use a Wiki to collect use cases and requirements, refine and produce a > concise list. Then that could be cut and pasted into a single RFC - or > if preferred, put into an annex in a technical specification - as long > as the work has an endpoint and is captured in some document and not > left in some nebulous Wiki. Sure, I do think that would work. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Fri Mar 14 10:20:48 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2A81A0176 for ; Fri, 14 Mar 2014 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHfBDxc6Yaf5 for ; Fri, 14 Mar 2014 10:20:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id A1D1D1A017E for ; Fri, 14 Mar 2014 10:20:42 -0700 (PDT) Received: from [192.168.131.136] ([80.92.123.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6P5z-1XLGLR1IyJ-00yQu9; Fri, 14 Mar 2014 18:20:34 +0100 Message-ID: <53229E6A.4030103@gmx.net> Date: Fri, 14 Mar 2014 07:15:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sandeep Kumar References: <53210566.60100@gmx.net> <5321D764.5010000@gmx.net> <61D7C04F-9B17-4EAF-A565-A25A45B97756@tzi.org> <5321E0C3.5020802@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kpCsFIa8udIV8LEBPvS2SP43qJQOhXTv1" X-Provags-ID: V03:K0:j2Ax9tZN7FtG0yxTfaoff1VZkPtYeKMvlzUtolkgCxNQLgYuWQi prWjphNzWNf30pg6CnqbPd7FUI1FyhwB6JptKNYvBSBkqrQ0KShfcnC9MA/rzBkuJL9+wL1 ZdkhOCKeJer9J5lnQr5ngddYr8nPRRyLgpaF2IcbqQ5nS3VgviejP4yaG2d05gW1qpGPxmp Q33nE4SaRJryzIKBrVAQg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/b2938Nk1kgBPNVT33M2Bjaf2X44 Cc: Carsten Bormann , =?windows-1252?Q?G=F6ran_Selander?= , "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:20:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kpCsFIa8udIV8LEBPvS2SP43qJQOhXTv1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sandeep, if we call a specification describing a set of features a 'profile' then you are in essence saying that you want the group to standardize more than one profile. In this email thread we only spoken about the difference between symmetric vs. asymmetric crypto but there might be other differentiating features as well (pending further exploration). Did I interpret you correctly? Ciao Hannes On 03/14/2014 04:51 PM, Sandeep Kumar wrote: > Hi Hannes >=20 > The interoperability challenge you describe will be as much as a client= > implementing "the chosen" option that talks to a resource server which > does not implement any option since it does not have the resources to > implement "the chosen" option. Given few options, it will be the system= > designers who needs to mix-and-match devices based on the appropriate > security requirements into their system. Keep the number of options > extremely small (maybe 2). >=20 > Sandeep >=20 >=20 > On Thu, Mar 13, 2014 at 5:45 PM, Hannes Tschofenig > > wrote: >=20 > Hi Carsten, >=20 > while that's an interesting way to post pone the problem it introdu= ces > interoperability problems. >=20 > Clients implementing one option who talk to resource servers > implementing different options. >=20 > Do you see the interop challenges there? >=20 > Ciao > Hannes >=20 >=20 > On 03/13/2014 05:37 PM, Carsten Bormann wrote: > > On 13 Mar 2014, at 17:05, Hannes Tschofenig > > wrot= e: > > > >> I fully agree with the challenge you > >> identified regarding symmetric vs. asymmetric key crypto. It wil= l be > >> difficult to reach a consensus on that topic > > > > I don=92t think that such a decision is possible or desirable. > > We didn=92t do that for CoAP (which has security modes, and > preferred cipher suites, for both shared-key and public-key), and w= e > shouldn=92t try to do that here. > > > > Gr=FC=DFe, Carsten > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --kpCsFIa8udIV8LEBPvS2SP43qJQOhXTv1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIp5qAAoJEGhJURNOOiAtcpsH/ih3ym4N1VZnOuiixQzVdABI jFe9aS3bR1x+1LonllqnUhnu16irTGruY7r1OBQE2WvoW8PufQ+l7WoI5B1+5u/z YJsSeN6lbkynwAaFmtQOIuwfrraRcoVmEGYhMUVYZYaDhVlyt2o2s9RWRY7xQ/ld WF71kZRsRRR3l1nQN9Ds0TR+TIhIKeiWiSAkO6F/VdHNkWhGZNMbqGhNYwzWenJd onoM4HtyIeEKXB6/ufsZGvnc5hhD90AiqmotawxuyPWS0ZabrgquRoQ9E/fiO162 LZ64yMNZRD8MEq33lTEkaeb6gkD/zqf5zrIGduLXFb+O8qIKZZM9AFrZrq/doWQ= =yOgR -----END PGP SIGNATURE----- --kpCsFIa8udIV8LEBPvS2SP43qJQOhXTv1-- From nobody Sat Mar 15 12:20:18 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D884E1A019B for ; Sat, 15 Mar 2014 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAskHGzArZPg for ; Sat, 15 Mar 2014 12:20:15 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 03B3C1A0199 for ; Sat, 15 Mar 2014 12:20:14 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 238F620040; Sat, 15 Mar 2014 16:39:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E6195647C9; Sat, 15 Mar 2014 15:20:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CFEE0647C8; Sat, 15 Mar 2014 15:20:06 -0400 (EDT) From: Michael Richardson To: Margaret Wasserman In-Reply-To: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> References: <133A4AE5-7D89-4CDC-A47C-25F5D7C3E49B@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/aBjDQ1s9qoTPVfMI3LzCgHB3SMc Cc: "ace@ietf.org" Subject: Re: [Ace] Constrained Authorization Server? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 19:20:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Margaret Wasserman wrote: > In an offline discussion, I was asked whether I think the ACE effort > should > consider situations where the Authorization Server is a constrained > node. I > wrote the following answer, and I thought it might be useful to share > it here: > I think that depends on what you mean by "constrained". I don't think > an > authorization server needs to have a user input device, necessarily= =E2=80=A6 It To the extent that we now understand "user input" can also mean ethernet-li= ke (100tx/802.11) interface with HTTPS/RESTful interface that can speak to smartphone, and/or a transitive push connection (via "the cloud") to such a device, I think that the authorization has a user input. > If you assume that a "constrained" node can be > always-on/always-connected, > can have enough data storage to hold authentication and authorization > information for a network of nodes, and has enough CPU to run crypto > operations to service every connection that those nodes want to make = to > each other or to the outside=E2=80=A6 Well, if you assume that a cons= trained > node > can do those things, the problem becomes a lot easier. :-) I am prepared to assume that the AS has all of these things, and consider such a device to be far less constrained than the other devices, even if it can't run Office.. > So, no, I don't think of the authorization server as being a constrai= ned > node in the same sense as battery-operated sensors, actuators, etc. +1 =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting for hire =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUySn5oqHRg3pndX9AQLD3AQA7EAXrRFgyUdYpt4s8cJUK8OqG7iKRjc5 YT4Fi9HdEkjp5kDilXr29Gw0uze2lvIzOca55oLW7eSU2frz44B7Qwxkczwo6NOL KPYqRC6PTS7Jf5cKvVFYMbNQJH91ggbABmHNAWAo38N1GyDiP/kGFL2qd69IZnC0 skPpFQKQ10o= =Bptd -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 16 23:29:02 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889491A02D3 for ; Sun, 16 Mar 2014 23:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCqPNhcucFyc for ; Sun, 16 Mar 2014 23:28:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79F621A038E for ; Sun, 16 Mar 2014 23:28:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c9-5326962017ed Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 80.EB.10875.02696235; Mon, 17 Mar 2014 07:28:48 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.80]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Mon, 17 Mar 2014 07:28:48 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Hannes Tschofenig , Sandeep Kumar Thread-Topic: [Ace] Design Consideration Document as one milestone? Thread-Index: AQHPPrewRMKjLCAMGkyGQgBzpjAjyZrfHJ+AgAABaQCAAAixAIAAAnuAgAGDKgD//17rAIAEy5EA Date: Mon, 17 Mar 2014 06:28:47 +0000 Message-ID: References: <53210566.60100@gmx.net> <5321D764.5010000@gmx.net> <61D7C04F-9B17-4EAF-A565-A25A45B97756@tzi.org> <5321E0C3.5020802@gmx.net> <53229E6A.4030103@gmx.net> In-Reply-To: <53229E6A.4030103@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <09724B1A7F2D074685F602776B3459E2@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rldhmlqwwb4zyhbfv/UwWxyZcpfV YunOe6wWs7d1szmweCzetJ/NY8mSn0weu840MnlMW5QZwBLFZZOSmpNZllqkb5fAlfHlxR32 gg/6FRvmX2RsYJyv2sXIySEhYCKx58pSJghbTOLCvfVsXYxcHEIChxglfu9ZzArhLGaUWHzz PDtIFZuAq8SBB+/AOkQEQiQ2LtrPBmIzCzhKnL/XwwpiCws4Sax9P5sdosZZYvHBJYwQdpTE 1S3rwOpZBFQlmnsngNm8AuYS3/vuMEEsm8sk8X/zCrAEp4C6xJNFe8FsRqDzvp9awwSxTFzi 1pP5UGcLSCzZc54ZwhaVePn4H9gRogJ6EvcezWWBiCtJNC55wgrRqydxY+oUqKOtJdqvr4ey tSWWLXzNDHGQoMTJmU9YJjBKzEKybhaS9llI2mchaZ+FpH0BI+sqRvbcxMyc9HLDTYzAqDy4 5bfuDsZT50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdH7jP7B/Bz2 m+tTQx+rltr5Onitdbn6hFHzg+6laUJCx9cnbvy7bu/LjTuVRGxtmHXWlLeueDl7Z8Mv0/dT 1CTvPs2zZq3j2mrtn1AhcO9VkvDyDYFreGT2Shl8kaqIXGrc+vqlFvvc/T0NbfLSpw532Apb 5p4Pvt9+kdHxV2VS1eQ/wjdzs5VYijMSDbWYi4oTAT5tlcCYAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ydPiHQydJG4rAvKLnfmBskObXvQ Cc: Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] Design Consideration Document as one milestone? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 06:29:00 -0000 Trying to generalise Carsten's and Sandeep=B9s input on the various options of =B3symmetric vs. asymmetric=B2. Aren=B9t the two main questions about th= e following keys: =20 K1: What kind of keys shall be used by the Resource Server and Authorization Server to protect the authorisation information? K2: What kind of keys shall be used by the Client and Resource Server to protect the access request/response procedure? Two assumptions were made in the architecture presentation of the BOF: K0: There are keys established between RS and AS (what kind?). How these are established is out of scope for the work. P1: The keys in K1 can be used to establish the keys in K2. This protocol/algotrithm is in scope for the work. (P1 is one of the main tasks of ACE together with how to transfer authorization information from AS to RS, which may be the same protocol) =20 What we didn=B9t discuss in the BOF was whether the keys in K0 are identica= l to the keys in K1. If they are not, the implicit assumption is however: P0: The keys in K0 can be used to establish the keys in K1. This protocol/algorithm is in scope for the work. Then there are the meta questions like M1: Shall the work specify a single kind of keys K0, K1, K2? M2: Shall the work specify different cipher suites? Examples of working assumptions: Example 1. --- M1: yes=20 M2: no=20 K0: asymmetric=20 K1: symmetric=20 K2: symmetric=20 P0 could e.g. be Diffie-Hellman (say DTLS with raw public keys) P1 could be your favourite symmetric key candidate protocol Example 2. --- M1: yes =20 M2: yes=20 K0: symmetric=20 K1: symmetric=20 K2: asymmetric=20 K1 =3D K0, so there is no P0. The key used in K2 may be specified in the authorisation information, say "h(PK_C) has the right to GET /bloodpressure=B2, where h(PK_C) is the hash of the public key of the Client. P1 carries and protects the authorisation information and communicates also which cipher suite is to be used between Client and RS. Example 3. --- M1: no M2: no K0: asymmetric or symmetric K1: symmetric K2: symmetric The work specifies two alternatives for establishing the keys in K1 (say as in examples 1 or 2). The protocol P1 uses whatever keys K1. Now mapping Carsten's and Sandeep=B9s input to this terminology. Both answe= r M1: no. If I understand Carsten right he says that K2 should be symmetric. Some keys established between RS and AS may be either symmetric or asymmetric. Like in example 3? If I understand Sandeep right he is saying that we should allow both symmetric and asymmetric keys in K2, and he answers M2: yes. Were you thinking of communicating ciphersuites like in 2? Did I get it right? Is this helpful or does it just complicate matters? G=F6ran PS I left out potential keys used in communication between Client and AS because a) it is not necessary that they communicate at all b) the Client may use different keys in communicating with AS and RS, respectively c) the keys used may depend on access policy (see Ex. 2 above) and we want the authorisation solution to be independent of access policy. =20 On 14/03/14 07:15, "Hannes Tschofenig" wrote: >Hi Sandeep, > >if we call a specification describing a set of features a 'profile' then >you are in essence saying that you want the group to standardize more >than one profile. > >In this email thread we only spoken about the difference between >symmetric vs. asymmetric crypto but there might be other differentiating >features as well (pending further exploration). > >Did I interpret you correctly? > >Ciao >Hannes > >On 03/14/2014 04:51 PM, Sandeep Kumar wrote: >> Hi Hannes >>=20 >> The interoperability challenge you describe will be as much as a client >> implementing "the chosen" option that talks to a resource server which >> does not implement any option since it does not have the resources to >> implement "the chosen" option. Given few options, it will be the system >> designers who needs to mix-and-match devices based on the appropriate >> security requirements into their system. Keep the number of options >> extremely small (maybe 2). >>=20 >> Sandeep >>=20 >>=20 >> On Thu, Mar 13, 2014 at 5:45 PM, Hannes Tschofenig >> > wrote: >>=20 >> Hi Carsten, >>=20 >> while that's an interesting way to post pone the problem it >>introduces >> interoperability problems. >>=20 >> Clients implementing one option who talk to resource servers >> implementing different options. >>=20 >> Do you see the interop challenges there? >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On 03/13/2014 05:37 PM, Carsten Bormann wrote: >> > On 13 Mar 2014, at 17:05, Hannes Tschofenig >> > >>wrote: >> > >> >> I fully agree with the challenge you >> >> identified regarding symmetric vs. asymmetric key crypto. It >>will be >> >> difficult to reach a consensus on that topic >> > >> > I don=B9t think that such a decision is possible or desirable. >> > We didn=B9t do that for CoAP (which has security modes, and >> preferred cipher suites, for both shared-key and public-key), and we >> shouldn=B9t try to do that here. >> > >> > Gr=FC=DFe, Carsten >> > >> > _______________________________________________ >> > Ace mailing list >> > Ace@ietf.org >> > https://www.ietf.org/mailman/listinfo/ace >> > >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 > From nobody Mon Mar 17 00:31:57 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CDD1A03A7 for ; Mon, 17 Mar 2014 00:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gb01gij-A7U for ; Mon, 17 Mar 2014 00:31:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D700D1A006E for ; Mon, 17 Mar 2014 00:31:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEQ28410; Mon, 17 Mar 2014 07:31:43 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 07:31:33 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 07:31:32 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Mon, 17 Mar 2014 15:31:23 +0800 From: Bert Greevenbosch To: Hannes Tschofenig , Likepeng , Olaf Bergmann Thread-Topic: [Ace] Authorization server: a constrained device? Thread-Index: AQHPPsCDt1Q4YHjoakieLht9zvHe1prfJCLv//+FAoCAAYZWJIAEtcJQ Date: Mon, 17 Mar 2014 07:31:23 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E4634D5@SZXEMA510-MBX.china.huawei.com> References: <5321B255.3070801@gmx.net> <87eh26glu6.fsf@tzi.org> <5321D7D5.2000503@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B04A12@SZXEMA501-MBS.china.huawei.com> <5322127D.6080101@gmx.net> In-Reply-To: <5322127D.6080101@gmx.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/gq2ZlxeeZWsSqiwKZJXRYyq8Imc Cc: "ace@ietf.org" Subject: Re: [Ace] Authorization server: a constrained device? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 07:31:55 -0000 SGkgSGFubmVzLA0KDQpUaGUgQVMgY3VycmVudGx5IGhhcyB0d28gZnVuY3Rpb25zOg0KDQooMSkg UHJvdmlkaW5nIGFjY2VzcyBwZXJtaXNzaW9ucw0KKDIpIEFzc2lzdGluZyBjb25zdHJhaW5lZCBy ZXNvdXJjZSBzZXJ2ZXIgb3IgY2xpZW50IGluIG1ha2luZyBzZWN1cml0eSBkZWNpc2lvbnMNCg0K RXNwZWNpYWxseSAoMikgaW5kaWNhdGVzIHRoYXQgdGhlIEFTIGlzIG5vdCBjb25zdHJhaW5lZC4N Cg0KSSBndWVzcyB0aGlzIGlzIHF1aXRlIGluLWxpbmUgd2l0aCB0aGUgcGFyYWxsZWwgZGlzY3Vz c2lvbiAiQ29uc3RyYWluZWQgQXV0aG9yaXphdGlvbiBTZXJ2ZXIiLiAiQ29uc3RyYWluZWQiIGlz IGEgc29tZXdoYXQgdmFndWUgdGVybSwgYnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGFzc3VtZSBtb3Jl IHRoYW4gY2xhc3MgMiBmb3IgdGhlIEFTLg0KDQpEZXBlbmRpbmcgb24gdGhlIHByb3RvY29scyB3 ZSBhcmUgdXNpbmcsIHRoZSBBUyBtYXkgbmVlZCB0byBkbyBxdWl0ZSBzb21lIGJvb2trZWVwaW5n LCBlLmcuIG9mIENSTHMgYW5kIG1heWJlIGhhdmUgYSBkYXRhYmFzZSBhYm91dCB0aGUgY29uc3Ry YWluZWQgZGV2aWNlcyBpdCBtYXkgc2VydmUsIGFzIHdlbGwgYXMgdGhlaXIgKGFjdGl2ZSBhbmQv b3IgYXZhaWxhYmxlKSBwZXJtaXNzaW9ucy4NCg0KQmVzdCByZWdhcmRzLA0KQmVydA0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KPiBTZW50OiAxNCBN YXJjaCAyMDE0IDA0OjE4DQo+IFRvOiBMaWtlcGVuZzsgT2xhZiBCZXJnbWFubg0KPiBDYzogYWNl QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQWNlXSBBdXRob3JpemF0aW9uIHNlcnZlcjogYSBj b25zdHJhaW5lZCBkZXZpY2U/DQo+IA0KPiBUaGVyZSBpcyBzdGlsbCBhIGxvdCBvZiBiZW5lZml0 IHNpbmNlIGl0IGFsbG93cyB0byBjZW50cmFsbHkgbWFuYWdlDQo+IGF1dGhvcml6YXRpb24sIHdo aWNoIGlzIGZyb20gYSB1c2FiaWxpdHkgcG9pbnQgb2YgdmlldyBhIGJpZyBwbHVzLg0KPiBUb2Rh eSwgd2l0aCB0aGUgcGFpcmluZyBhcHByb2FjaCB5b3UgbmVlZCB0byBpbnRyb2R1Y2UgZWFjaCBk ZXZpY2UgdG8NCj4gYW55IG90aGVyIGRldmljZSAobGVhZGluZyB0byB0aGUgaGFuZHNoYWtlIHBy b2JsZW0gd2l0aCBuKG4tMSkvMg0KPiBjb21iaW5hdGlvbnMpLg0KPiANCj4gSGF2aW5nIHNhaWQg dGhhdCBJIGFtIGZpbmUgd2l0aCBqdXN0IGFzc3VtaW5nIHRoYXQgdGhlIGF1dGhvcml6YXRpb24N Cj4gc2VydmVyIGlzIG5vdCBjb25zdHJhaW5lZC4NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0K PiBPbiAwMy8xNC8yMDE0IDA3OjQzIEFNLCBMaWtlcGVuZyB3cm90ZToNCj4gPiBJZiBBdXRob3Jp emF0aW9uIFNlcnZlciBpcyBhbHNvIGNvbnN0cmFpbmVkLCB0aGVyZSBpcyBubyBtdWNoIGJlbmVm aXQNCj4gdG8gaGF2ZSBpdCBpbiB0aGUgYXJjaGl0ZWN0dXJlLg0KPiA+DQo+ID4gS2luZCBSZWdh cmRzDQo+ID4gS2VwZW5nDQo+ID4NCj4gPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+ILeivP7I yzogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSGFubmVzIFRzY2hvZmVu aWcNCj4gPj4gt6LLzcqxvOQ6IDIwMTTE6jPUwjE0yNUgMDowOA0KPiA+PiDK1bz+yMs6IE9sYWYg QmVyZ21hbm4NCj4gPj4gs63LzTogYWNlQGlldGYub3JnDQo+ID4+INb3zOI6IFJlOiBbQWNlXSBB dXRob3JpemF0aW9uIHNlcnZlcjogYSBjb25zdHJhaW5lZCBkZXZpY2U/DQo+ID4+DQo+ID4+IEhp IE9sYWYsDQo+ID4+DQo+ID4+IHRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIHZpZXdzLg0KPiA+Pg0K PiA+PiBUaGUgZGlzY3Vzc2lvbnMgYmVmb3JlIHRoZSBCT0YgaGFwcGVuZWQgaW4gYSByYXRoZXIg c21hbGwgZ3JvdXANCj4gPj4gKG1vc3RseQ0KPiA+PiBvZmZsaW5lKSBhbmQgbm93IHdlIGhhdmUg YSBsYXJnZXIgYXVkaWVuY2UgYW5kIHNvIGl0IHNlZW1lZCB0byBiZQ0KPiA+PiBmYWlyIHRvIHJl LXN0YXRlIHRoZSBxdWVzdGlvbiBhZ2FpbiAocGFydGljdWxhcmx5IGFmdGVyIHJlYWRpbmcNCj4g U2FtJ3MgZW1haWwpLg0KPiA+Pg0KPiA+PiBDaWFvDQo+ID4+IEhhbm5lcw0KPiA+Pg0KPiA+Pg0K PiA+PiBPbiAwMy8xMy8yMDE0IDA0OjI3IFBNLCBPbGFmIEJlcmdtYW5uIHdyb3RlOg0KPiA+Pj4g SGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyaXRlczoNCj4g Pj4+DQo+ID4+Pj4gcmVhZGluZyB0aHJvdWdoIFNhbSdzIGVtYWlsIGFuZCB2YXJpb3VzIGNvbW1l bnRzIGR1cmluZyB0aGUgQk9GIEkNCj4gPj4+PiB3YXMgd29uZGVyaW5nIHdoZXRoZXIgdGhlIGdy b3VwIGhhcyBhIGNvbnNlbnN1cyB0byBhc3N1bWUgdGhhdCB0aGUNCj4gPj4+PiBhdXRob3JpemF0 aW9uIGlzIG5vdCBhIGNvbnN0cmFpbmVkIGRldmljZS4NCj4gPj4+DQo+ID4+PiA+RnJvbSB3aGF0 IEkgdG9vayBmcm9tIHRoZSBkaXNjdXNzaW9ucyBzaW5jZSB0aGUgQmVybGluIElFVEYgdGhhdA0K PiA+Pj4gZXZlbnR1YWxseSBsZWQgdG8gdGhlIEFDRSBCb0YsIEkgYWx3YXlzIGhhZCB0aGUgaW1w cmVzc2lvbiB0aGF0IHRoZQ0KPiA+Pj4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaXMgcmVnYXJkZWQg YXMgbm90IGNvbnN0cmFpbmVkIGluIG5vbi10cml2aWFsDQo+ID4+PiB1c2UtY2FzZXMuDQo+ID4+ Pg0KPiA+Pj4gR3J1ZXNzZQ0KPiA+Pj4gT2xhZg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBBY2UgbWFpbGluZyBsaXN0 DQo+ID4+PiBBY2VAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYWNlDQo+ID4+Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBBY2UgbWFpbGluZyBsaXN0DQo+ID4gQWNlQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4gPg0K DQo= From nobody Mon Mar 17 00:34:52 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ADB1A0270 for ; Mon, 17 Mar 2014 00:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbVsV_QRcjaT for ; Mon, 17 Mar 2014 00:34:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9021A0124 for ; Mon, 17 Mar 2014 00:34:48 -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.7-GA FastPath queued) with ESMTP id BCD27856; Mon, 17 Mar 2014 07:34:40 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 07:34:32 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 07:34:38 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 17 Mar 2014 15:34:32 +0800 From: Likepeng To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] ACE Charter Proposal v0.6 Thread-Index: AQHPPrnTmdQyDUaRoUK9ubnDoEoVXJrk2fDQ Date: Mon, 17 Mar 2014 07:34:31 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B06276@SZXEMA501-MBS.china.huawei.com> References: <532108F4.10007@gmx.net> In-Reply-To: <532108F4.10007@gmx.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/xWB6KVdHmnKCOKg6Y7BwD4g7xpM Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 07:34:51 -0000 SSB1cGRhdGVkIG91ciB3aWtpIHBhZ2UgYWNjb3JkaW5nIHRvIEhhbm5lcycgY2hhcnRlciBwcm9w b3NhbDoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2NvcmUvdHJhYy93aWtpL0FDRV9j aGFydGVyIw0KDQpUaGUgY2hhbmdlcyBhcmUgaGlnaGxpZ2h0ZWQgaW4gYm9sZCBmb250Lg0KDQpQ bGVhc2UgcmV2aWV3IGl0IGFuZCBwcm92aWRlIHlvdXIgZmVlZGJhY2suDQoNClRoYW5rcywNCg0K S2luZCBSZWdhcmRzDQpLZXBlbmcNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBB Y2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBIYW5uZXMgVHNjaG9mZW5pZw0K PiC3osvNyrG85DogMjAxNMTqM9TCMTPI1SA5OjI1DQo+IMrVvP7IyzogYWNlQGlldGYub3JnDQo+ INb3zOI6IFtBY2VdIEFDRSBDaGFydGVyIFByb3Bvc2FsIHYwLjYNCj4gDQo+IC0tPiBIZXJlIGlz IGFuIHVwZGF0ZSBiYXNlZCBvbiBjb21tZW50cyBmcm9tIEdvZXJhbi4NCj4gDQo+IERyYWZ0IENo YXJ0ZXIgVjAuNiAtIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJh aW5lZA0KPiBFbnZpcm9ubWVudCAoQUNFKQ0KPiANCj4gVGhlIElFVEYgaGFzIHJlY2VudGx5IGRl dmVsb3BlZCBwcm90b2NvbHMgZm9yIHVzZSBpbiBlbnZpcm9ubWVudHMgd2hlcmUNCj4gbmV0d29y ayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSwgYW5kIHBvd2VyLiBJdCB3YXMgb2Jz ZXJ2ZWQgdGhhdA0KPiBJbnRlcm5ldCBwcm90b2NvbHMgY2FuIGJlIGFwcGxpZWQgdG8gdGhlc2Ug Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCBvZnRlbg0KPiBvbmx5IHJlcXVpcmluZyBtaW5vciB0 d2Vha2luZyBhbmQgcHJvZmlsaW5nLiBJbiBvdGhlciBjYXNlcywgbmV3IHByb3RvY29scw0KPiBo YXZlIGJlZW4gZGVmaW5lZCB0byBhZGRyZXNzIHRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMgb2Yg Y29uc3RyYWluZWQgZGV2aWNlcw0KPiBhbmQgbmV0d29ya3MuIEFuIGV4YW1wbGUgb2Ygc3VjaCBh IHByb3RvY29sIGlzIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbg0KPiBQcm90b2NvbCAoQ29B UCkuDQo+IA0KPiBBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIHF1ZXN0aW9uIGFsc28gYXJpc2UNCj4gaW4gZW52aXJvbm1lbnRzIHdpdGgg Y29uc3RyYWluZWQgbm9kZXMgYW5kIG5ldHdvcmtzLiBGb3IgZXhhbXBsZSwgYSBkb29yDQo+IGxv Y2sgaGFzIHRvIGF1dGhvcml6ZSB0aGUgcGVyc29uIHNlZWtpbmcgYWNjZXNzIHVzaW5nIGEgImRp Z2l0YWwga2V5Ii4gV2hlcmUgYXJlDQo+IHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBzdG9y ZWQ/IEhvdyBkb2VzIHRoZSBkaWdpdGFsIGtleSBjb21tdW5pY2F0ZQ0KPiB3aXRoIHRoZSBsb2Nr PyBEb2VzIHRoZSBsb2NrIGludGVyYWN0IHdpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8g b2J0YWluDQo+IGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24/IEhvdyBjYW4gYWNjZXNzIGJlIGdy YW50ZWQgdG8gb3RoZXIgcGVyc29ucw0KPiB0ZW1wb3JhcmlseT8gSG93IGNhbiBhY2Nlc3MgYmUg cmV2b2tlZD8NCj4gVGhlc2UgdHlwZXMgb2YgcXVlc3Rpb25zIGhhdmUgYmVlbiBhbnN3ZXJlZCBi eSBleGlzdGluZyBwcm90b2NvbHMgZm9yIHVzZQ0KPiBjYXNlcyBvdXRzaWRlIHRoZSBjb25zdHJh aW5lZCBlbnZpcm9ubWVudC4gQnV0IGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50LA0KPiBhZGRp dGlvbmFsIHJlcXVpcmVtZW50cyBwb3NlIGNoYWxsZW5nZXMgZm9yIHRoZSB1c2Ugb2YgdmFyaW91 cyBzZWN1cml0eQ0KPiBwcm90b2NvbHMuIEluIHBhcnRpY3VsYXIsIHRoZSBuZWVkIGZvciBhIGR5 bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZCBhY2Nlc3MgY29udHJvbA0KPiBtZWNoYW5pc20gd2hlcmVi eSBjbGllbnRzIGFuZC9vciByZXNvdXJjZSBzZXJ2ZXJzIHN1ZmZlciBmcm9tIGNvbnN0cmFpbnRz DQo+IGFyaXNlcy4NCj4gDQo+IFRoZSBJRVRGIGhhcyBhIGxvbmcgaGlzdG9yeSBpbiBkZXZlbG9w aW5nIHRocmVlIHBhcnR5IGF1dGhlbnRpY2F0aW9uIGFuZA0KPiBhdXRob3JpemF0aW9uIHByb3Rv Y29scyBmb3IgZGlzdHJpYnV0ZWQgZW52aXJvbm1lbnRzLiBFeGFtcGxlcyBpbmNsdWRlDQo+IEtl cmJlcm9zLCB0aGUgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKSwgdGhlIEF1dGhlbnRp Y2F0aW9uLA0KPiBBdXRob3JpemF0aW9uLCBhbmQgQWNjb3VudGluZyAoQUFBKSBpbmZyYXN0cnVj dHVyZSwgYW5kIHRoZSBXZWINCj4gQXV0aG9yaXphdGlvbiBQcm90b2NvbCAoT0F1dGgpLiBBbGwg dGhlc2UgcHJvdG9jb2xzIGVuam95IHdpZGVzcHJlYWQNCj4gZGVwbG95bWVudCBvbiB0aGUgSW50 ZXJuZXQuIEFsdGhvdWdoIHRoZXkgYWxsIGFpbSB0byBzb2x2ZSBhIHNpbWlsYXIgZ29hbCwgYXQg YW4NCj4gYWJzdHJhY3QgbGV2ZWwsIHRoZXkgb2ZmZXIgcXVpdGUgZGlmZmVyZW50IGZ1bmN0aW9u cyBhbmQgdXRpbGl6ZSBkaWZmZXJlbnQgbWVzc2FnZQ0KPiBleGNoYW5nZXMuIFRoZXNlIGRpZmZl cmVuY2VzIGFyZSBtb3RpdmF0ZWQgYnkgdGhlIG1haW4gZGVwbG95bWVudCB1c2UgY2FzZXMNCj4g dGhleSB3ZXJlIGRlc2lnbmVkIGZvci4NCj4gDQo+IFJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20g dXNlIGNhc2VzIGluZGljYXRlIHRoZSBzdWl0YWJpbGl0eSBvZiBhbHJlYWR5IGV4aXN0aW5nDQo+ IHdvcmssIHN1Y2ggYXMgT0F1dGgsIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkIGVudmly b25tZW50cy4gVGhlc2UNCj4gcHJvdG9jb2xzIHdlcmUsIGhvd2V2ZXIsIG5vdCBvcHRpbWl6ZWQg Zm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCj4gQWRkaXRpb25hbCByZXF1aXJlbWVudHMg dGhhdCBuZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBhcmUgdGhlIGxhY2sgb2YgYQ0KPiBz dWl0YWJsZSB1c2VyLWludGVyZmFjZSBmb3Igb2J0YWluaW5nIHRoZSBjb25zZW50IG9mIHRoZSB1 c2VyIGFuZCB0aGUgaW5hYmlsaXR5DQo+IG9mIGVtYmVkZGVkIGRldmljZXMgdG8gY29udGFjdCBh biBhdXRob3JpemF0aW9uIHNlcnZlciBpbiByZWFsLXRpbWUgd2l0aCBldmVyeQ0KPiBhY2Nlc3Mg cmVxdWVzdCBkdWUgdG8gaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSwgZXRjLg0KPiANCj4gVGhp cyB3b3JraW5nIGdyb3VwIHRoZXJlZm9yZSBhaW1zIGZvciBhIHN0YW5kYXJkaXplZCBzb2x1dGlv biBmb3INCj4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gdG8gZW5hYmxlIGF1dGhv cml6ZWQgYWNjZXNzIHRvIHJlc291cmNlcyBpbg0KPiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMu IEFzIGEgc3RhcnRpbmcgcG9pbnQsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYXNzdW1lDQo+IHRo YXQgYWNjZXNzIHRvIHJlc291cmNlcyBvZmZlcmVkIGJ5IGEgcmVzb3VyY2Ugc2VydmVyIGJ5IGEg Y2xpZW50IGRldmljZXMgdGFrZXMNCj4gcGxhY2UgdXNpbmcgQ29BUCBhbmQgaXMgcHJvdGVjdGVk IGJ5IERUTFMuDQo+IEJvdGggcmVzb3VyY2Ugc2VydmVyIGFuZCBjbGllbnQgbWF5IGJlIHJlc291 cmNlIGNvbnN0cmFpbnQuIFRoaXMgYWNjZXNzIHdpbGwgYmUNCj4gbWVkaWF0ZWQgYnkgYW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXIsIHdoaWNoIGRvZXMgbm90IHN1ZmZlciBmcm9tIHRoZSBzYW1lDQo+ IHJlc291cmNlIGxpbWl0YXRpb25zLg0KPiANCj4gRXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5k IGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGFyZSB1c2VkIGFuZCByZS1hcHBsaWVkDQo+IGZvciB1 c2Ugd2l0aCBjb25zdHJhaW5lZCBkZXZpY2VzLCB3aGVyZSBhcHBsaWNhYmxlLiBUaGlzIHJlcXVp cmVzIHJlbGV2YW50DQo+IHNwZWNpZmljYXRpb25zIHRvIGJlIHJldmlld2VkIGZvciBzdWl0YWJp bGl0eSwgc2VsZWN0aW5nIGEgc3Vic2V0IG9mIHRoZW0sDQo+IHJlc3RyaWN0aW5nIHRoZSBvcHRp b25zIHdpdGhpbiBlYWNoIG9mIHRoZSBzcGVjaWZpY2F0aW9ucy4gU29tZSBmdW5jdGlvbmFsaXRp ZXMNCj4gbWF5LCBob3dldmVyLCBub3QgYmUgYXZhaWxhYmxlIGluIGV4aXN0aW5nIHByb3RvY29s cyBhbmQgZm9yIHRob3NlIGNhc2VzIG5ldw0KPiBmdW5jdGlvbmFsaXR5IGhhcyB0byBiZSBzdGFu ZGFyZGl6ZWQuIFRodXMsIGV4aXN0aW5nIHdvcmsgY2FuIGJlIGxldmVyYWdlZCBhbmQNCj4gdGhl IGdyb3VwIGJlbmVmaXRzIGZyb20gYXZhaWxhYmxlIHNlY3VyaXR5IGFuYWx5c2lzLCBpbXBsZW1l bnRhdGlvbiwgYW5kDQo+IGRlcGxveW1lbnQgZXhwZXJpZW5jZS4gTW9yZW92ZXIsIGEgc3RhbmRh cmRpemVkIHNvbHV0aW9uIGZvciBmZWRlcmF0ZWQNCj4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhv cml6YXRpb24gd2lsbCBoZWxwIHRvIHN0aW11bGF0ZSB0aGUgZGVwbG95bWVudCBvZiBJb1QNCj4g ZGV2aWNlcyBvZmZlcmluZyBpbmNyZWFzZWQgc2VjdXJpdHkuDQo+IA0KPiBPbmNlIHByb2dyZXNz IGluIGlkZW50aWZ5aW5nIHN1aXRhYmxlIGNhbmRpZGF0ZSBzb2x1dGlvbnMgaGFzIGJlZW4gbWFk ZSB0aGUNCj4gd29ya2luZyBncm91cCB3aWxsIHZlcmlmeSB3aGV0aGVyIHRoZSBzYW1lIG1lY2hh bmlzbSBhcmUgYWxzbyBhcHBsaWNhYmxlDQo+IGJleW9uZCB0aGUgdXNlIG9mIENvQVAgYW5kIERU TFMsIHdoaWNoIGFyZSB0aGUgdHdvIG1haW4gcHJvdG9jb2xzIHRoZSBncm91cA0KPiB3aWxsIGZv Y3VzIG9uIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgYWJpbGl0 eSB0byB1c2UgdGhlDQo+IGRldmVsb3BlZCBzb2x1dGlvbiBvdmVyIEhUVFAgYW5kIFRMUyB3aWxs IGJlIGludmVzdGlnYXRlZC4gRnVydGhlcm1vcmUsIHRvDQo+IGd1YXJhbnRlZSBzbW9vdGggdHJh bnNpdGlvbiB0aGUgaW50ZWdyYXRpb24gd2l0aCBleGlzdGluZyBkZXBsb3ltZW50IHdpbGwgYmUN Cj4gc3R1ZGllZC4gVGhpcyBwYXJ0aWN1bGFybHkgY29uY2VybnMgdGhlIHVzZSBvZiBwcm90b2Nv bCB0cmFuc2xhdGlvbiBwcm94aWVzLg0KPiANCj4gVG8gYmUgc3VjY2Vzc2Z1bCB0aGlzIHdvcmtp bmcgZ3JvdXAgcmVxdWlyZXMgZXhwZXJ0aXNlIGluIHNlY3VyaXR5LCBwcml2YWN5LCBhbmQNCj4g YSBnb29kIHVuZGVyc3RhbmRpbmcgb2YgdXNhYmlsaXR5IGluIHRoZSBjb25zdHJhaW5lZCBlbnZp cm9ubWVudCBzcGFjZS4gVGhpcw0KPiB3b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3VtcHRpb24g dGhhdCB0aGUgcGFydHkgb2ZmZXJpbmcgYXBwbGljYXRpb24gbGF5ZXINCj4gc2VydmljZXMgaXMg YWx3YXlzIHRoZSBzYW1lIHBhcnR5IG9mZmVyaW5nIG5ldHdvcmsgYWNjZXNzIHNlcnZpY2VzLg0K PiANCj4gVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRoZSBmb2xsb3dpbmcgdGFza3MgKGluIHRoaXMg b3JkZXIpOg0KPiANCj4gMSkgVXNlIGNhc2VzLCByZXF1aXJlbWVudHMsIGFuZCBkZXNpZ24gY3Jp dGVyaWEuDQo+IFtbRGV0YWlscyBwZW5kaW5nIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uLl1dIFRo aXMgd29yayB3aWxsIGd1aWRlIHRoZQ0KPiBpZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90 b2NvbCBtZWNoYW5pc21zLg0KPiANCj4gMikgU2VsZWN0aW9uIG9mIGFuIGF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sIGZvciBjb25zdHJhaW5lZA0KPiBlbnZpcm9ubWVu dHMuDQo+IA0KPiAzKSBFdmFsdWF0aW9uIG9mIHRoZSBjYW5kaWRhdGUgc29sdXRpb24gZm9yIHVz ZSB3aXRoIEhUVFAvVExTIGFuZCBwcm94eQ0KPiBkZXBsb3ltZW50cy4NCj4gW1tEZXRhaWxzIHBl bmRpbmcgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24uXV0NCg0K From nobody Mon Mar 17 02:31:10 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27D71A0051 for ; Mon, 17 Mar 2014 02:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC5UOC-rpzaX for ; Mon, 17 Mar 2014 02:31:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6B81A004A for ; Mon, 17 Mar 2014 02:31:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEQ41176; Mon, 17 Mar 2014 09:30:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 09:30:50 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 09:30:56 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 17 Mar 2014 17:30:53 +0800 From: Bert Greevenbosch To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] ACE Charter Proposal v0.6 Thread-Index: AQHPPrnStDQl89pMzEmxWhR94zRq3Jrk9rvQ Date: Mon, 17 Mar 2014 09:30:52 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> References: <532108F4.10007@gmx.net> In-Reply-To: <532108F4.10007@gmx.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/bfaMJ9cBbbK2e_YYQrLHF-kDmys Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 09:31:09 -0000 I have reviewed the new charter. I have a comment on the following task: > 2) Selection of an authentication and authorization protocol for constrai= ned environments. I think there is more to it than "selection", especially since we may need = to make some adjustments or define something new for the constrained case. So I support G=F6ran's proposal to change the task, but I propose a slightl= y different version: > 2) Identify suitable authentication and authorization mechanisms, in part= icular addressing dynamic and fine grained access control suitable for CoAP= resource access requests in constrained environments. What do you think? Best regards, Bert > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: 13 March 2014 09:25 > To: ace@ietf.org > Subject: [Ace] ACE Charter Proposal v0.6 >=20 > --> Here is an update based on comments from Goeran. >=20 > Draft Charter V0.6 - Authentication and Authorization for Constrained > Environment (ACE) >=20 > The IETF has recently developed protocols for use in environments where > network nodes are limited in CPU, memory, and power. It was observed > that Internet protocols can be applied to these constrained > environments, often only requiring minor tweaking and profiling. In > other cases, new protocols have been defined to address the specific > requirements of constrained devices and networks. An example of such a > protocol is the Constrained Application Protocol (CoAP). >=20 > As in other environments, authentication and authorization question > also arise in environments with constrained nodes and networks. For > example, a door lock has to authorize the person seeking access using a > "digital key". Where are the authorization decisions stored? How does > the digital key communicate with the lock? Does the lock interact with > an authorization server to obtain authorization information? How can > access be granted to other persons temporarily? How can access be > revoked? > These types of questions have been answered by existing protocols for > use cases outside the constrained environment. But in constrained > environment, additional requirements pose challenges for the use of > various security protocols. In particular, the need for a dynamic and > fine grained access control mechanism whereby clients and/or resource > servers suffer from constraints arises. >=20 > The IETF has a long history in developing three party authentication > and authorization protocols for distributed environments. Examples > include Kerberos, the Public Key Infrastructure (PKI), the > Authentication, Authorization, and Accounting (AAA) infrastructure, and > the Web Authorization Protocol (OAuth). All these protocols enjoy > widespread deployment on the Internet. Although they all aim to solve a > similar goal, at an abstract level, they offer quite different > functions and utilize different message exchanges. These differences > are motivated by the main deployment use cases they were designed for. >=20 > Requirements derived from use cases indicate the suitability of already > existing work, such as OAuth, as a solution for constrained > environments. These protocols were, however, not optimized for > constrained environments. Additional requirements that need to be taken > into account are the lack of a suitable user-interface for obtaining > the consent of the user and the inability of embedded devices to > contact an authorization server in real-time with every access request > due to intermittent connectivity, etc. >=20 > This working group therefore aims for a standardized solution for > authentication and authorization to enable authorized access to > resources in constrained environments. As a starting point, the working > group will assume that access to resources offered by a resource server > by a client devices takes place using CoAP and is protected by DTLS. > Both resource server and client may be resource constraint. This access > will be mediated by an authorization server, which does not suffer from > the same resource limitations. >=20 > Existing authentication and authorization protocols are used and re- > applied for use with constrained devices, where applicable. This > requires relevant specifications to be reviewed for suitability, > selecting a subset of them, restricting the options within each of the > specifications. Some functionalities may, however, not be available in > existing protocols and for those cases new functionality has to be > standardized. Thus, existing work can be leveraged and the group > benefits from available security analysis, implementation, and > deployment experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of IoT devices offering increased security. >=20 > Once progress in identifying suitable candidate solutions has been made > the working group will verify whether the same mechanism are also > applicable beyond the use of CoAP and DTLS, which are the two main > protocols the group will focus on for access to resources. In > particular, the ability to use the developed solution over HTTP and TLS > will be investigated. Furthermore, to guarantee smooth transition the > integration with existing deployment will be studied. This particularly > concerns the use of protocol translation proxies. >=20 > To be successful this working group requires expertise in security, > privacy, and a good understanding of usability in the constrained > environment space. This work does not make the assumption that the > party offering application layer services is always the same party > offering network access services. >=20 > The working group has the following tasks (in this order): >=20 > 1) Use cases, requirements, and design criteria. > [[Details pending mailing list discussion.]] This work will guide the > identification of suitable protocol mechanisms. >=20 > 2) Selection of an authentication and authorization protocol for > constrained environments. >=20 > 3) Evaluation of the candidate solution for use with HTTP/TLS and proxy > deployments. > [[Details pending mailing list discussion.]] From nobody Mon Mar 17 03:24:18 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD381A03CA for ; Mon, 17 Mar 2014 03:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qga3CKBAF7Kh for ; Mon, 17 Mar 2014 03:24:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F11181A03CB for ; Mon, 17 Mar 2014 03:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2HANTxx021405; Mon, 17 Mar 2014 11:23:29 +0100 (CET) Received: from eduroam-pool7-2006.wlan.uni-bremen.de (eduroam-pool7-2006.wlan.uni-bremen.de [134.102.119.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8181A837; Mon, 17 Mar 2014 11:23:29 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> Date: Mon, 17 Mar 2014 11:23:28 +0100 X-Mao-Original-Outgoing-Id: 416744608.36127-6f80f72b1f0930a59cc0850944c4dde9 Content-Transfer-Encoding: quoted-printable Message-Id: <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/oCCUA-TmBMUaR74jCavNQf7T3C4 Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:24:16 -0000 On 17 Mar 2014, at 10:30, Bert Greevenbosch = wrote: >> 2) Selection of an authentication and authorization protocol for = constrained environments. >=20 > I think there is more to it than "selection", especially since we may = need to make some adjustments or define something new for the = constrained case. Indeed. > So I support G=F6ran's proposal to change the task, but I propose a = slightly different version: >=20 >> 2) Identify suitable authentication and authorization mechanisms, in = particular addressing dynamic and fine grained access control suitable = for CoAP resource access requests in constrained environments. >=20 > What do you think? We can try to weasel around this, but if this group is successful, the = result will be the definition of certain new protocol components. Reusing existing mechanisms, (abstract) protocols, or even encodings as = much as possible is desirable, but there also is an objective to be met = here. This is not possible by stitching together a Frankenprotocol (which, by = composing old elements in a new way, still would be a new protocol). Gr=FC=DFe, Carsten From nobody Mon Mar 17 03:26:40 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C681A03C7 for ; Mon, 17 Mar 2014 03:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEjPRKQlefzd for ; Mon, 17 Mar 2014 03:26:37 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) by ietfa.amsl.com (Postfix) with ESMTP id C469B1A00A6 for ; Mon, 17 Mar 2014 03:26:36 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2014-03-16 mail.cs.helsinki.fi Mon, 17 Mar 2014 12:26:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=dkim20130528; bh=vaZbgRxsPYQe7Tu+s qhJDNqpoq+WycbA7rPL/CPHTHM=; b=VLrod5BtJ5Tz/0cZFCii8jhCAqoOB9X/o xL9b7K7qPbMU+Ntxc5e5Lv5VMUn/gVz2fszPAS8SV9cfbMfzzgtgSWBBetv0Nora uVMIYSvJ2JDtcfO9HFXDboSK6YQyoM80aOZJIglpnWU6bnKYHu257YT+kV3ywzsb iEgYZgtDUk= Received: from [10.23.252.45] (client-7-198.eduroam.oxuni.org.uk [192.76.7.198]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with ESMTPSA; Mon, 17 Mar 2014 12:26:24 +0200 id 00000000000826B3.000000005326CDD0.00001652 Message-ID: <5326CDD0.4080204@cs.helsinki.fi> Date: Mon, 17 Mar 2014 12:26:24 +0200 From: Andrei Gurtov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ace@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/jXnu5T_64fOXPE6KWKVFNfxbw2c Subject: [Ace] 802.15.9 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:26:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I think the charter should include the use of IEEE 802.15.9 KMP protocols and development of API to provide channel binding towards applications http://www.ietf.org/proceedings/84/slides/slides-84-roll-3.pdf http://ieee802.org/15/par.html br Andrei - -- Andrei Gurtov, PhD Principal Scientist, Helsinki Institute for Information Technology HIIT Adjunct Professor Aalto University, University of Oulu and University of Helsinki http://www.hiit.fi/~gurtov https://www.researchgate.net/profile/Andrei_Gurtov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMmzdAACgkQP7jp0uceFkTg+gCfWeCr4jn27qoIESt+Xo0L7SS2 V4AAnR+VT3NVFl4FVv6xEG9a7bC3sKKg =hIzw -----END PGP SIGNATURE----- From nobody Mon Mar 17 03:35:28 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2DC1A03C9 for ; Mon, 17 Mar 2014 03:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYURoJuz1iqe for ; Mon, 17 Mar 2014 03:35:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6FA1A03C7 for ; Mon, 17 Mar 2014 03:35:24 -0700 (PDT) Received: from [192.168.131.137] ([80.92.123.72]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MNIO5-1WWNa72xHV-006zHN; Mon, 17 Mar 2014 11:35:15 +0100 Message-ID: <5326CDA7.40707@gmx.net> Date: Mon, 17 Mar 2014 11:25:43 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andrei Gurtov , ace@ietf.org References: <5326CDD0.4080204@cs.helsinki.fi> In-Reply-To: <5326CDD0.4080204@cs.helsinki.fi> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vuUPhj9D8lTc0ahk0LFujAQPep6qVet3v" X-Provags-ID: V03:K0:AR1DIZoIFKvqXklj21W9pLi0mMhhmFGGDowwTtiS3M6u4sudpLf vBMpXLl9ue/qZdrU2is2nG/S0n4rPUaxqiZt6qDu4y+o/weRk3OI7Kh28Xrak7IU0m/W4TT jjKteQeoQ93g2yUSZOqEp54+seGotwuJ9/CFgKPY8z91O9Uwa5KMOCh1YZcX0a1rKr0QDek V3qO0t07J3uHwpMKVSC2g== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/_4oZXl_lv_yrI9VIcDg2XcgTq7k Subject: Re: [Ace] 802.15.9 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:35:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vuUPhj9D8lTc0ahk0LFujAQPep6qVet3v Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrei, we should definitely track this work (whenever something becomes public).= It is, however, my impression that this IEEE work is focused on an authentication and key exchange solution on the link layer and we are focusing on an application layer solution (which lead us to discuss the dependency on CoAP). Is this correct? While there are cases where only two neighbouring nodes talk to each other I believe that this is not the only scenario people have in mind. It does, however, raise the question between the link layer mechanism and the application layer security story. If you want to optimize the entire system then paying attention to the security mechanism at the other layers obviously makes sense. In that sense it is understandable that the 6tisch work was presented to us as well. Ciao Hannes On 03/17/2014 11:26 AM, Andrei Gurtov wrote: > Hi, >=20 > I think the charter should include the use of IEEE 802.15.9 KMP > protocols and development of API to provide channel binding towards > applications > http://www.ietf.org/proceedings/84/slides/slides-84-roll-3.pdf > http://ieee802.org/15/par.html >=20 > br > Andrei >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --vuUPhj9D8lTc0ahk0LFujAQPep6qVet3v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTJs2nAAoJEGhJURNOOiAtq8IIAJPVlHNCbmXZPR4raBvyeXWD gPONTj07EQID23Bpv6RfHqpp1+oVui90oWAlg5wp7PPXJl5ovEZb03DgahHPcuo9 MGu8yrAoYEGkMuQFmOZcSbMK4maB+hZzAO9PX1ZmyydBS8U8VT2KOF95EJHfO2pT Od6Da2Md838wZPdUc4nL8/28Cehd3L0KR1ciwkjAZLw67AF5/nnEZ42x3lbD9j16 uK+T5MNmtUlQ4aZ+ypjS+ji2wMoFkKCscnXoTm75tbfDGzpNS9f8d4EbranTiAwC Ft4ij1IEHz+Ct/ydyD8r3bXH63GwZvda7jPYkl8nDIxqKFma6XsQhUKtdN/P2H8= =yOU7 -----END PGP SIGNATURE----- --vuUPhj9D8lTc0ahk0LFujAQPep6qVet3v-- From nobody Mon Mar 17 06:21:20 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3DD1A0201 for ; Mon, 17 Mar 2014 06:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QldCXch_fE7g for ; Mon, 17 Mar 2014 06:21:16 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 271241A011C for ; Mon, 17 Mar 2014 06:21:16 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id j7so5203439qaq.36 for ; Mon, 17 Mar 2014 06:21:08 -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; bh=EpW6rU7+SxmdkGkGRKtoIumfaYc4AOD6fI+MBSJehSE=; b=Ni2YHWPBkF+EALRFZzl23XjJjEuHHt6yxdhlH3fjndY6u7Z4p/u+Or0BzIUPDbYYmt cN9tHpMN6BAz3AGuSZQqt9AOo9N+fRrIu/x8fYUqwV/8gNtpAKuP+CSC8QRAVMoG0yAT fH2bLkn4hZNciXAYB4RxPYKQ+tM4pfMBlGfSKRbjpaJ1CEhx99JdHefiQnwfYA4sVslv ReJxeFgYmV/maruly10bb060JLr8ck6NYDQvFwwswhchnL6bVNpgKnHHCx0VoOGmocBI wuAI6/SHwkIyREYKYPrIKraUXzLzx5QAY07qKcb9C05bknJlUqBQYzxInwoTBJcyN8yB eyNw== X-Received: by 10.229.116.193 with SMTP id n1mr28210599qcq.10.1395062468077; Mon, 17 Mar 2014 06:21:08 -0700 (PDT) Received: from new-host.home (pool-108-7-235-60.bstnma.fios.verizon.net. [108.7.235.60]) by mx.google.com with ESMTPSA id t104sm2399173qga.8.2014.03.17.06.21.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 06:21:06 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Wasserman In-Reply-To: <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> Date: Mon, 17 Mar 2014 09:21:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/6ODKB_r8eEw0DeRIzGnW9-QcsD0 Cc: Bert Greevenbosch , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 13:21:18 -0000 Hi Carsten, On Mar 17, 2014, at 6:23 AM, Carsten Bormann wrote: > On 17 Mar 2014, at 10:30, Bert Greevenbosch = wrote: >>=20 >> I think there is more to it than "selection", especially since we may = need to make some adjustments or define something new for the = constrained case. >=20 > Indeed. I agree with this, too. I think the charter should be open to = profiling, adjusting or extending existing security mechanisms to meet = the needs of this environment. >>> 2) Identify suitable authentication and authorization mechanisms, in = particular addressing dynamic and fine grained access control suitable = for CoAP resource access requests in constrained environments. >>=20 >> What do you think? I think this goes too far into the requirements space=85 I think we are = planning to define the requirements and architecture as part of the = charter, and I think that one area that needs a lot of discussion is = what our requirements are for access control, and what roles the RS and = AS will play in that. For instance, we might decide that we want an = attribute or role-based system where the authentication process returns = various attributes and/or roles associated with the authenticated user, = and that information is used by the RS to determine what access should = be allowed. In that case, the granularity of the access control could = be application-specific and would be a matter of AS configuration and = local implementation on the RS. I want our charter to lean _strongly_ in the direction of preferring a = solution that is based on existing security protocol standards, = unless/until we can determine that none of them can meet the = requirements, even with appropriate profiles, extensions or = modifications. I think that is pretty unlikely based on the breadth and = variety of existing security protocols. I think we should require a = recharter to undertake development of a new security protocol. So, I would propose something like this: 2) Selection of an existing authentication and authorization protocol = that can serve as the basis of an authentication and authorization = system for constrained environments. =20 3) Definition of whatever profiles, extensions or modifications are = required to make the selected authentication and authorization protocol = suitable for constrained environments. > We can try to weasel around this, but if this group is successful, the = result will be the definition of certain new protocol components. > Reusing existing mechanisms, (abstract) protocols, or even encodings = as much as possible is desirable, but there also is an objective to be = met here. > This is not possible by stitching together a Frankenprotocol (which, = by composing old elements in a new way, still would be a new protocol). Depending on what you mean here, I might or might not agree=85 For instance, if we decide that an EAP-based approach could work in this = environment (as it does for every wi-fi device that needs to join an = 802.11x-secured network), I think we might want to define an EAP method = that leverages the existing crypto algorithms and security protocols = available on the constrained device, based on the assumption that the = device will also implement a constrained version of DTLS (as defined by = the DICE WG). Where would that fall in your view of the world? I don't = think it would be a Frankenprotocol at all, since EAP is designed to be = extended that way. There also wouldn't be much new protocol work, as an = EAP-DTLS method could be pretty similar to the existing EAP-TLS method. = Assuming something like that could meet our as-yet-undetermined = requirements for this environment, would you consider that to be a = successful outcome? Margaret From nobody Mon Mar 17 10:10:23 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336961A01C0 for ; Mon, 17 Mar 2014 10:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dndePHgfDplf for ; Mon, 17 Mar 2014 10:10:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0B47D1A0432 for ; Mon, 17 Mar 2014 10:10:16 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-df-53272c7058f3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5E.FB.23809.07C27235; Mon, 17 Mar 2014 18:10:08 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.80]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 17 Mar 2014 18:10:07 +0100 From: =?Windows-1252?Q?G=F6ran_Selander?= To: Margaret Wasserman , Carsten Bormann Thread-Topic: [Ace] ACE Charter Proposal v0.6 Thread-Index: AQHPPrnP/GEEGimfR0eN1erwqzgrSJrk+PYAgAAOsgCAADGggIAAUMGA Date: Mon, 17 Mar 2014 17:10:07 +0000 Message-ID: References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> In-Reply-To: <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6BADBC39BAD8B849A28D0E56152D53EA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+JvjW6BjnqwwcszChbfv/UwW/x+soLV 4siUu6wWS3feY7V48GIekwOrx85Zd9k9Fm/az+bRcuQtq8eSJT+ZPKYtygxgjeKySUnNySxL LdK3S+DK6N51i7XgvFZFz+4LbA2M35S6GDk5JARMJPa8b2WCsMUkLtxbz9bFyMUhJHCIUaJh 9VJ2CGcxo0Trq4WMIFVsAu4Sj3s2soDYIgJ+Emf+t7CCFDELtDBKXJzVBVYkLKAjcfTdBKgi XYnFqz+xQthuEruWTwdbxyKgKjFt1yGwGl4Bc4l7K/YxQWy7wiixtfMxWBGngK3Eyq9z2EFs RqD7vp9aAxZnFhCXuPVkPtTdAhJL9pxnhrBFJV4+/ge2TFRAT+Leo7ksEHElibWHt7NA9BpI vD83nxnCtpZoOP2OEcLWlli28DUzxEGCEidnPmGZwCgxC8m6WUjaZyFpn4WkfRaS9gWMrKsY 2XMTM3PSy402MQJj9eCW36o7GO+cEznEKM3BoiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRtUbi6wmny9QZvOV15uQ1jL5xyrf5fIuxzJOi5efnXTl+6RJAkWJnM6sHicPvFgT Ja1zzfb6xgTL26+E+6dvTRPTFM5ece7ct/5l10RkN/0t1rAwXn1i0v0V79782Ly+UHbL5OTF /jMj7+7IELJuYQ/rjOSbu69HT3+a3yJlX64thv/udRvGZyqxFGckGmoxFxUnAgDmNE/xowIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/JI2eXUZRO8NBRRCRXaMGvrPRPxU Cc: Bert Greevenbosch , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:10:21 -0000 Hi Margret, On 17/03/14 14:21, "Margaret Wasserman" wrote: > >Hi Carsten, > >On Mar 17, 2014, at 6:23 AM, Carsten Bormann wrote: > >> On 17 Mar 2014, at 10:30, Bert Greevenbosch >> wrote: >>>=20 >>> I think there is more to it than "selection", especially since we may >>>need to make some adjustments or define something new for the >>>constrained case. >>=20 >> Indeed. > >I agree with this, too. I think the charter should be open to profiling, >adjusting or extending existing security mechanisms to meet the needs of >this environment. > >>>> 2) Identify suitable authentication and authorization mechanisms, in >>>>particular addressing dynamic and fine grained access control suitable >>>>for CoAP resource access requests in constrained environments. >>>=20 >>> What do you think? > >I think this goes too far into the requirements space=8A I think we are >planning to define the requirements and architecture as part of the >charter, and I think that one area that needs a lot of discussion is what >our requirements are for access control, and what roles the RS and AS >will play in that. For instance, we might decide that we want an >attribute or role-based system where the authentication process returns >various attributes and/or roles associated with the authenticated user, >and that information is used by the RS to determine what access should be >allowed. In that case, the granularity of the access control could be >application-specific and would be a matter of AS configuration and local >implementation on the RS. I can see where you are coming from. The =B3in particular addressing dynami= c and fine grained access control . . .=B2 is a conclusion from the use case and requirements draft. A better formulation would maybe have been =B3in particular *allowing* dynamic and fine grained access control . . .=B2 The intent was not that all applications must have =B3fine granular=B2 access policies, but that some applications require this so the solution must support it. We may completely disregard the previous work and redo the exercise, but I believe that the support for dynamical changes of a client's rights and application-specific granularity will remain a conclusion. Forgetting for a moment that this is a preliminary conclusion, do you still see a contradiction with this text and a solution based on an attribute/role-based system where say the AS associated a client with attributes/roles for the RS to match with locally specified rights? > >I want our charter to lean _strongly_ in the direction of preferring a >solution that is based on existing security protocol standards, >unless/until we can determine that none of them can meet the >requirements, even with appropriate profiles, extensions or >modifications. I think that is pretty unlikely based on the breadth and >variety of existing security protocols. I think we should require a >recharter to undertake development of a new security protocol. > >So, I would propose something like this: > >2) Selection of an existing authentication and authorization protocol >that can serve as the basis of an authentication and authorization system >for constrained environments. > >3) Definition of whatever profiles, extensions or modifications are >required to make the selected authentication and authorization protocol >suitable for constrained environments. While I certainly support the use an existing security protocol standard, if feasible, I think that the process indicated here has a weakness: In order to in step 2) assess that the selected protocol can serve as a basis for constrained environments, a large part of the profiling and modifications of step 3) must have already been performed. G=F6ran > >> We can try to weasel around this, but if this group is successful, the >>result will be the definition of certain new protocol components. >> Reusing existing mechanisms, (abstract) protocols, or even encodings as >>much as possible is desirable, but there also is an objective to be met >>here. >> This is not possible by stitching together a Frankenprotocol (which, by >>composing old elements in a new way, still would be a new protocol). > >Depending on what you mean here, I might or might not agree=8A > >For instance, if we decide that an EAP-based approach could work in this >environment (as it does for every wi-fi device that needs to join an >802.11x-secured network), I think we might want to define an EAP method >that leverages the existing crypto algorithms and security protocols >available on the constrained device, based on the assumption that the >device will also implement a constrained version of DTLS (as defined by >the DICE WG). Where would that fall in your view of the world? I don't >think it would be a Frankenprotocol at all, since EAP is designed to be >extended that way. There also wouldn't be much new protocol work, as an >EAP-DTLS method could be pretty similar to the existing EAP-TLS method. >Assuming something like that could meet our as-yet-undetermined >requirements for this environment, would you consider that to be a >successful outcome? > >Margaret > > > > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Mon Mar 17 12:59:24 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CCB1A0496 for ; Mon, 17 Mar 2014 12:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy9Gcf749hzF for ; Mon, 17 Mar 2014 12:59:20 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan4.extendcp.co.uk [79.170.43.26]) by ietfa.amsl.com (Postfix) with ESMTP id B2CD81A0200 for ; Mon, 17 Mar 2014 12:59:19 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WPdga-0007KT-IX; Mon, 17 Mar 2014 19:59:00 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WPdga-0003aF-27; Mon, 17 Mar 2014 19:59:00 +0000 Received: from host86-149-120-43.range86-149.btcentralplus.com ([86.149.120.43] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WPdgV-00049V-R0; Mon, 17 Mar 2014 19:58:56 +0000 Message-ID: <53275430.6070903@gridmerge.com> Date: Mon, 17 Mar 2014 19:59:44 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Margaret Wasserman , Carsten Bormann References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> In-Reply-To: <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020902030602060304050700" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/GCrXxZFsCf4iNdqWXhy7vHTgx3A Cc: Bert Greevenbosch , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 19:59:22 -0000 This is a cryptographically signed message in MIME format. --------------ms020902030602060304050700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Regarding the point on EAP-TLS: It is unlikely we would need an EAP-DTLS = as DTLS is an adaptation of TLS to work over datagrams. Similarly,=20 EAP-TLS (and EAP-TTLS) adapt TLS for use with EAP, which itself is a=20 datagram protocol and provides lock-step Request-Response and=20 fragmentation and reassembly support, like DTLS. What may be important for constrained devices (and may be more of a=20 topic for LWIG) would be the ability to have a single TLS base for=20 handshake and record layers with a small set of common cipher suites=20 which could be reused across TLS, DTLS and EAP-TLS implementations. Robert On 17/03/2014 1:21 PM, Margaret Wasserman wrote: > Hi Carsten, > > On Mar 17, 2014, at 6:23 AM, Carsten Bormann wrote: > >> On 17 Mar 2014, at 10:30, Bert Greevenbosch wrote: >>> I think there is more to it than "selection", especially since we may= need to make some adjustments or define something new for the constraine= d case. >> Indeed. > I agree with this, too. I think the charter should be open to profilin= g, adjusting or extending existing security mechanisms to meet the needs = of this environment. > >>>> 2) Identify suitable authentication and authorization mechanisms, in= particular addressing dynamic and fine grained access control suitable f= or CoAP resource access requests in constrained environments. >>> What do you think? > I think this goes too far into the requirements space=85 I think we ar= e planning to define the requirements and architecture as part of the cha= rter, and I think that one area that needs a lot of discussion is what ou= r requirements are for access control, and what roles the RS and AS will = play in that. For instance, we might decide that we want an attribute or= role-based system where the authentication process returns various attri= butes and/or roles associated with the authenticated user, and that infor= mation is used by the RS to determine what access should be allowed. In = that case, the granularity of the access control could be application-spe= cific and would be a matter of AS configuration and local implementation = on the RS. > > I want our charter to lean _strongly_ in the direction of preferring a = solution that is based on existing security protocol standards, unless/un= til we can determine that none of them can meet the requirements, even wi= th appropriate profiles, extensions or modifications. I think that is pr= etty unlikely based on the breadth and variety of existing security proto= cols. I think we should require a recharter to undertake development of = a new security protocol. > > So, I would propose something like this: > > 2) Selection of an existing authentication and authorization protocol t= hat can serve as the basis of an authentication and authorization system = for constrained environments. > > 3) Definition of whatever profiles, extensions or modifications are req= uired to make the selected authentication and authorization protocol suit= able for constrained environments. > >> We can try to weasel around this, but if this group is successful, the= result will be the definition of certain new protocol components. >> Reusing existing mechanisms, (abstract) protocols, or even encodings a= s much as possible is desirable, but there also is an objective to be met= here. >> This is not possible by stitching together a Frankenprotocol (which, b= y composing old elements in a new way, still would be a new protocol). > Depending on what you mean here, I might or might not agree=85 > > For instance, if we decide that an EAP-based approach could work in thi= s environment (as it does for every wi-fi device that needs to join an 80= 2.11x-secured network), I think we might want to define an EAP method tha= t leverages the existing crypto algorithms and security protocols availab= le on the constrained device, based on the assumption that the device wil= l also implement a constrained version of DTLS (as defined by the DICE WG= ). Where would that fall in your view of the world? I don't think it wo= uld be a Frankenprotocol at all, since EAP is designed to be extended tha= t way. There also wouldn't be much new protocol work, as an EAP-DTLS met= hod could be pretty similar to the existing EAP-TLS method. Assuming som= ething like that could meet our as-yet-undetermined requirements for this= environment, would you consider that to be a successful outcome? > > Margaret > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --------------ms020902030602060304050700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMTcxOTU5NDRaMCMGCSqGSIb3DQEJBDEWBBQpjWGuJJoM07eqlqR1CxxNayDOMjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAK2+BVUPuqZoFo0KlMTfKkI2SUm/Y/oPw/K7iQzUoGR5322S IgVzXjPWs561HslTwywmNXC3AwMvQVs6cacRmfdE+2qKj3fTZ8c6FAd4uOUy0Q1DxspGZ69D wg42kfHvEu6tMY+zIQr0eyhiQUKq9X6Bzg3bvUjQIjS3393p6Bh8RN0XdylWDnQ+rP42KJ/j zb/A5f0V8q39XHkFN1dxdsMGAdy14zDszZhznC+yAV2y+Vb6MAQEVqMjyrqlek3N7SKfla3Y sJkHWbm9D+ns1DmXhR0upS0z9x/84BKsnqzZnNvxl6LEcmZI3Rqt/wWd88a+H81mEsQpWB3H YeQmeSoAAAAAAAA= --------------ms020902030602060304050700-- From nobody Tue Mar 18 06:24:45 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428801A03F5 for ; Tue, 18 Mar 2014 06:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh8KRm5KFPaK for ; Tue, 18 Mar 2014 06:24:41 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 37D321A040C for ; Tue, 18 Mar 2014 06:24:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id D48C83FAB2 for ; Tue, 18 Mar 2014 14:24:31 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1uQHEJTjW2+A for ; Tue, 18 Mar 2014 14:24:31 +0100 (CET) Received: from inf-205-206.inf.um.es (inf-205-206.inf.um.es [155.54.205.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id C2EB13F8DA for ; Tue, 18 Mar 2014 14:24:31 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rafa Marin Lopez In-Reply-To: <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> Date: Tue, 18 Mar 2014 14:24:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> To: "ace@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fKYd2W2TaRIpgRkBtCYJmSn7VZA Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 13:24:44 -0000 Hi Margaret, all > Depending on what you mean here, I might or might not agree=85 >=20 > For instance, if we decide that an EAP-based approach could work in = this environment As part of a research activity here at the University of Murcia, we = created an initial design of an authentication service based on EAP for = CoAP sometime ago. In other words, CoAP messages are used to transport = EAP between the CoAP client (EAP authenticator) and the CoAP server (EAP = peer/ the constrained node). In particular, the EAP messages are = directly transported in the CoAP message payload for this authentication = service. In this case, the EAP authenticator (CoAP client) can contact = an external AAA server (which is one of the posible choices in ACE, as = far as I have read).=20 Once EAP has finished, we bootstrap a security association between CoAP = server and CoAP client based on the MSK. In our case, this security = association might be based on DTLS or by using a new AUTH option we have = defined to be included in any CoAP message (no need of DTLS in the = second case). We have restarted the work some months ago and we have now a very = limited proof-of-concept with libcoap. It is still in PC platform but we = have started to build the implementation in COOJA simulator (without = DTLS so far). Nevertheless, our intention is also to test it with DTLS. I guess this could be also categorized as an EAP-based approach, though = we do not know if it will be interesting for ACE members. If people = think it is, we can prepare a short I-D explaining what we have until = now. > (as it does for every wi-fi device that needs to join an = 802.11x-secured network), I think we might want to define an EAP method = that leverages the existing crypto algorithms and security protocols = available on the constrained device, based on the assumption that the = device will also implement a constrained version of DTLS (as defined by = the DICE WG). In our case we have tested EAP-PSK since it uses AES-based cryptography. = In fact, we have previous experience on that in real constrained devices = (PANATIKI: A Network Access Control Implementation Based on PANA for IoT = Devices http://www.mdpi.com/1424-8220/13/11/14888). But I agree that if = we assume DTLS we may assume that an EAP-TLS method would be reasonable. = Nevertheless, I agree with Robert that we may not need to design a new = EAP method for that. Just my 0.02 cents. > Where would that fall in your view of the world? I don't think it = would be a Frankenprotocol at all, since EAP is designed to be extended = that way. There also wouldn't be much new protocol work, as an EAP-DTLS = method could be pretty similar to the existing EAP-TLS method. Assuming = something like that could meet our as-yet-undetermined requirements for = this environment, would you consider that to be a successful outcome? >=20 > Margaret >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Tue Mar 18 06:39:58 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10B51A040C for ; Tue, 18 Mar 2014 06:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k0eMNN7I768 for ; Tue, 18 Mar 2014 06:39:49 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id A9C8F1A03FF for ; Tue, 18 Mar 2014 06:39:48 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so6976030qaq.10 for ; Tue, 18 Mar 2014 06:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:cc:reply-to:mime-version :content-type; bh=laahgd/slPSXKv7PrKWnr4LyYqEnABSfrV9l2mbGmb0=; b=zds6G9aX2xLJ5FdeUxzN6UxHQXR0Dx0yDTdQefDUgocvRvbV9wgnsOEgmp2VKukYzR 7Foata5KDhbbOjIWoB8q22qSe7TF5qaCK9qVlN2whZixRL3Mt1l5PxXG26YBNtz48whO QM60QcIZDjtHPugt5ZGkCxVEuQuebYHgMTiFG76fnS416r1lO8s1tMznL7+Jmj1u0tZ4 F7Bu7TsZ6+CZ8BGXyifFUhARMCJzVIDCbRj9gKhxHjNVVowO2x58VgYXztyfQ5x6sRin zBhEKnvpf6XOusOeuME1D0tW7etinXBYc7nZ46br0Ijx/aPrPGzzVowp0FAFKZKQe4VA LfWw== X-Received: by 10.224.172.133 with SMTP id l5mr36173067qaz.25.1395149980095; Tue, 18 Mar 2014 06:39:40 -0700 (PDT) Received: from [192.168.1.9] (pool-108-7-235-60.bstnma.fios.verizon.net. [108.7.235.60]) by mx.google.com with ESMTPSA id v12sm53402391qav.23.2014.03.18.06.39.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 06:39:39 -0700 (PDT) Date: Tue, 18 Mar 2014 09:37:57 -0400 Message-ID: Importance: normal From: Margaret Wasserman To: Zach Shelby , "robert.cragie@gridmerge.com" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_809215972640270" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0jdUijrjtd-ZbF9c1mUNYMCgmeM Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Margaret Wasserman List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 13:39:55 -0000 ----_com.android.email_809215972640270 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UHVibGlzaGluZyB0aGUgcmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgaW4gYW4gUkZDIGlzIE5P VCB0aGUgc2FtZSB0aGluZyBhcyBnYXRpbmcgb3VyIG90aGVyIHdvcmsgb24gcHVibGlzaGluZyB0 aG9zZSB0aGluZ3MgZmlyc3QgLS0gSSB3b3VsZCBvYmplY3QgdG8gYSBwaGFzZWQgY2hhcnRlciB0 aGF0IHJlcXVpcmVzIHVzIHRvIHB1Ymxpc2ggb3VyIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRz IGFzIFJGQ3MgYmVmb3JlIHdlIGRvIGFueSBwcm90b2NvbCB3b3JrLCBhbmQgSSBsaWtlIHRoZSBp ZGVhIG9mIHVzaW5nIGEgd2lraSB0byBjb2xsZWN0IGFuZCByZWZpbmUgdGhlbS4KCldlIHNob3Vs ZCByZW1lbWJlciwgdGhvdWdoLCB0aGF0IHdlIHdpbGwgbmVlZCB0byBpbnZvbHZlIGEgd2lkZSBy YW5nZSBvZiBJRVRGIHBhcnRpY2lwYW50cywgaW5jbHVkaW5nIG11bHRpcGxlIElFVEYgc2VjdXJp dHkgZXhwZXJ0cywgdG8gYmUgc3VjY2Vzc2Z1bC4gwqBOb3QgYWxsIG9mIHRob3NlIHBlb3BsZSB3 aWxsIGhhdmUgd29ya2VkIGluIHRoZSBJb1QvZW1iZWRkZWQgc3BhY2UsIHNvIGRvY3VtZW50aW5n IHRoZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBlYXJseSBpbiB0aGUgcHJvY2VzcyAob24g YSB3aWtpIHBhZ2UgaXMgZmluZSkgd2lsbCBiZSBlc3NlbnRpYWwgdG8gYWxsb3dpbmcgdGhhdCB3 aWRlciBzZXQgb2YgSUVURiBwYXJ0aWNpcGFudHMgdG8gZW5nYWdlIGNvbnN0cnVjdGl2ZWx5LgoK SSdkIHBlcnNvbmFsbHkgbGlrZSB0byBzZWUgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRz IGNhcHR1cmVkIGluIGFuIGFjaGl2YWwgZm9ybSB0aGF0IGNhbiBiZSByZWZlcmVuY2VkIGxhdGVy LCBiZWNhdXNlIEkgdGhpbmsgdGhlIHVzZSBjYXNlcywgaW4gcGFydGljdWxhciwgbWlnaHQgYmUg dXNlZnVsIGZvciBsYXRlciB3b3JrLiDCoEknZCBiZSBwZXJmZWN0bHkgaGFwcHkgd2l0aCBwdWJs aXNoaW5nIHRoZW0gYXMgUkZDcyBsYXRlciBpbiB0aGUgcHJvY2VzcywgdGhvdWdoLgoKSWYgcGVv cGxlIHdvdWxkIHJhdGhlciB0cnkgdG8gY2FwdHVyZSB0aGUgbWFqb3IgdXNlIGNhc2VzIGFuZCBt b3RpdmF0aW9ucyBpbiB0aGUgcHJvdG9jb2wgc3BlYyBpbnN0ZWFkLCBJIGd1ZXNzIHRoYXQgd291 bGQgd29yayBmb3IgbWUsIGJ1dCBJIHdvdWxkIHNvbWV3aGF0IHByZWZlciBhbiB1bmNsdXR0ZXJl ZCBwcm90b2NvbCBzcGVjIHRoYXQgcmVmZXJzIHRvIHN1cHBvcnRpbmcgaW5mb3JtYXRpb25hbCBk b2N1bWVudHMuIMKgCgpNYXJnYXJldAoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LQpGcm9tIFphY2ggU2hlbGJ5IDxaYWNoLlNoZWxieUBhcm0uY29tPiAKRGF0ZTogMDMvMTQvMjAx NCAgMTE6MzEgQU0gIChHTVQtMDU6MDApIApUbyByb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20g CkNjIGFjZUBpZXRmLm9yZyAKU3ViamVjdCBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9zYWwg djAuNSAKIApBcyBJIG1lbnRpb25lZCBpbiB0aGUgQm9GLCBteSBhZHZpY2Ugd291bGQgYmUgdG8g anVzdCB1c2UgYSB3aWtpIHRvIGNvbGxlY3QgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMuCgpO b3csIGlmIHdlIHdhbnQgdG8gd2FzdGUgdGhlIGZpcnN0IGhhbGYgeWVhciBicmluaW5nIHN1Y2gg ZHJhZnRzIHRocm91Z2ggdGhlIFJGQyBwcm9jZXNzIHRoZW4gZ28gYWhlYWQuIEZyb20gbXkgZXhw ZXJpZW5jZSB0aGVzZSBraW5kcyBvZiB3b3JrIGl0ZW1zIGFyZSBqdXN0IGEgV0cgYmxhY2sgaG9s ZS4gWW91IGNhbiBhbHdheXMgZG9jdW1lbnQgdGhlIGFzc3VtZWQgdXNlIGNhc2VzIHdpdGhpbiB0 aGUgYWN0dWFsIHRlY2huaWNhbCBzcGVjaWZpY2F0aW9uIHRvIG1ha2UgaXQgY2xlYXIgd2hhdCBw cm9ibGVtIGl0IGlzIHRyeWluZyB0byBzb2x2ZS4KClphY2gKCk9uIE1hciAxNCwgMjAxNCwgYXQg ODowMiBBTSwgUm9iZXJ0IENyYWdpZSA8cm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tPiB3cm90 ZToKCj4gKzEgdG8gYm90aCBNYXJnYXJldCdzIHN0YXRlbWVudHMuCj4KPiBSb2JlcnQKPgo+IE9u IDEzLzAzLzIwMTQgMTA6NTUgQU0sIE1hcmdhcmV0IFdhc3Nlcm1hbiB3cm90ZToKPj4gUGVyc29u YWxseSwgSSB3b3VsZCBhbHNvIHJhdGhlciBzZWUgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1l bnRzIHB1Ymxpc2hlZCBhcyBpbmZvcm1hdGlvbmFsUkZDcy7CoCBJIHRoaW5rIHRoYXQgYSB3aWtp IG1pZ2h0IGJlIGEgZ29vZCB3YXkgdG8gY29sbGVjdCB0aGVtIGF0IGZpcnN0LCBidXQgSSB3b3Vs ZCBwcmVmZXIgdG8gYmUgc3VyZSB0aGF0IHdlIGhhdmUgY29uc2Vuc3VzIG9uIHRoZSBwcm9ibGVt KHMpIHdlIGFyZSB0cnlpbmcgdG8gc29sdmUuwqAgSSBhbHNvIHRoaW5rIGl0IHdpbGwgYmUgdXNl ZnVsIHRvIGhhdmUgdGhlc2UgdGhpbmdzIGluIGFyY2hpdmFsIGZvcm0gbGF0ZXIuCj4+Cj4+IEkg ZG8gbm90IHRoaW5rIHRoZSBvdGhlciB3b3JrIG9mIHRoZSBncm91cCBzaG91bGQgYmUgZ2F0ZWQg b24gdGhlIHJlcXVpcmVtZW50cywgdGhvdWdoLCBhcyBJIHRoaW5rIHRoYXQgaXQgbWFrZXMgc2Vu c2UgdG8gZXhwbG9yZSBob3cgZXhpc3RpbmcgdGVjaG5vbG9naWVzIGNvdWxkIG9yIGNvdWxkbid0 IG1lZXQgdGhlIHJlcXVpcmVtZW50cyB0byBpbnN1cmUgdGhhdCBvdXIgcmVxdWlyZW1lbnRzIGFy ZSByZWFsaXR5LWJhc2VkLgo+Pgo+PiBNYXJnYXJldAo+Pgo+Pgo+Pgo+PiAtLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tCj4+IEZyb20gTGlrZXBlbmcgPGxpa2VwZW5nQGh1YXdlaS5j b20+Cj4+IERhdGU6IDAzLzEzLzIwMTQgNDoyOCBBTSAoR01ULTA1OjAwKQo+PiBUbyBIYW5uZXMg VHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4sR8O2cmFuIFNlbGFuZGVyIDxn b3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+LFphY2ggU2hlbGJ5IDxaYWNoLlNoZWxieUBhcm0u Y29tPgo+PiBDYyBhY2VAaWV0Zi5vcmcKPj4gU3ViamVjdCBSZTogW0FjZV0gQUNFIENoYXJ0ZXIg UHJvcG9zYWwgdjAuNQo+Pgo+Pgo+PiBNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgdGhlIHVz ZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZG9jdW1lbnQgY2FuIGhlbHAgcGVvcGxlIHRvIHVuZGVy c3RhbmQgd2hhdCBraW5kIG9mIGlzc3VlcyB3ZSBhcmUgdHJ5aW5nIHRvIHJlc29sdmUuCj4+Cj4+ IEkgY2FuIHNlZSBzb21lIHZhbHVlcyB0byBwdWJsaXNoIGl0IGludG8gUkZDcy4gSWYgaXQgaXMg YSB3aWtpIHBhZ2UsIHdlIHdpbGwgaGF2ZSBsZXNzIHBlb3BsZSB0byByZXZpZXcgaXQgb3IgaW1w cm92ZSBpdC4KPj4KPj4gRXNwZWNpYWxseSB0aGUgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50IGRv Y3VtZW50IGlzIGFscmVhZHkgaW4gYSBnb29kIHNoYXBlIGFuZCBpdCBpcyByZWZlcmVuY2VkIHNl dmVyYWwgdGltZXMgaW4gdGhlIG1haWxpbmcgbGlzdCB0byBpbnRyb2R1Y2Ugb3VyIHdvcmsgdG8g b3V0c2lkZS4KPj4KPj4gVGhhbmtzLAo+Pgo+PiBLaW5kIFJlZ2FyZHMKPj4gS2VwZW5nCj4+Cj4+ ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQo+PiA+IOWPkeS7tuS6ujogQWNlIFttYWlsdG86YWNl LWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBIYW5uZXMgVHNjaG9mZW5pZwo+PiA+IOWPkemAgeaX tumXtDogMjAxNOW5tDPmnIgxM+aXpSA0OjMzCj4+ID4g5pS25Lu25Lq6OiBHw7ZyYW4gU2VsYW5k ZXI7IFphY2ggU2hlbGJ5Cj4+ID4g5oqE6YCBOiBhY2VAaWV0Zi5vcmcKPj4gPiDkuLvpopg6IFJl OiBbQWNlXSBBQ0UgQ2hhcnRlciBQcm9wb3NhbCB2MC41Cj4+ID4KPj4gPiBIaSBHb2VyYW4sCj4+ ID4KPj4gPiBJIHJlYWQgYSBsaXR0bGUgYml0IGJldHdlZW4gdGhlIGxpbmVzIG9mIHlvdXIgbWFp bCBhbmQgeW91ciBtYWluIGNvbmNlcm4gaXMgdGhhdAo+PiA+IHlvdSB3YW50IHRvIGhhdmUgYW4g UkZDIHB1Ymxpc2hlZCB3aXRoIHlvdXIgbmFtZSBvbiBpdC4KPj4gPiBBIHdpa2kgcGFnZSB0byBk b2N1bWVudCB0aGUgcmVxdWlyZW1lbnRzLCBhbmQgdXNlIGNhc2VzIGlzIG5vdCBnb29kIGVub3Vn aAo+PiA+IGZvciB5b3UuCj4+ID4KPj4gPiBGb3IgeW91IHB1dHRpbmcgdGhlIGRyYWZ0IHRleHQg b24gYSBXRyB3aWtpIGZlZWxzIGxpa2Ugd2FzdGVkIHRpbWUuCj4+ID4gSXQgaXMganVzdCBhIGRp ZmZlcmVudCBmb3JtIG9mIGRvY3VtZW50aW5nIHRoZSB3b3JrLgo+PiA+Cj4+ID4gTXkgZXhwZXJp ZW5jZSB3aXRoIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGhhcyBub3QgYmVlbiBncmVhdCBp biB0aGUgSUVURi4KPj4gPiBJbiBlc3NlbmNlIGV2ZXJ5b25lIHF1aWNrbHkgbW92ZXMgb24gb25j ZSB0aGUgZ3JvdXAgZGVjaWRlcyBhYm91dCBhCj4+ID4gcGFydGljdWxhciBzb2x1dGlvbiBkaXJl Y3Rpb24uIEl0IHRoZW4gYmVjb21lcyB2ZXJ5IGhhcmQgKGZvciB0aGUKPj4gPiBjaGFpcnMpIHRv IGZpbmlzaCB0aGUgcmVxdWlyZW1lbnRzIHdvcmsgc2luY2Ugbm9ib2R5IHdhbnRzIHRvIHJldmll dyBvciBsb29rCj4+ID4gYXQgdGhlbSBhbnltb3JlLgo+PiA+Cj4+ID4gVXNlIGNhc2VzIGFuZCBy ZXF1aXJlbWVudHMgYXJlIGdyZWF0IGR1cmluZyB0aGUgaW5pdGlhbCBwYXJ0IG9mIHRoZSB3b3Jr IHRvIGdldAo+PiA+IGFuIHVuZGVyc3RhbmRpbmcgb2YgdGhlIG1haW4gY2hhbGxlbmdlcy4KPj4g Pgo+PiA+IEhhdmluZyBzYWlkIHRoYXQgSSB3aWxsIGxlYXZlIGl0IHRvIHRoZSBncm91cCB0byBk ZWNpZGUgd2hhdCB0aGV5IHdhbnQgdG8gZG86Cj4+ID4gUkZDcyBvciBXaWtpIHBhZ2UKPj4gPgo+ PiA+IENpYW8KPj4gPiBIYW5uZXMKPj4gPgo+PiA+IFBTOiBSZWdhcmRpbmcgeW91ciBvdGhlciBj b21tZW50IGFib3V0IHBvaW50aW5nIHRvIHRoZSBjb25zdHJhaW50IG5hdHVyZSB0bwo+PiA+IGV2 ZXJ5IGl0ZW0uIFdlIGNhbiBkbyB0aGF0IGlmIHlvdSBmZWVsIGJldHRlciBidXQgdGhlIGVudGly ZSBjaGFydGVyIHBhZ2UKPj4gPiBhbHJlYWR5IHNheXMgMTAgdGltZXMgdGhhdCB3ZSBhcmUgZm9j dXNpbmcgb24gdGhlIGNvbnN0cmFpbnQgc3BhY2UuCj4+ID4gSSBhbSBzdXJlIHRoYXQgdGhlIHJl YWRlciB3aWxsIGhhdmUgdW5kZXJzdG9vZCB0aGF0IHdoZW4gdGhleSBnZXQgdG8gdGhlIHRhc2sK Pj4gPiBsaXN0Lgo+PiA+Cj4+ID4KPj4gPiBPbiAwMy8xMi8yMDE0IDEwOjMyIEFNLCBHw7ZyYW4g U2VsYW5kZXIgd3JvdGU6Cj4+ID4gPiBIYW5uZXMsIFphY2ggYW5kIGFsbCwKPj4gPiA+Cj4+ID4g PiBJIG11c3Qgc2F5IEkgZG9uwrl0IGZpbmQgdGhlIHRhc2sgbGlzdCBvZiB0aGUgY3VycmVudCBj aGFydGVyIHZlcnkgaGVscGZ1bDoKPj4gPiA+Cj4+ID4gPiDCs1RoZSB3b3JraW5nIGdyb3VwIGhh cyB0aGUgZm9sbG93aW5nIHRhc2tzIChpbiB0aGlzIG9yZGVyKToKPj4gPiA+Cj4+ID4gPiAxKSBU aGUgd29ya2luZyBncm91cCBXaWtpIHBhZ2VzIHdpbGwgYmUgdXNlZCB0byBkb2N1bWVudCB1c2Ug Y2FzZXMsCj4+ID4gPiByZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEu IFRoaXMgd29yayB3aWxsIGd1aWRlIHRoZQo+PiA+ID4gaWRlbnRpZmljYXRpb24gb2Ygc3VpdGFi bGUgcHJvdG9jb2wgbWVjaGFuaXNtcy4KPj4gPiA+Cj4+ID4gPiAyKSBTZWxlY3Rpb24gb2YgYW4g YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9yCj4+ID4gPiBjb25z dHJhaW5lZCBlbnZpcm9ubWVudHMuCj4+ID4gPgo+PiA+ID4gMykgRXZhbHVhdGlvbiBvZiB0aGUg Y2FuZGlkYXRlIHNvbHV0aW9uIGZvciB1c2Ugd2l0aCBIVFRQL1RMUyBhbmQKPj4gPiA+IHByb3h5 IGRlcGxveW1lbnRzLsKyCj4+ID4gPgo+PiA+ID4gVGhpcyBsaXN0IGRvZXMgbm90IGdpdmUgbXVj aCBtb3JlIGRldGFpbHMgYWJvdXQgdGhlIHdvcmsgdG8gYmUKPj4gPiA+IGNvbmR1Y3RlZCB0aGFu IGlzIGFscmVhZHkgZ2l2ZW4gYnkgdGhlIHRpdGxlIG9mIHRoZSBXRy4gVG8gYSBwZXJzb24KPj4g PiA+IG5vdCBoYXZpbmcgZm9sbG93ZWQgdGhlIGRpc2N1c3Npb24sIHRoZSBpbXByZXNzaW9uIGlz IHRoYXQgdGhlIHdvcmsKPj4gPiA+IHN0YXJ0cyBmcm9tIHNjcmF0Y2ggYW5kIHRoZXJlIGlzIG5v IGNsZWFyIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB0byBkby4KPj4gPiA+Cj4+ID4gPiBJZiB3ZSBj YW7CuXQgZm9ybXVsYXRlIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgZmlyc3Qgc3RlcCB0b3dh cmRzIGEKPj4gPiA+IHNvbHV0aW9uIGluIHNvbWUgZGVncmVlIG9mIGRldGFpbCBiZWZvcmUgc3Rh cnRpbmcgdGhlIFdHIHRoYXQgd2lsbAo+PiA+ID4gYW55d2F5IGJlIHRoZSBmaXJzdCB0YXNrIHRv IGRvLCBzbyBsZXTCuXMgdHJ5IHRvIGdldCBzb21ldGhpbmcgaW4gd3JpdGluZy4KPj4gPiA+Cj4+ ID4gPgo+PiA+ID4gIjEpIFRoZSB3b3JraW5nIGdyb3VwIFdpa2kgcGFnZXMgd2lsbCBiZSB1c2Vk IHRvIGRvY3VtZW50IHVzZSBjYXNlcywKPj4gPiA+IHJlcXVpcmVtZW50cywgYW5kIHByb3RvY29s IGRlc2lnbiBjcml0ZXJpYS4gVGhpcyB3b3JrIHdpbGwgZ3VpZGUgdGhlCj4+ID4gPiBpZGVudGlm aWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNoYW5pc21zLiIKPj4gPiA+Cj4+ID4gPiBU aGlzIGlzIGhpZGluZyB0aGUgZmFjdCB0aGF0IHRoZXJlIGhhcyBiZWVuIDYgbW9udGhzIG9mIHdv cmsgb24gdGhlCj4+ID4gPiB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0ICh0aGUgZmly c3QgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHdhcwo+PiA+ID4gc3VibWl0dGVkIHRvIENvUkUgaW4g SUVURjg4KSwgd2hpY2ggbm8gb25lIGhhcyBkaXNhZ3JlZWQgaXMgc2V0dGluZwo+PiA+ID4gdGhl IHN0YWdlIGZvciB0aGlzIHdvcmsuIExvb2sgYXQgcGFyYWxsZWwgdGhyZWFkcyBvbiB0aGlzIG1h aWxpbmcgbGlzdAo+PiA+ID4gd2hlcmUgcGVvcGxlIGFzayB3aGV0aGVyIHRoZWlyIHBhcnRpY3Vs YXIgc2VjdXJpdHktZm9yLUlvVCBkcmFmdCBmaXRzCj4+ID4gPiBpbnRvIEFDRS4gVGhlIGFuc3dl ciBIYW5uZXMgaXMgZ2l2aW5nIGlzIGNvcnJlY3RseTogdGhlIHNjb3BlIG9mIHRoaXMKPj4gPiA+ IHdvcmsgaXMgd2hhdCBpcyBvdXRsaW5lZCBieSB0aGUgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50 cyBkcmFmdC4gSQo+PiA+ID4gZG9uwrl0IG1pbmQgdXNpbmcgdGhlIFdpa2kgYXMgYSB3b3JraW5n IHRvb2wgYnV0IHRoaXMgZG9lcyBub3QgZ2l2ZQo+PiA+ID4gdHJhY2VhYmlsaXR5IGEgeWVhciBs YXRlci4gQW5kIEkgZG9uwrl0IHNlZSB0aGUgcG9pbnQgaWYgY29weWluZyB0aGUKPj4gPiA+IHVz ZSBjYXNlIGRvY3VtZW50IGludG8gYSBXaWtpIHBhZ2UgLSByZWFkIHRoZSBkcmFmdCBhbmQgcHJv dmlkZSB5b3VyCj4+ID4gY29tbWVudHMhCj4+ID4gPgo+PiA+ID4gV2hlbiBpdCBjb21lcyB0byBw cm90b2NvbCBkZXNpZ24gY3JpdGVyaWEsIEkgYWdyZWUgdGhhdCBtb3JlIHdvcmsgaXMKPj4gPiA+ IG5lZWRlZCwgZm9yIHdoaWNoIHRoZSBXaWtpIG1heSBiZSBzdWl0YWJsZS4gTmV2ZXJ0aGVsZXNz IEkgaW5zaXN0IG9uCj4+ID4gPiBkb2N1bWVudGluZyB0aGUgZGVzaWduIGNyaXRlcmlhIGFuZCBp dHMgcmF0aW9uYWxlIHNpbmNlIHRoYXQgcHJvdmlkZXMKPj4gPiA+IGEgbWVhbnMgZm9yIHRyYWNl YWJpbGl0eS4gTWFrZSBpdCBhIG1pbGVzdG9uZSB0byBoYXZlIGEgZHJhZnQgd2l0aAo+PiA+ID4g YXNzdW1wdGlvbnMgYW5kIGRlc2lnbiBjcml0ZXJpYcKgICh5b3UgbWF5IGluY2x1ZGUgwrNhcmNo aXRlY3R1cmXCsiBpbgo+PiA+ID4gdGhpcyBkb2N1bWVudCkuIFRoaXMgd29yayBpcyBhbnl3YXkg YSBwcmUtcmVxdWlzaXRlIGZvciBjb21pbmcgdG8gYQo+PiA+ID4gc29sdXRpb24sIGFuZCBvbmNl IHlvdSBoYXZlIHRoaXMgY29udGVudCwgdGhlIGNhbmRpZGF0ZSBzb2x1dGlvbnMgYXJlCj4+ID4g PiBtdWNoIGVhc2llciBldmFsdWF0ZWQuCj4+ID4gPgo+PiA+ID4gU28sIGNoYW5nZSAxKSB0byBz dGF0ZSBzb21ldGhpbmcgbGlrZQo+PiA+ID4KPj4gPiA+ICIxwrkgKQo+PiA+ID4gYSkgY29tcGxl dGUgdGhlIHdvcmsgb24gdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50cwo+PiA+ID4gYikgdXNlIFdp a2kgcGFnZXMgZm9yIGxpc3RpbmcgYXNzdW1wdGlvbnMgYW5kIHByb3RvY29sIGRlc2lnbgo+PiA+ ID4gY3JpdGVyaWEsIGRvY3VtZW50IHRoZSByZXN1bHQgaW4gYSBkcmFmdCIKPj4gPiA+Cj4+ID4g PiBQcm94eSBkZXBsb3ltZW50IGFzcGVjdHMgZml0cyB3ZWxsIGludG8gMWIpwqAgW21vcmUgaW4g c2VwYXJhdGUKPj4gPiA+IHVwY29taW5nIG1haWxdCj4+ID4gPgo+PiA+ID4KPj4gPiA+IDIpIFNl bGVjdGlvbiBvZiBhbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbCBm b3IKPj4gPiA+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4KPj4gPiA+Cj4+ID4gPiBIZXJlIEnC uW0gbWlzc2luZyBhbW9uZyBvdGhlciB0aGluZ3MgdGhlIHNwZWNpZmljIHByb2JsZW0gc3RhdGVt ZW50Lgo+PiA+ID4gVGhlIHByZWxpbWluYXJ5IGNvbmNsdXNpb25zIGZyb20gdGhlIHVzZSBjYXNl IGFuZCByZXF1aXJlbWVudHMgZHJhZnQKPj4gPiA+IGZvcm1lZCB0aGUgYmFzaXMgZm9yIHRoZSBw cm9ibGVtIHN0YXRlbWVudCBhcyBwcmVzZW50ZWQgaW4gdGhlIEJPRjogV2UKPj4gPiA+IGxhY2sg YSBtZWNoYW5pc20gZm9yIGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZCBhY2Nlc3MgY29udHJvbCBm b3IKPj4gPiA+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4KPj4gPiA+Cj4+ID4gPiBUaGUgcHJv Y2VzcyBoZXJlIHNob3VsZCBiZSB0bzoKPj4gPiA+ICIywrkpIGlkZW50aWZ5IHN1aXRhYmxlIHBy b3RvY29sIG1lY2hhbmlzbXMgYW5kIG1hdGNoIGNhbmRpZGF0ZQo+PiA+ID4gYXV0aGVudGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGFnYWluc3QgcmVxdWlyZW1lbnRzIGFuZAo+ PiA+ID4gZGVzaWduIGNyaXRlcmlhLCBpbiBwYXJ0aWN1bGFyIGFkZHJlc3NpbmcgZHluYW1pYyBh bmQgZmluZSBncmFpbmVkCj4+ID4gPiBhY2Nlc3MgY29udHJvbCBzdWl0YWJsZSBmb3IgQ29BUCBy ZXNvdXJjZSBhY2Nlc3MgcmVxdWVzdHMgaW4gY29uc3RyYWluZWQKPj4gPiBlbnZpcm9ubWVudHMu Igo+PiA+ID4KPj4gPiA+Cj4+ID4gPgo+PiA+ID4gMykgRXZhbHVhdGlvbiBvZiB0aGUgY2FuZGlk YXRlIHNvbHV0aW9uIGZvciB1c2Ugd2l0aCBIVFRQL1RMUyBhbmQKPj4gPiA+IHByb3h5IGRlcGxv eW1lbnRzLsKyCj4+ID4gPgo+PiA+ID4KPj4gPiA+IEFzIG1lbnRpb25lZCBhYm92ZSwgcHJveHkg ZGVwbG95bWVudHMgY291bGQgYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mCj4+ID4gMcK5YikuCj4+ ID4gPiBJbiAywrkpIGl0IGlzIGFscmVhZHkgc3RhdGVkIHRoYXQgaW4gcGFydGljdWxhciB3ZSBz aG91bGQgY29uc2lkZXIgQ29BUAo+PiA+ID4gb24gaW50ZXJmYWNlIChJSSkuIEFzIGZvciB1c2Ug b2Ygb3RoZXIgcHJvdG9jb2xzIGJlc2lkZXMgQ29BUCB0aGF0Cj4+ID4gPiBpc3N1ZSBpcyBvcnRo b2dvbmFsIHRvIHRoaXMgc28gSSBsZWF2ZSB0aGF0IG91dCBmcm9tIHRoaXMgZGlzY3Vzc2lvbi4K Pj4gPiA+Cj4+ID4gPgo+PiA+ID4KPj4gPiA+IEfDtnJhbgo+PiA+ID4KPj4gPiA+Cj4+ID4gPgo+ PiA+ID4KPj4gPiA+Cj4+ID4gPiBPbiAxMS8wMy8xNCAxNjo0OSwgIlphY2ggU2hlbGJ5IiA8WmFj aC5TaGVsYnlAYXJtLmNvbT4gd3JvdGU6Cj4+ID4gPgo+PiA+ID4+IEhhbm5lcywKPj4gPiA+Pgo+ PiA+ID4+IEkgYW0gaGFwcHkgd2l0aCB0aGlzIGNoYXJ0ZXIgd2l0aCBvbmUgZXhjZXB0aW9uLiBU aGUgcHJveHkgaXRlbSBoZXJlCj4+ID4gPj4gc2VlbXMgdG8gYmUgbW9yZSBvZiBhIGRpc3RyYWN0 aW9uIHRoYW4gYW55dGhpbmcgZWxzZSwgYW5kIHdpbGwKPj4gPiA+PiBwcm9iYWJseSByZXN1bHQg aW4gaW5jcmVhc2VkIGNvbXBsZXhpdHkuIFdhcyBwcm94eSBzdXBwb3J0IG1heWJlIGp1c3QKPj4g PiA+PiBhIG1pc3VuZGVyc3RhbmRpbmc/IERvIHdlIHJlYWxseSBzZWUgdGhlIG5lZWQgZm9yIGEg cHJveHkgaW4gdGhlCj4+ID4gPj4gbWlkZGxlIG9mIEkgb3IgSUlJPwo+PiA+ID4+Cj4+ID4gPj4g SSB0aGluayB3aGF0IHdlIHJlYWxseSB3YW50IGhlcmUgaXMgdG8gbWFrZSBzdXJlIHRoYXQgZS5n LiBldmVuCj4+ID4gPj4gdGhyb3VnaCBJIGlzIGJhc2VkIG9uIEhUVFAvVExTLCBJSSBhbmQgSUlJ IGZvciBleGFtcGxlIGNhbiBydW4KPj4gPiA+PiBDb0FQL0RUTFMuIEluIG90aGVyIHdvcmRzLCBz b21lIGludGVyZmFjZXMgY2FuIGJlIGNvbnN0cmFpbmVkIHdoaWxlCj4+ID4gPj4gb3RoZXJzIGFy ZSBub3QuIEkgdGhpbmsgdGhlIGNoYXJ0ZXIgYWxyZWFkeSBjb3ZlcnMgdGhpcyBmaW5lLgo+PiA+ ID4+Cj4+ID4gPj4gU28gbXkgcHJvcG9zYWwgd291bGQgYmUgdG8gcmVtb3ZlIHRoZSBtZW50aW9u IG9mIHByb3RvY29sIHRyYW5zbGF0aW9uCj4+ID4gPj4gcHJveGllcy4gSWYgd2UgcmVhbGx5IHNl ZSB0aGUgbmVlZCBmb3IgdGhpcyBzb21lIGRheSBpbiB0aGUgZnV0dXJlLAo+PiA+ID4+IGl0IGNv dWxkIGJlIHRhY2tsZWQgdGhlbi4KPj4gPiA+Pgo+PiA+ID4+IFphY2gKPj4gPiA+Pgo+PiA+ID4+ IE9uIE1hciAxMSwgMjAxNCwgYXQgMTI6NTAgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnCj4+ID4gPj4g PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOgo+PiA+ID4+Cj4+ID4gPj4+IEhpIGFs bCwKPj4gPiA+Pj4KPj4gPiA+Pj4gSSBoYXZlIHRha2VuIHRoZSBmZWVkYmFjayBmcm9tIHRoZSBt ZWV0aW5nIGFuZCB0aGUgcmVjZW50Cj4+ID4gPj4+IGRpc2N1c3Npb25zIG9uIHRoZSBtYWlsaW5n IGxpc3QgYW5kIHByb2R1Y2VkIGEgbmV3IHN0cmF3bWFuIHByb3Bvc2FsLgo+PiA+ID4+Pgo+PiA+ ID4+PiBUaGUgY2hhbmdlcyBpbmNsdWRlOgo+PiA+ID4+PiAqIEFkZGVkIHRoZSBmb2N1cyBvbiBE VExTL0NvQVAgd2l0aCBhbiBpbmRpY2F0aW9uIHRoYXQgd2Ugd2lsbCBjaGVjawo+PiA+ID4+PiBh IGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3Igc3VpdGFiaWxpdHkgd2l0aCBIVFRQL1RMUy4KPj4gPiA+ Pj4gKiBBZGRlZCB0ZXh0IHRvIGluZGljYXRlIHRoYXQgd2Ugd2lsbCBhbHNvIHZlcmlmeSB0aGUg c3VpdGFiaWxpdHkgb2YKPj4gPiA+Pj4gdGhlIHNvbHV0aW9uIGZvciB1c2Ugd2l0aCBwcm90b2Nv bCB0cmFuc2xhdGlvbiBwcm94aWVzLgo+PiA+ID4+PiAqIFNpbXBsaWZpZWQgdGhlIHRhc2sgbGlz dCBieSByZW1vdmluZyBzb2x1dGlvbiBzcGVjaWZpYyBpdGVtcy4KPj4gPiA+Pj4gKiBNZXJnZWQg c2V2ZXJhbCBpdGVtcyBvbiB0aGUgdGFzayBsaXN0ICh1c2UgY2FzZXMsIHJlcXVpcmVtZW50cywK Pj4gPiA+Pj4gYW5kIHByb3RvY29sIGRlc2lnbiBndWlkZWxpbmVzKS4gRm9sbG93ZWQgdGhlIHN1 Z2dlc3Rpb24gdG8gdXNlIG9mIGEKPj4gPiA+Pj4gV2lraSBmb3IgY2FwdHVyaW5nIHRob3NlLgo+ PiA+ID4+Pgo+PiA+ID4+PiBXaGF0IGRvIHlvdSB0aGluaz8KPj4gPiA+Pj4KPj4gPiA+Pj4gLS0t LS0KPj4gPiA+Pj4KPj4gPiA+Pj4gRHJhZnQgQ2hhcnRlciBWMC41IC0gQXV0aGVudGljYXRpb24g YW5kIEF1dGhvcml6YXRpb24gZm9yCj4+ID4gPj4+IENvbnN0cmFpbmVkIEVudmlyb25tZW50IChB Q0UpCj4+ID4gPj4+Cj4+ID4gPj4+IFRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJv dG9jb2xzIGZvciB1c2UgaW4gZW52aXJvbm1lbnRzCj4+ID4gPj4+IHdoZXJlIG5ldHdvcmsgbm9k ZXMgYXJlIGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnksIGFuZCBwb3dlci4gSXQgd2FzCj4+ID4gPj4+ IG9ic2VydmVkIHRoYXQgSW50ZXJuZXQgcHJvdG9jb2xzIGNhbiBiZSBhcHBsaWVkIHRvIHRoZXNl IGNvbnN0cmFpbmVkCj4+ID4gPj4+IGVudmlyb25tZW50cywgb2Z0ZW4gb25seSByZXF1aXJpbmcg bWlub3IgdHdlYWtpbmcgYW5kIHByb2ZpbGluZy4gSW4KPj4gPiA+Pj4gb3RoZXIgY2FzZXMsIG5l dyBwcm90b2NvbHMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gYWRkcmVzcyB0aGUgc3BlY2lmaWMKPj4g PiA+Pj4gcmVxdWlyZW1lbnRzIG9mIGNvbnN0cmFpbmVkIGRldmljZXMgYW5kIG5ldHdvcmtzLiBB biBleGFtcGxlIG9mIHN1Y2gKPj4gPiA+Pj4gYSBwcm90b2NvbCBpcyB0aGUgQ29uc3RyYWluZWQg QXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLgo+PiA+ID4+PiBjb21wb25lbnRzCj4+ID4gPj4+ IEFzIGluIG90aGVyIGVudmlyb25tZW50cywgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRp b24gcXVlc3Rpb24KPj4gPiA+Pj4gYWxzbyBhcmlzZSBpbiBlbnZpcm9ubWVudHMgd2l0aCBjb25z dHJhaW5lZCBub2RlcyBhbmQgbmV0d29ya3MuIEZvcgo+PiA+ID4+PiBleGFtcGxlLCBhIGRvb3Ig bG9jayBoYXMgdG8gYXV0aG9yaXplIHRoZSBwZXJzb24gc2Vla2luZyBhY2Nlc3MKPj4gPiA+Pj4g dXNpbmcgYSAiZGlnaXRhbCBrZXkiLiBXaGVyZSBhcmUgdGhlIGF1dGhvcml6YXRpb24gZGVjaXNp b25zIHN0b3JlZD8KPj4gPiA+Pj4gSG93IGRvZXMgdGhlIGRpZ2l0YWwga2V5IGNvbW11bmljYXRl IHdpdGggdGhlIGxvY2s/IERvZXMgdGhlIGxvY2sKPj4gPiA+Pj4gaW50ZXJhY3Qgd2l0aCBhbiBh dXRob3JpemF0aW9uIHNlcnZlciB0byBvYnRhaW4gYXV0aG9yaXphdGlvbgo+PiA+ID4+PiBpbmZv cm1hdGlvbj8gSG93IGNhbiBhY2Nlc3MgYmUgZ3JhbnRlZCB0byBvdGhlciBwZXJzb25zIHRlbXBv cmFyaWx5Pwo+PiA+IEhvdyBjYW4gYWNjZXNzIGJlIHJldm9rZWQ/Cj4+ID4gPj4+IFRoZXNlIHR5 cGVzIG9mIHF1ZXN0aW9ucyBoYXZlIGJlZW4gYW5zd2VyZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xz Cj4+ID4gPj4+IGZvciB1c2UgY2FzZXMgb3V0c2lkZSB0aGUgY29uc3RyYWluZWQgZW52aXJvbm1l bnQuIEJ1dCBpbgo+PiA+ID4+PiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCwgYWRkaXRpb25hbCBy ZXF1aXJlbWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvcgo+PiA+ID4+PiB0aGUgdXNlIG9mIHZhcmlv dXMgc2VjdXJpdHkgcHJvdG9jb2xzLgo+PiA+ID4+Pgo+PiA+ID4+PiBUaGUgSUVURiBoYXMgYSBs b25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZSBwYXJ0eSBhdXRoZW50aWNhdGlvbgo+PiA+ ID4+PiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25t ZW50cy4gRXhhbXBsZXMKPj4gPiA+Pj4gaW5jbHVkZSBLZXJiZXJvcywgdGhlIFB1YmxpYyBLZXkg SW5mcmFzdHJ1Y3R1cmUgKFBLSSksIHRoZQo+PiA+ID4+PiBBdXRoZW50aWNhdGlvbiwgQXV0aG9y aXphdGlvbiwgYW5kIEFjY291bnRpbmcgKEFBQSkgaW5mcmFzdHJ1Y3R1cmUsCj4+ID4gPj4+IGFu ZCB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgKE9BdXRoKS4gQWxsIHRoZXNlIHByb3Rv Y29scwo+PiA+ID4+PiBlbmpveSB3aWRlc3ByZWFkIGRlcGxveW1lbnQgb24gdGhlIEludGVybmV0 LiBBbHRob3VnaCB0aGV5IGFsbCBhaW0KPj4gPiA+Pj4gdG8gc29sdmUgYSBzaW1pbGFyIGdvYWws IGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRlCj4+ID4gPj4+IGRpZmZlcmVu dCBmdW5jdGlvbnMgYW5kIHV0aWxpemUgZGlmZmVyZW50IG1lc3NhZ2UgZXhjaGFuZ2VzLiBUaGVz ZQo+PiA+ID4+PiBkaWZmZXJlbmNlcyBhcmUgbW90aXZhdGVkIGJ5IHRoZSBtYWluIGRlcGxveW1l bnQgdXNlIGNhc2VzIHRoZXkgd2VyZQo+PiA+IGRlc2lnbmVkIGZvci4KPj4gPiA+Pj4KPj4gPiA+ Pj4gUmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSB1c2UgY2FzZXMgaW5kaWNhdGUgdGhlIHN1aXRh YmlsaXR5IG9mCj4+ID4gPj4+IGFscmVhZHkgZXhpc3Rpbmcgd29yaywgc3VjaCBhcyBPQXV0aCwg YXMgYSBzb2x1dGlvbiBmb3IgY29uc3RyYWluZWQKPj4gPiA+Pj4gZW52aXJvbm1lbnRzLiBUaGVz ZSBwcm90b2NvbHMgd2VyZSwgaG93ZXZlciwgbm90IG9wdGltaXplZCBmb3IKPj4gPiA+Pj4gY29u c3RyYWluZWQgZW52aXJvbm1lbnRzLiBBZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IG5lZWQg dG8gYmUKPj4gPiA+Pj4gdGFrZW4gaW50byBhY2NvdW50IGFyZSB0aGUgbGFjayBvZiBhIHN1aXRh YmxlIHVzZXItaW50ZXJmYWNlIGZvcgo+PiA+ID4+PiBvYnRhaW5pbmcgdGhlIGNvbnNlbnQgb2Yg dGhlIHVzZXIgYW5kIHRoZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQKPj4gPiA+Pj4gZGV2aWNlcyB0 byBjb250YWN0IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGluIHJlYWwtdGltZSB3aXRoIGV2ZXJ5 Cj4+ID4gPj4+IGFjY2VzcyByZXF1ZXN0IGR1ZSB0byBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5 LCBldGMuCj4+ID4gPj4+Cj4+ID4gPj4+IFRoaXMgd29ya2luZyBncm91cCB0aGVyZWZvcmUgYWlt cyBmb3IgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZm9yCj4+ID4gPj4+IGF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIHRvIGVuYWJsZSBhdXRob3JpemVkIGFjY2VzcyB0bwo+PiA+ID4+ PiByZXNvdXJjZXMgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBBcyBhIHN0YXJ0aW5nIHBv aW50LCB0aGUKPj4gPiA+Pj4gd29ya2luZyBncm91cCB3aWxsIGFzc3VtZSB0aGF0IGFjY2VzcyB0 byByZXNvdXJjZXMgb2ZmZXJlZCBieSBhCj4+ID4gPj4+IHJlc291cmNlIHNlcnZlciBieSBhIGNs aWVudCBkZXZpY2VzIHRha2VzIHBsYWNlIHVzaW5nIENvQVAgYW5kIGlzIHByb3RlY3RlZAo+PiA+ IGJ5IERUTFMuCj4+ID4gPj4+IEJvdGggcmVzb3VyY2Ugc2VydmVyIGFuZCBjbGllbnQgbWF5IGJl IHJlc291cmNlIGNvbnN0cmFpbnQuIFRoaXMKPj4gPiA+Pj4gYWNjZXNzIHdpbGwgYmUgbWVkaWF0 ZWQgYnkgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdoaWNoIGRvZXMgbm90Cj4+ID4gPj4+IHN1 ZmZlciBmcm9tIHRoZSBzYW1lIHJlc291cmNlIGxpbWl0YXRpb25zLgo+PiA+ID4+Pgo+PiA+ID4+ PiBFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgYXJl IHVzZWQgYW5kCj4+ID4gPj4+IHJlLWFwcGxpZWQgZm9yIHVzZSB3aXRoIGNvbnN0cmFpbmVkIGRl dmljZXMsIHdoZXJlIGFwcGxpY2FibGUuIFRoaXMKPj4gPiA+Pj4gcmVxdWlyZXMgcmVsZXZhbnQg c3BlY2lmaWNhdGlvbnMgdG8gYmUgcmV2aWV3ZWQgZm9yIHN1aXRhYmlsaXR5LAo+PiA+ID4+PiBz ZWxlY3RpbmcgYSBzdWJzZXQgb2YgdGhlbSwgcmVzdHJpY3RpbmcgdGhlIG9wdGlvbnMgd2l0aGlu IGVhY2ggb2YKPj4gPiA+Pj4gdGhlIHNwZWNpZmljYXRpb25zLiBTb21lIGZ1bmN0aW9uYWxpdGll cyBtYXksIGhvd2V2ZXIsIG5vdCBiZQo+PiA+ID4+PiBhdmFpbGFibGUgaW4gZXhpc3RpbmcgcHJv dG9jb2xzIGFuZCBmb3IgdGhvc2UgY2FzZXMgbmV3Cj4+ID4gPj4+IGZ1bmN0aW9uYWxpdHkgaGFz IHRvIGJlIHN0YW5kYXJkaXplZC4gVGh1cywgZXhpc3Rpbmcgd29yayBjYW4gYmUKPj4gPiA+Pj4g bGV2ZXJhZ2VkIGFuZCB0aGUgZ3JvdXAgYmVuZWZpdHMgZnJvbSBhdmFpbGFibGUgc2VjdXJpdHkg YW5hbHlzaXMsCj4+ID4gPj4+IGltcGxlbWVudGF0aW9uLCBhbmQgZGVwbG95bWVudCBleHBlcmll bmNlLiBNb3Jlb3ZlciwgYSBzdGFuZGFyZGl6ZWQKPj4gPiA+Pj4gc29sdXRpb24gZm9yIGZlZGVy YXRlZCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB3aWxsIGhlbHAgdG8KPj4gPiA+ Pj4gc3RpbXVsYXRlIHRoZSBkZXBsb3ltZW50IG9mIElvVCBkZXZpY2VzIG9mZmVyaW5nIGluY3Jl YXNlZCBzZWN1cml0eS4KPj4gPiA+Pj4KPj4gPiA+Pj4gT25jZSBwcm9ncmVzcyBpbiBpZGVudGlm eWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuCj4+ID4gPj4+IG1hZGUg dGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB2ZXJpZnkgd2hldGhlciB0aGUgc2FtZSBtZWNoYW5pc20g YXJlCj4+ID4gPj4+IGFsc28gYXBwbGljYWJsZSBiZXlvbmQgdGhlIHVzZSBvZiBDb0FQIGFuZCBE VExTLiBJbiBwYXJ0aWN1bGFyLCB0aGUKPj4gPiA+Pj4gYWJpbGl0eSB0byB1c2UgdGhlIGRldmVs b3BlZCBzb2x1dGlvbiBvdmVyIEhUVFAgYW5kIFRMUyB3aWxsIGJlCj4+ID4gaW52ZXN0aWdhdGVk Lgo+PiA+ID4+PiBGdXJ0aGVybW9yZSwgdG8gZ3VhcmFudGVlIHNtb290aCB0cmFuc2l0aW9uIHRo ZSBpbnRlZ3JhdGlvbiB3aXRoCj4+ID4gPj4+IGV4aXN0aW5nIGRlcGxveW1lbnQgd2lsbCBiZSBz dHVkaWVkLiBUaGlzIHBhcnRpY3VsYXJseSBjb25jZXJucyB0aGUKPj4gPiA+Pj4gdXNlIG9mIHBy b3RvY29sIHRyYW5zbGF0aW9uIHByb3hpZXMuCj4+ID4gPj4+Cj4+ID4gPj4+IFRvIGJlIHN1Y2Nl c3NmdWwgdGhpcyB3b3JraW5nIGdyb3VwIHJlcXVpcmVzIGV4cGVydGlzZSBpbiBzZWN1cml0eSwK Pj4gPiA+Pj4gcHJpdmFjeSwgYW5kIGEgZ29vZCB1bmRlcnN0YW5kaW5nIG9mIHVzYWJpbGl0eSBp biB0aGUgY29uc3RyYWluZWQKPj4gPiA+Pj4gZW52aXJvbm1lbnQgc3BhY2UuIFRoaXMgd29yayBk b2VzIG5vdCBtYWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlCj4+ID4gPj4+IHBhcnR5IG9mZmVy aW5nIGFwcGxpY2F0aW9uIGxheWVyIHNlcnZpY2VzIGlzIGFsd2F5cyB0aGUgc2FtZSBwYXJ0eQo+ PiA+ID4+PiBvZmZlcmluZyBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlcy4KPj4gPiA+Pj4KPj4gPiA+ Pj4gVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRoZSBmb2xsb3dpbmcgdGFza3MgKGluIHRoaXMgb3Jk ZXIpOgo+PiA+ID4+Pgo+PiA+ID4+PiAxKSBUaGUgd29ya2luZyBncm91cCBXaWtpIHBhZ2VzIHdp bGwgYmUgdXNlZCB0byBkb2N1bWVudCB1c2UgY2FzZXMsCj4+ID4gPj4+IHJlcXVpcmVtZW50cywg YW5kIHByb3RvY29sIGRlc2lnbiBjcml0ZXJpYS4gVGhpcyB3b3JrIHdpbGwgZ3VpZGUgdGhlCj4+ ID4gPj4+IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3RvY29sIG1lY2hhbmlzbXMuCj4+ ID4gPj4+Cj4+ID4gPj4+IDIpIFNlbGVjdGlvbiBvZiBhbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0 aG9yaXphdGlvbiBwcm90b2NvbCBmb3IKPj4gPiA+Pj4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRz Lgo+PiA+ID4+Pgo+PiA+ID4+PiAzKSBFdmFsdWF0aW9uIG9mIHRoZSBjYW5kaWRhdGUgc29sdXRp b24gZm9yIHVzZSB3aXRoIEhUVFAvVExTIGFuZAo+PiA+ID4+PiBwcm94eSBkZXBsb3ltZW50cy4K Pj4gPiA+Pj4KPj4gPiA+Pj4gLS0tLS0KPj4gPiA+Pj4KPj4gPiA+Pj4gQ2lhbwo+PiA+ID4+PiBI YW5uZXMKPj4gPiA+Pj4KPj4gPiA+Pj4gPHNpZ25hdHVyZS5hc2M+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gPiA+Pj4gQWNlIG1haWxpbmcgbGlzdAo+ PiA+ID4+PiBBY2VAaWV0Zi5vcmcKPj4gPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2UKPj4gPiA+Pgo+PiA+ID4+IFphY2ggU2hlbGJ5Cj4+ID4gPj4gRGlyZWN0 b3Igb2YgVGVjaG5vbG9neQo+PiA+ID4+IEFSTSBJbnRlcm5ldCBvZiBUaGluZ3MgQlUKPj4gPiA+ PiB3d3cuYXJtLmNvbQo+PiA+ID4+IG1vYmlsZTogKzEgKDQwOCkgMjAzLTk0MzQKPj4gPiA+PiBT a3lwZTogemRzaGVsYnkKPj4gPiA+PiBMaW5rZWRJbjogZmkubGlua2VkaW4uY29tL2luL3phY2hz aGVsYnkvCj4+ID4gPj4KPj4gPiA+Pgo+PiA+ID4+IC0tIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMKPj4gPiA+PiBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUK Pj4gPiA+PiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90Cj4+ID4gPj4gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yCj4+ID4gPj4gc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS7CoCBUaGFuayB5b3UuCj4+ID4gPj4K Pj4gPiA+PiBBUk0gTGltaXRlZCwgUmVnaXN0ZXJlZCBvZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQs IENhbWJyaWRnZSBDQjEgOU5KLAo+PiA+ID4+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVz LCBDb21wYW55IE5vOsKgIDI1NTc1OTAgQVJNIEhvbGRpbmdzIHBsYywKPj4gPiA+PiBSZWdpc3Rl cmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVy ZWQgaW4KPj4gPiA+PiBFbmdsYW5kICYgV2FsZXMsIENvbXBhbnkgTm86wqAgMjU0ODc4Mgo+PiA+ ID4+Cj4+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPj4gPiA+PiBBY2UgbWFpbGluZyBsaXN0Cj4+ID4gPj4gQWNlQGlldGYub3JnCj4+ID4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UKPj4gPiA+Cj4+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiA+ID4gQWNl IG1haWxpbmcgbGlzdAo+PiA+ID4gQWNlQGlldGYub3JnCj4+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQo+PiA+ID4KPj4KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gQWNlIG1haWxpbmcgbGlzdAo+PiBBY2VA aWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UKPj4K Pj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4g QWNlIG1haWxpbmcgbGlzdAo+Pgo+PiBBY2VAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hY2UKPgo+IDxzbWltZS5wN3M+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBBY2UgbWFpbGluZyBsaXN0Cj4gQWNlQGll dGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UKClphY2gg U2hlbGJ5CkRpcmVjdG9yIG9mIFRlY2hub2xvZ3kKQVJNIEludGVybmV0IG9mIFRoaW5ncyBCVQp3 d3cuYXJtLmNvbQptb2JpbGU6ICsxICg0MDgpIDIwMy05NDM0ClNreXBlOiB6ZHNoZWxieQpMaW5r ZWRJbjogZmkubGlua2VkaW4uY29tL2luL3phY2hzaGVsYnkvCgoKLS0gSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS7CoCBUaGFuayB5b3UuCgpBUk0gTGltaXRlZCwgUmVnaXN0ZXJlZCBvZmZpY2Ug MTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRnZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGluIEVuZ2xh bmQgJiBXYWxlcywgQ29tcGFueSBObzrCoCAyNTU3NTkwCkFSTSBIb2xkaW5ncyBwbGMsIFJlZ2lz dGVyZWQgb2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0 ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMsIENvbXBhbnkgTm86wqAgMjU0ODc4MgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpBY2UgbWFpbGluZyBsaXN0CkFj ZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQo= ----_com.android.email_809215972640270 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+UHVibGlzaGluZyB0aGUgcmVxdWly ZW1lbnRzIGFuZCB1c2UgY2FzZXMgaW4gYW4gUkZDIGlzIE5PVCB0aGUgc2FtZSB0aGluZyBhcyBn YXRpbmcgb3VyIG90aGVyIHdvcmsgb24gcHVibGlzaGluZyB0aG9zZSB0aGluZ3MgZmlyc3QgLS0g SSB3b3VsZCBvYmplY3QgdG8gYSBwaGFzZWQgY2hhcnRlciB0aGF0IHJlcXVpcmVzIHVzIHRvIHB1 Ymxpc2ggb3VyIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGFzIFJGQ3MgYmVmb3JlIHdlIGRv IGFueSBwcm90b2NvbCB3b3JrLCBhbmQgSSBsaWtlIHRoZSBpZGVhIG9mIHVzaW5nIGEgd2lraSB0 byBjb2xsZWN0IGFuZCByZWZpbmUgdGhlbS48ZGl2Pjxicj48L2Rpdj48ZGl2PldlIHNob3VsZCBy ZW1lbWJlciwgdGhvdWdoLCB0aGF0IHdlIHdpbGwgbmVlZCB0byBpbnZvbHZlIGEgd2lkZSByYW5n ZSBvZiBJRVRGIHBhcnRpY2lwYW50cywgaW5jbHVkaW5nIG11bHRpcGxlIElFVEYgc2VjdXJpdHkg ZXhwZXJ0cywgdG8gYmUgc3VjY2Vzc2Z1bC4gJm5ic3A7Tm90IGFsbCBvZiB0aG9zZSBwZW9wbGUg d2lsbCBoYXZlIHdvcmtlZCBpbiB0aGUgSW9UL2VtYmVkZGVkIHNwYWNlLCBzbyBkb2N1bWVudGlu ZyB0aGUgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZWFybHkgaW4gdGhlIHByb2Nlc3MgKG9u IGEgd2lraSBwYWdlIGlzIGZpbmUpIHdpbGwgYmUgZXNzZW50aWFsIHRvIGFsbG93aW5nIHRoYXQg d2lkZXIgc2V0IG9mIElFVEYgcGFydGljaXBhbnRzIHRvIGVuZ2FnZSBjb25zdHJ1Y3RpdmVseS48 ZGl2Pjxicj48ZGl2PkknZCBwZXJzb25hbGx5IGxpa2UgdG8gc2VlIHRoZSB1c2UgY2FzZXMgYW5k IHJlcXVpcmVtZW50cyBjYXB0dXJlZCBpbiBhbiBhY2hpdmFsIGZvcm0gdGhhdCBjYW4gYmUgcmVm ZXJlbmNlZCBsYXRlciwgYmVjYXVzZSBJIHRoaW5rIHRoZSB1c2UgY2FzZXMsIGluIHBhcnRpY3Vs YXIsIG1pZ2h0IGJlIHVzZWZ1bCBmb3IgbGF0ZXIgd29yay4gJm5ic3A7SSdkIGJlIHBlcmZlY3Rs eSBoYXBweSB3aXRoIHB1Ymxpc2hpbmcgdGhlbSBhcyBSRkNzIGxhdGVyIGluIHRoZSBwcm9jZXNz LCB0aG91Z2guPGRpdj48YnI+PC9kaXY+PGRpdj5JZiBwZW9wbGUgd291bGQgcmF0aGVyIHRyeSB0 byBjYXB0dXJlIHRoZSBtYWpvciB1c2UgY2FzZXMgYW5kIG1vdGl2YXRpb25zIGluIHRoZSBwcm90 b2NvbCBzcGVjIGluc3RlYWQsIEkgZ3Vlc3MgdGhhdCB3b3VsZCB3b3JrIGZvciBtZSwgYnV0IEkg d291bGQgc29tZXdoYXQgcHJlZmVyIGFuIHVuY2x1dHRlcmVkIHByb3RvY29sIHNwZWMgdGhhdCBy ZWZlcnMgdG8gc3VwcG9ydGluZyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cy4gJm5ic3A7PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5NYXJnYXJldDwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjxicj48 YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbSBaYWNoIFNo ZWxieSAmbHQ7WmFjaC5TaGVsYnlAYXJtLmNvbSZndDsgPGJyPkRhdGU6IDAzLzE0LzIwMTQgIDEx OjMxIEFNICAoR01ULTA1OjAwKSA8YnI+VG8gcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tIDxi cj5DYyBhY2VAaWV0Zi5vcmcgPGJyPlN1YmplY3QgUmU6IFtBY2VdIEFDRSBDaGFydGVyIFByb3Bv c2FsIHYwLjUgPGJyPiA8YnI+PGJyPkFzIEkgbWVudGlvbmVkIGluIHRoZSBCb0YsIG15IGFkdmlj ZSB3b3VsZCBiZSB0byBqdXN0IHVzZSBhIHdpa2kgdG8gY29sbGVjdCB1c2UgY2FzZXMgYW5kIHJl cXVpcmVtZW50cy48YnI+PGJyPk5vdywgaWYgd2Ugd2FudCB0byB3YXN0ZSB0aGUgZmlyc3QgaGFs ZiB5ZWFyIGJyaW5pbmcgc3VjaCBkcmFmdHMgdGhyb3VnaCB0aGUgUkZDIHByb2Nlc3MgdGhlbiBn byBhaGVhZC4gRnJvbSBteSBleHBlcmllbmNlIHRoZXNlIGtpbmRzIG9mIHdvcmsgaXRlbXMgYXJl IGp1c3QgYSBXRyBibGFjayBob2xlLiBZb3UgY2FuIGFsd2F5cyBkb2N1bWVudCB0aGUgYXNzdW1l ZCB1c2UgY2FzZXMgd2l0aGluIHRoZSBhY3R1YWwgdGVjaG5pY2FsIHNwZWNpZmljYXRpb24gdG8g bWFrZSBpdCBjbGVhciB3aGF0IHByb2JsZW0gaXQgaXMgdHJ5aW5nIHRvIHNvbHZlLjxicj48YnI+ WmFjaDxicj48YnI+T24gTWFyIDE0LCAyMDE0LCBhdCA4OjAyIEFNLCBSb2JlcnQgQ3JhZ2llICZs dDtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0OyArMSB0 byBib3RoIE1hcmdhcmV0J3Mgc3RhdGVtZW50cy48YnI+Jmd0Ozxicj4mZ3Q7IFJvYmVydDxicj4m Z3Q7PGJyPiZndDsgT24gMTMvMDMvMjAxNCAxMDo1NSBBTSwgTWFyZ2FyZXQgV2Fzc2VybWFuIHdy b3RlOjxicj4mZ3Q7Jmd0OyBQZXJzb25hbGx5LCBJIHdvdWxkIGFsc28gcmF0aGVyIHNlZSB0aGUg dXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgcHVibGlzaGVkIGFzIGluZm9ybWF0aW9uYWxSRkNz LiZuYnNwOyBJIHRoaW5rIHRoYXQgYSB3aWtpIG1pZ2h0IGJlIGEgZ29vZCB3YXkgdG8gY29sbGVj dCB0aGVtIGF0IGZpcnN0LCBidXQgSSB3b3VsZCBwcmVmZXIgdG8gYmUgc3VyZSB0aGF0IHdlIGhh dmUgY29uc2Vuc3VzIG9uIHRoZSBwcm9ibGVtKHMpIHdlIGFyZSB0cnlpbmcgdG8gc29sdmUuJm5i c3A7IEkgYWxzbyB0aGluayBpdCB3aWxsIGJlIHVzZWZ1bCB0byBoYXZlIHRoZXNlIHRoaW5ncyBp biBhcmNoaXZhbCBmb3JtIGxhdGVyLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIGRvIG5vdCB0 aGluayB0aGUgb3RoZXIgd29yayBvZiB0aGUgZ3JvdXAgc2hvdWxkIGJlIGdhdGVkIG9uIHRoZSBy ZXF1aXJlbWVudHMsIHRob3VnaCwgYXMgSSB0aGluayB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGV4 cGxvcmUgaG93IGV4aXN0aW5nIHRlY2hub2xvZ2llcyBjb3VsZCBvciBjb3VsZG4ndCBtZWV0IHRo ZSByZXF1aXJlbWVudHMgdG8gaW5zdXJlIHRoYXQgb3VyIHJlcXVpcmVtZW50cyBhcmUgcmVhbGl0 eS1iYXNlZC48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgTWFyZ2FyZXQ8YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTxicj4mZ3Q7Jmd0OyBGcm9tIExpa2VwZW5nICZsdDtsaWtlcGVuZ0BodWF3ZWku Y29tJmd0Ozxicj4mZ3Q7Jmd0OyBEYXRlOiAwMy8xMy8yMDE0IDQ6MjggQU0gKEdNVC0wNTowMCk8 YnI+Jmd0OyZndDsgVG8gSGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdt eC5uZXQmZ3Q7LEfDtnJhbiBTZWxhbmRlciAmbHQ7Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29t Jmd0OyxaYWNoIFNoZWxieSAmbHQ7WmFjaC5TaGVsYnlAYXJtLmNvbSZndDs8YnI+Jmd0OyZndDsg Q2MgYWNlQGlldGYub3JnPGJyPiZndDsmZ3Q7IFN1YmplY3QgUmU6IFtBY2VdIEFDRSBDaGFydGVy IFByb3Bvc2FsIHYwLjU8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgTXkgcGVy c29uYWwgb3BpbmlvbiBpcyB0aGF0IHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRvY3Vt ZW50IGNhbiBoZWxwIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQga2luZCBvZiBpc3N1ZXMgd2Ug YXJlIHRyeWluZyB0byByZXNvbHZlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIGNhbiBzZWUg c29tZSB2YWx1ZXMgdG8gcHVibGlzaCBpdCBpbnRvIFJGQ3MuIElmIGl0IGlzIGEgd2lraSBwYWdl LCB3ZSB3aWxsIGhhdmUgbGVzcyBwZW9wbGUgdG8gcmV2aWV3IGl0IG9yIGltcHJvdmUgaXQuPGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEVzcGVjaWFsbHkgdGhlIHVzZSBjYXNlIGFuZCByZXF1aXJl bWVudCBkb2N1bWVudCBpcyBhbHJlYWR5IGluIGEgZ29vZCBzaGFwZSBhbmQgaXQgaXMgcmVmZXJl bmNlZCBzZXZlcmFsIHRpbWVzIGluIHRoZSBtYWlsaW5nIGxpc3QgdG8gaW50cm9kdWNlIG91ciB3 b3JrIHRvIG91dHNpZGUuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFRoYW5rcyw8YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsgS2luZCBSZWdhcmRzPGJyPiZndDsmZ3Q7IEtlcGVuZzxicj4mZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyAmZ3Q7IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS08YnI+Jmd0OyZndDsgJmd0 OyDlj5Hku7bkuro6IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggSGFu bmVzIFRzY2hvZmVuaWc8YnI+Jmd0OyZndDsgJmd0OyDlj5HpgIHml7bpl7Q6IDIwMTTlubQz5pyI MTPml6UgNDozMzxicj4mZ3Q7Jmd0OyAmZ3Q7IOaUtuS7tuS6ujogR8O2cmFuIFNlbGFuZGVyOyBa YWNoIFNoZWxieTxicj4mZ3Q7Jmd0OyAmZ3Q7IOaKhOmAgTogYWNlQGlldGYub3JnPGJyPiZndDsm Z3Q7ICZndDsg5Li76aKYOiBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9zYWwgdjAuNTxicj4m Z3Q7Jmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgSGkgR29lcmFuLDxicj4mZ3Q7Jmd0OyAmZ3Q7 PGJyPiZndDsmZ3Q7ICZndDsgSSByZWFkIGEgbGl0dGxlIGJpdCBiZXR3ZWVuIHRoZSBsaW5lcyBv ZiB5b3VyIG1haWwgYW5kIHlvdXIgbWFpbiBjb25jZXJuIGlzIHRoYXQ8YnI+Jmd0OyZndDsgJmd0 OyB5b3Ugd2FudCB0byBoYXZlIGFuIFJGQyBwdWJsaXNoZWQgd2l0aCB5b3VyIG5hbWUgb24gaXQu PGJyPiZndDsmZ3Q7ICZndDsgQSB3aWtpIHBhZ2UgdG8gZG9jdW1lbnQgdGhlIHJlcXVpcmVtZW50 cywgYW5kIHVzZSBjYXNlcyBpcyBub3QgZ29vZCBlbm91Z2g8YnI+Jmd0OyZndDsgJmd0OyBmb3Ig eW91Ljxicj4mZ3Q7Jmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgRm9yIHlvdSBwdXR0aW5nIHRo ZSBkcmFmdCB0ZXh0IG9uIGEgV0cgd2lraSBmZWVscyBsaWtlIHdhc3RlZCB0aW1lLjxicj4mZ3Q7 Jmd0OyAmZ3Q7IEl0IGlzIGp1c3QgYSBkaWZmZXJlbnQgZm9ybSBvZiBkb2N1bWVudGluZyB0aGUg d29yay48YnI+Jmd0OyZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7IE15IGV4cGVyaWVuY2Ugd2l0 aCB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBoYXMgbm90IGJlZW4gZ3JlYXQgaW4gdGhlIElF VEYuPGJyPiZndDsmZ3Q7ICZndDsgSW4gZXNzZW5jZSBldmVyeW9uZSBxdWlja2x5IG1vdmVzIG9u IG9uY2UgdGhlIGdyb3VwIGRlY2lkZXMgYWJvdXQgYTxicj4mZ3Q7Jmd0OyAmZ3Q7IHBhcnRpY3Vs YXIgc29sdXRpb24gZGlyZWN0aW9uLiBJdCB0aGVuIGJlY29tZXMgdmVyeSBoYXJkIChmb3IgdGhl PGJyPiZndDsmZ3Q7ICZndDsgY2hhaXJzKSB0byBmaW5pc2ggdGhlIHJlcXVpcmVtZW50cyB3b3Jr IHNpbmNlIG5vYm9keSB3YW50cyB0byByZXZpZXcgb3IgbG9vazxicj4mZ3Q7Jmd0OyAmZ3Q7IGF0 IHRoZW0gYW55bW9yZS48YnI+Jmd0OyZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7IFVzZSBjYXNl cyBhbmQgcmVxdWlyZW1lbnRzIGFyZSBncmVhdCBkdXJpbmcgdGhlIGluaXRpYWwgcGFydCBvZiB0 aGUgd29yayB0byBnZXQ8YnI+Jmd0OyZndDsgJmd0OyBhbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBt YWluIGNoYWxsZW5nZXMuPGJyPiZndDsmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyBIYXZpbmcg c2FpZCB0aGF0IEkgd2lsbCBsZWF2ZSBpdCB0byB0aGUgZ3JvdXAgdG8gZGVjaWRlIHdoYXQgdGhl eSB3YW50IHRvIGRvOjxicj4mZ3Q7Jmd0OyAmZ3Q7IFJGQ3Mgb3IgV2lraSBwYWdlPGJyPiZndDsm Z3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyBDaWFvPGJyPiZndDsmZ3Q7ICZndDsgSGFubmVzPGJy PiZndDsmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyBQUzogUmVnYXJkaW5nIHlvdXIgb3RoZXIg Y29tbWVudCBhYm91dCBwb2ludGluZyB0byB0aGUgY29uc3RyYWludCBuYXR1cmUgdG88YnI+Jmd0 OyZndDsgJmd0OyBldmVyeSBpdGVtLiBXZSBjYW4gZG8gdGhhdCBpZiB5b3UgZmVlbCBiZXR0ZXIg YnV0IHRoZSBlbnRpcmUgY2hhcnRlciBwYWdlPGJyPiZndDsmZ3Q7ICZndDsgYWxyZWFkeSBzYXlz IDEwIHRpbWVzIHRoYXQgd2UgYXJlIGZvY3VzaW5nIG9uIHRoZSBjb25zdHJhaW50IHNwYWNlLjxi cj4mZ3Q7Jmd0OyAmZ3Q7IEkgYW0gc3VyZSB0aGF0IHRoZSByZWFkZXIgd2lsbCBoYXZlIHVuZGVy c3Rvb2QgdGhhdCB3aGVuIHRoZXkgZ2V0IHRvIHRoZSB0YXNrPGJyPiZndDsmZ3Q7ICZndDsgbGlz dC48YnI+Jmd0OyZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgT24g MDMvMTIvMjAxNCAxMDozMiBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOjxicj4mZ3Q7Jmd0OyAm Z3Q7ICZndDsgSGFubmVzLCBaYWNoIGFuZCBhbGwsPGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4m Z3Q7Jmd0OyAmZ3Q7ICZndDsgSSBtdXN0IHNheSBJIGRvbsK5dCBmaW5kIHRoZSB0YXNrIGxpc3Qg b2YgdGhlIGN1cnJlbnQgY2hhcnRlciB2ZXJ5IGhlbHBmdWw6PGJyPiZndDsmZ3Q7ICZndDsgJmd0 Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgwrNUaGUgd29ya2luZyBncm91cCBoYXMgdGhlIGZvbGxv d2luZyB0YXNrcyAoaW4gdGhpcyBvcmRlcik6PGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7 Jmd0OyAmZ3Q7ICZndDsgMSkgVGhlIHdvcmtpbmcgZ3JvdXAgV2lraSBwYWdlcyB3aWxsIGJlIHVz ZWQgdG8gZG9jdW1lbnQgdXNlIGNhc2VzLDxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1l bnRzLCBhbmQgcHJvdG9jb2wgZGVzaWduIGNyaXRlcmlhLiBUaGlzIHdvcmsgd2lsbCBndWlkZSB0 aGU8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3Rv Y29sIG1lY2hhbmlzbXMuPGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZn dDsgMikgU2VsZWN0aW9uIG9mIGFuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHBy b3RvY29sIGZvcjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgY29uc3RyYWluZWQgZW52aXJvbm1lbnRz Ljxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IDMpIEV2YWx1YXRp b24gb2YgdGhlIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggSFRUUC9UTFMgYW5kPGJy PiZndDsmZ3Q7ICZndDsgJmd0OyBwcm94eSBkZXBsb3ltZW50cy7Csjxicj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IFRoaXMgbGlzdCBkb2VzIG5vdCBnaXZlIG11Y2gg bW9yZSBkZXRhaWxzIGFib3V0IHRoZSB3b3JrIHRvIGJlPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBj b25kdWN0ZWQgdGhhbiBpcyBhbHJlYWR5IGdpdmVuIGJ5IHRoZSB0aXRsZSBvZiB0aGUgV0cuIFRv IGEgcGVyc29uPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBub3QgaGF2aW5nIGZvbGxvd2VkIHRoZSBk aXNjdXNzaW9uLCB0aGUgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSB3b3JrPGJyPiZndDsmZ3Q7ICZn dDsgJmd0OyBzdGFydHMgZnJvbSBzY3JhdGNoIGFuZCB0aGVyZSBpcyBubyBjbGVhciB1bmRlcnN0 YW5kaW5nIG9mIHdoYXQgdG8gZG8uPGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAm Z3Q7ICZndDsgSWYgd2UgY2Fuwrl0IGZvcm11bGF0ZSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5k IGZpcnN0IHN0ZXAgdG93YXJkcyBhPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBzb2x1dGlvbiBpbiBz b21lIGRlZ3JlZSBvZiBkZXRhaWwgYmVmb3JlIHN0YXJ0aW5nIHRoZSBXRyB0aGF0IHdpbGw8YnI+ Jmd0OyZndDsgJmd0OyAmZ3Q7IGFueXdheSBiZSB0aGUgZmlyc3QgdGFzayB0byBkbywgc28gbGV0 wrlzIHRyeSB0byBnZXQgc29tZXRoaW5nIGluIHdyaXRpbmcuPGJyPiZndDsmZ3Q7ICZndDsgJmd0 Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7ICIxKSBUaGUgd29y a2luZyBncm91cCBXaWtpIHBhZ2VzIHdpbGwgYmUgdXNlZCB0byBkb2N1bWVudCB1c2UgY2FzZXMs PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24g Y3JpdGVyaWEuIFRoaXMgd29yayB3aWxsIGd1aWRlIHRoZTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsg aWRlbnRpZmljYXRpb24gb2Ygc3VpdGFibGUgcHJvdG9jb2wgbWVjaGFuaXNtcy4iPGJyPiZndDsm Z3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyBoaWRpbmcgdGhlIGZh Y3QgdGhhdCB0aGVyZSBoYXMgYmVlbiA2IG1vbnRocyBvZiB3b3JrIG9uIHRoZTxicj4mZ3Q7Jmd0 OyAmZ3Q7ICZndDsgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50cyBkcmFmdCAodGhlIGZpcnN0IHZl cnNpb24gb2YgdGhpcyBkcmFmdCB3YXM8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IHN1Ym1pdHRlZCB0 byBDb1JFIGluIElFVEY4OCksIHdoaWNoIG5vIG9uZSBoYXMgZGlzYWdyZWVkIGlzIHNldHRpbmc8 YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IHRoZSBzdGFnZSBmb3IgdGhpcyB3b3JrLiBMb29rIGF0IHBh cmFsbGVsIHRocmVhZHMgb24gdGhpcyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7 IHdoZXJlIHBlb3BsZSBhc2sgd2hldGhlciB0aGVpciBwYXJ0aWN1bGFyIHNlY3VyaXR5LWZvci1J b1QgZHJhZnQgZml0czxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgaW50byBBQ0UuIFRoZSBhbnN3ZXIg SGFubmVzIGlzIGdpdmluZyBpcyBjb3JyZWN0bHk6IHRoZSBzY29wZSBvZiB0aGlzPGJyPiZndDsm Z3Q7ICZndDsgJmd0OyB3b3JrIGlzIHdoYXQgaXMgb3V0bGluZWQgYnkgdGhlIHVzZSBjYXNlIGFu ZCByZXF1aXJlbWVudHMgZHJhZnQuIEk8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IGRvbsK5dCBtaW5k IHVzaW5nIHRoZSBXaWtpIGFzIGEgd29ya2luZyB0b29sIGJ1dCB0aGlzIGRvZXMgbm90IGdpdmU8 YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IHRyYWNlYWJpbGl0eSBhIHllYXIgbGF0ZXIuIEFuZCBJIGRv bsK5dCBzZWUgdGhlIHBvaW50IGlmIGNvcHlpbmcgdGhlPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyB1 c2UgY2FzZSBkb2N1bWVudCBpbnRvIGEgV2lraSBwYWdlIC0gcmVhZCB0aGUgZHJhZnQgYW5kIHBy b3ZpZGUgeW91cjxicj4mZ3Q7Jmd0OyAmZ3Q7IGNvbW1lbnRzITxicj4mZ3Q7Jmd0OyAmZ3Q7ICZn dDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IFdoZW4gaXQgY29tZXMgdG8gcHJvdG9jb2wgZGVzaWdu IGNyaXRlcmlhLCBJIGFncmVlIHRoYXQgbW9yZSB3b3JrIGlzPGJyPiZndDsmZ3Q7ICZndDsgJmd0 OyBuZWVkZWQsIGZvciB3aGljaCB0aGUgV2lraSBtYXkgYmUgc3VpdGFibGUuIE5ldmVydGhlbGVz cyBJIGluc2lzdCBvbjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgZG9jdW1lbnRpbmcgdGhlIGRlc2ln biBjcml0ZXJpYSBhbmQgaXRzIHJhdGlvbmFsZSBzaW5jZSB0aGF0IHByb3ZpZGVzPGJyPiZndDsm Z3Q7ICZndDsgJmd0OyBhIG1lYW5zIGZvciB0cmFjZWFiaWxpdHkuIE1ha2UgaXQgYSBtaWxlc3Rv bmUgdG8gaGF2ZSBhIGRyYWZ0IHdpdGg8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IGFzc3VtcHRpb25z IGFuZCBkZXNpZ24gY3JpdGVyaWEmbmJzcDsgKHlvdSBtYXkgaW5jbHVkZSDCs2FyY2hpdGVjdHVy ZcKyIGluPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyB0aGlzIGRvY3VtZW50KS4gVGhpcyB3b3JrIGlz IGFueXdheSBhIHByZS1yZXF1aXNpdGUgZm9yIGNvbWluZyB0byBhPGJyPiZndDsmZ3Q7ICZndDsg Jmd0OyBzb2x1dGlvbiwgYW5kIG9uY2UgeW91IGhhdmUgdGhpcyBjb250ZW50LCB0aGUgY2FuZGlk YXRlIHNvbHV0aW9ucyBhcmU8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IG11Y2ggZWFzaWVyIGV2YWx1 YXRlZC48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBTbywgY2hh bmdlIDEpIHRvIHN0YXRlIHNvbWV0aGluZyBsaWtlPGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4m Z3Q7Jmd0OyAmZ3Q7ICZndDsgIjHCuSApPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBhKSBjb21wbGV0 ZSB0aGUgd29yayBvbiB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzPGJyPiZndDsmZ3Q7ICZndDsg Jmd0OyBiKSB1c2UgV2lraSBwYWdlcyBmb3IgbGlzdGluZyBhc3N1bXB0aW9ucyBhbmQgcHJvdG9j b2wgZGVzaWduPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBjcml0ZXJpYSwgZG9jdW1lbnQgdGhlIHJl c3VsdCBpbiBhIGRyYWZ0Ijxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAm Z3Q7IFByb3h5IGRlcGxveW1lbnQgYXNwZWN0cyBmaXRzIHdlbGwgaW50byAxYikmbmJzcDsgW21v cmUgaW4gc2VwYXJhdGU8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IHVwY29taW5nIG1haWxdPGJyPiZn dDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAm Z3Q7IDIpIFNlbGVjdGlvbiBvZiBhbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBw cm90b2NvbCBmb3I8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IGNvbnN0cmFpbmVkIGVudmlyb25tZW50 cy48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBIZXJlIEnCuW0g bWlzc2luZyBhbW9uZyBvdGhlciB0aGluZ3MgdGhlIHNwZWNpZmljIHByb2JsZW0gc3RhdGVtZW50 Ljxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgVGhlIHByZWxpbWluYXJ5IGNvbmNsdXNpb25zIGZyb20g dGhlIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZHJhZnQ8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7 IGZvcm1lZCB0aGUgYmFzaXMgZm9yIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhcyBwcmVzZW50ZWQg aW4gdGhlIEJPRjogV2U8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IGxhY2sgYSBtZWNoYW5pc20gZm9y IGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZCBhY2Nlc3MgY29udHJvbCBmb3I8YnI+Jmd0OyZndDsg Jmd0OyAmZ3Q7IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7 PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBUaGUgcHJvY2VzcyBoZXJlIHNob3VsZCBiZSB0bzo8YnI+ Jmd0OyZndDsgJmd0OyAmZ3Q7ICIywrkpIGlkZW50aWZ5IHN1aXRhYmxlIHByb3RvY29sIG1lY2hh bmlzbXMgYW5kIG1hdGNoIGNhbmRpZGF0ZTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGFnYWluc3QgcmVxdWlyZW1lbnRzIGFu ZDxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgZGVzaWduIGNyaXRlcmlhLCBpbiBwYXJ0aWN1bGFyIGFk ZHJlc3NpbmcgZHluYW1pYyBhbmQgZmluZSBncmFpbmVkPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBh Y2Nlc3MgY29udHJvbCBzdWl0YWJsZSBmb3IgQ29BUCByZXNvdXJjZSBhY2Nlc3MgcmVxdWVzdHMg aW4gY29uc3RyYWluZWQ8YnI+Jmd0OyZndDsgJmd0OyBlbnZpcm9ubWVudHMuIjxicj4mZ3Q7Jmd0 OyAmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxi cj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsgMykgRXZhbHVhdGlvbiBvZiB0aGUgY2FuZGlkYXRlIHNvbHV0 aW9uIGZvciB1c2Ugd2l0aCBIVFRQL1RMUyBhbmQ8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IHByb3h5 IGRlcGxveW1lbnRzLsKyPGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZn dDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IEFzIG1lbnRpb25lZCBhYm92ZSwgcHJveHkgZGVwbG95 bWVudHMgY291bGQgYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mPGJyPiZndDsmZ3Q7ICZndDsgMcK5 YikuPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBJbiAywrkpIGl0IGlzIGFscmVhZHkgc3RhdGVkIHRo YXQgaW4gcGFydGljdWxhciB3ZSBzaG91bGQgY29uc2lkZXIgQ29BUDxicj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDsgb24gaW50ZXJmYWNlIChJSSkuIEFzIGZvciB1c2Ugb2Ygb3RoZXIgcHJvdG9jb2xzIGJl c2lkZXMgQ29BUCB0aGF0PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBpc3N1ZSBpcyBvcnRob2dvbmFs IHRvIHRoaXMgc28gSSBsZWF2ZSB0aGF0IG91dCBmcm9tIHRoaXMgZGlzY3Vzc2lvbi48YnI+Jmd0 OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZn dDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IEfDtnJhbjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+ Jmd0OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBPbiAxMS8w My8xNCAxNjo0OSwgIlphY2ggU2hlbGJ5IiAmbHQ7WmFjaC5TaGVsYnlAYXJtLmNvbSZndDsgd3Jv dGU6PGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IEhhbm5l cyw8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IEkg YW0gaGFwcHkgd2l0aCB0aGlzIGNoYXJ0ZXIgd2l0aCBvbmUgZXhjZXB0aW9uLiBUaGUgcHJveHkg aXRlbSBoZXJlPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgc2VlbXMgdG8gYmUgbW9yZSBvZiBh IGRpc3RyYWN0aW9uIHRoYW4gYW55dGhpbmcgZWxzZSwgYW5kIHdpbGw8YnI+Jmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyBwcm9iYWJseSByZXN1bHQgaW4gaW5jcmVhc2VkIGNvbXBsZXhpdHkuIFdhcyBw cm94eSBzdXBwb3J0IG1heWJlIGp1c3Q8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBhIG1pc3Vu ZGVyc3RhbmRpbmc/IERvIHdlIHJlYWxseSBzZWUgdGhlIG5lZWQgZm9yIGEgcHJveHkgaW4gdGhl PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgbWlkZGxlIG9mIEkgb3IgSUlJPzxicj4mZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgSSB0aGluayB3aGF0IHdl IHJlYWxseSB3YW50IGhlcmUgaXMgdG8gbWFrZSBzdXJlIHRoYXQgZS5nLiBldmVuPGJyPiZndDsm Z3Q7ICZndDsgJmd0OyZndDsgdGhyb3VnaCBJIGlzIGJhc2VkIG9uIEhUVFAvVExTLCBJSSBhbmQg SUlJIGZvciBleGFtcGxlIGNhbiBydW48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBDb0FQL0RU TFMuIEluIG90aGVyIHdvcmRzLCBzb21lIGludGVyZmFjZXMgY2FuIGJlIGNvbnN0cmFpbmVkIHdo aWxlPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgb3RoZXJzIGFyZSBub3QuIEkgdGhpbmsgdGhl IGNoYXJ0ZXIgYWxyZWFkeSBjb3ZlcnMgdGhpcyBmaW5lLjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgU28gbXkgcHJvcG9zYWwgd291bGQgYmUgdG8g cmVtb3ZlIHRoZSBtZW50aW9uIG9mIHByb3RvY29sIHRyYW5zbGF0aW9uPGJyPiZndDsmZ3Q7ICZn dDsgJmd0OyZndDsgcHJveGllcy4gSWYgd2UgcmVhbGx5IHNlZSB0aGUgbmVlZCBmb3IgdGhpcyBz b21lIGRheSBpbiB0aGUgZnV0dXJlLDxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IGl0IGNvdWxk IGJlIHRhY2tsZWQgdGhlbi48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAm Z3Q7ICZndDsmZ3Q7IFphY2g8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAm Z3Q7ICZndDsmZ3Q7IE9uIE1hciAxMSwgMjAxNCwgYXQgMTI6NTAgQU0sIEhhbm5lcyBUc2Nob2Zl bmlnPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7IEhpIGFsbCw8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgSSBoYXZlIHRha2VuIHRoZSBmZWVkYmFjayBmcm9tIHRo ZSBtZWV0aW5nIGFuZCB0aGUgcmVjZW50PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGRp c2N1c3Npb25zIG9uIHRoZSBtYWlsaW5nIGxpc3QgYW5kIHByb2R1Y2VkIGEgbmV3IHN0cmF3bWFu IHByb3Bvc2FsLjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyBUaGUgY2hhbmdlcyBpbmNsdWRlOjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0OyAqIEFkZGVkIHRoZSBmb2N1cyBvbiBEVExTL0NvQVAgd2l0aCBhbiBpbmRpY2F0aW9u IHRoYXQgd2Ugd2lsbCBjaGVjazxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhIGNhbmRp ZGF0ZSBzb2x1dGlvbiBmb3Igc3VpdGFiaWxpdHkgd2l0aCBIVFRQL1RMUy48YnI+Jmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgKiBBZGRlZCB0ZXh0IHRvIGluZGljYXRlIHRoYXQgd2Ugd2lsbCBh bHNvIHZlcmlmeSB0aGUgc3VpdGFiaWxpdHkgb2Y8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsgdGhlIHNvbHV0aW9uIGZvciB1c2Ugd2l0aCBwcm90b2NvbCB0cmFuc2xhdGlvbiBwcm94aWVz Ljxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAqIFNpbXBsaWZpZWQgdGhlIHRhc2sgbGlz dCBieSByZW1vdmluZyBzb2x1dGlvbiBzcGVjaWZpYyBpdGVtcy48YnI+Jmd0OyZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsgKiBNZXJnZWQgc2V2ZXJhbCBpdGVtcyBvbiB0aGUgdGFzayBsaXN0ICh1c2Ug Y2FzZXMsIHJlcXVpcmVtZW50cyw8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYW5kIHBy b3RvY29sIGRlc2lnbiBndWlkZWxpbmVzKS4gRm9sbG93ZWQgdGhlIHN1Z2dlc3Rpb24gdG8gdXNl IG9mIGE8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgV2lraSBmb3IgY2FwdHVyaW5nIHRo b3NlLjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0OyBXaGF0IGRvIHlvdSB0aGluaz88YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgLS0tLS08YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgRHJhZnQgQ2hhcnRlciBWMC41 IC0gQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yPGJyPiZndDsmZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7IENvbnN0cmFpbmVkIEVudmlyb25tZW50IChBQ0UpPGJyPiZndDsmZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IFRoZSBJRVRGIGhh cyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gZW52aXJvbm1lbnRzPGJy PiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHdoZXJlIG5ldHdvcmsgbm9kZXMgYXJlIGxpbWl0 ZWQgaW4gQ1BVLCBtZW1vcnksIGFuZCBwb3dlci4gSXQgd2FzPGJyPiZndDsmZ3Q7ICZndDsgJmd0 OyZndDsmZ3Q7IG9ic2VydmVkIHRoYXQgSW50ZXJuZXQgcHJvdG9jb2xzIGNhbiBiZSBhcHBsaWVk IHRvIHRoZXNlIGNvbnN0cmFpbmVkPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGVudmly b25tZW50cywgb2Z0ZW4gb25seSByZXF1aXJpbmcgbWlub3IgdHdlYWtpbmcgYW5kIHByb2ZpbGlu Zy4gSW48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgb3RoZXIgY2FzZXMsIG5ldyBwcm90 b2NvbHMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gYWRkcmVzcyB0aGUgc3BlY2lmaWM8YnI+Jmd0OyZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsgcmVxdWlyZW1lbnRzIG9mIGNvbnN0cmFpbmVkIGRldmljZXMg YW5kIG5ldHdvcmtzLiBBbiBleGFtcGxlIG9mIHN1Y2g8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgYSBwcm90b2NvbCBpcyB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wg KENvQVApLjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBjb21wb25lbnRzPGJyPiZndDsm Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEFzIGluIG90aGVyIGVudmlyb25tZW50cywgYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gcXVlc3Rpb248YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgYWxzbyBhcmlzZSBpbiBlbnZpcm9ubWVudHMgd2l0aCBjb25zdHJhaW5lZCBub2RlcyBh bmQgbmV0d29ya3MuIEZvcjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBleGFtcGxlLCBh IGRvb3IgbG9jayBoYXMgdG8gYXV0aG9yaXplIHRoZSBwZXJzb24gc2Vla2luZyBhY2Nlc3M8YnI+ Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdXNpbmcgYSAiZGlnaXRhbCBrZXkiLiBXaGVyZSBh cmUgdGhlIGF1dGhvcml6YXRpb24gZGVjaXNpb25zIHN0b3JlZD88YnI+Jmd0OyZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsgSG93IGRvZXMgdGhlIGRpZ2l0YWwga2V5IGNvbW11bmljYXRlIHdpdGggdGhl IGxvY2s/IERvZXMgdGhlIGxvY2s8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgaW50ZXJh Y3Qgd2l0aCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBvYnRhaW4gYXV0aG9yaXphdGlvbjxi cj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbj8gSG93IGNhbiBhY2Nlc3Mg YmUgZ3JhbnRlZCB0byBvdGhlciBwZXJzb25zIHRlbXBvcmFyaWx5Pzxicj4mZ3Q7Jmd0OyAmZ3Q7 IEhvdyBjYW4gYWNjZXNzIGJlIHJldm9rZWQ/PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IFRoZXNlIHR5cGVzIG9mIHF1ZXN0aW9ucyBoYXZlIGJlZW4gYW5zd2VyZWQgYnkgZXhpc3Rpbmcg cHJvdG9jb2xzPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGZvciB1c2UgY2FzZXMgb3V0 c2lkZSB0aGUgY29uc3RyYWluZWQgZW52aXJvbm1lbnQuIEJ1dCBpbjxicj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCwgYWRkaXRpb25hbCByZXF1aXJl bWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvcjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyB0 aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHkgcHJvdG9jb2xzLjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGUgSUVURiBoYXMgYSBs b25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZSBwYXJ0eSBhdXRoZW50aWNhdGlvbjxicj4m Z3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9y IGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXM8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsgaW5jbHVkZSBLZXJiZXJvcywgdGhlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUg KFBLSSksIHRoZTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBBdXRoZW50aWNhdGlvbiwg QXV0aG9yaXphdGlvbiwgYW5kIEFjY291bnRpbmcgKEFBQSkgaW5mcmFzdHJ1Y3R1cmUsPGJyPiZn dDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGFuZCB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9j b2wgKE9BdXRoKS4gQWxsIHRoZXNlIHByb3RvY29sczxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyBlbmpveSB3aWRlc3ByZWFkIGRlcGxveW1lbnQgb24gdGhlIEludGVybmV0LiBBbHRob3Vn aCB0aGV5IGFsbCBhaW08YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdG8gc29sdmUgYSBz aW1pbGFyIGdvYWwsIGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRlPGJyPiZn dDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kIHV0aWxpemUg ZGlmZmVyZW50IG1lc3NhZ2UgZXhjaGFuZ2VzLiBUaGVzZTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0OyBkaWZmZXJlbmNlcyBhcmUgbW90aXZhdGVkIGJ5IHRoZSBtYWluIGRlcGxveW1lbnQg dXNlIGNhc2VzIHRoZXkgd2VyZTxicj4mZ3Q7Jmd0OyAmZ3Q7IGRlc2lnbmVkIGZvci48YnI+Jmd0 OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgUmVx dWlyZW1lbnRzIGRlcml2ZWQgZnJvbSB1c2UgY2FzZXMgaW5kaWNhdGUgdGhlIHN1aXRhYmlsaXR5 IG9mPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGFscmVhZHkgZXhpc3Rpbmcgd29yaywg c3VjaCBhcyBPQXV0aCwgYXMgYSBzb2x1dGlvbiBmb3IgY29uc3RyYWluZWQ8YnI+Jmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgZW52aXJvbm1lbnRzLiBUaGVzZSBwcm90b2NvbHMgd2VyZSwgaG93 ZXZlciwgbm90IG9wdGltaXplZCBmb3I8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgY29u c3RyYWluZWQgZW52aXJvbm1lbnRzLiBBZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IG5lZWQg dG8gYmU8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGFrZW4gaW50byBhY2NvdW50IGFy ZSB0aGUgbGFjayBvZiBhIHN1aXRhYmxlIHVzZXItaW50ZXJmYWNlIGZvcjxicj4mZ3Q7Jmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyBvYnRhaW5pbmcgdGhlIGNvbnNlbnQgb2YgdGhlIHVzZXIgYW5kIHRo ZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQ8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgZGV2 aWNlcyB0byBjb250YWN0IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGluIHJlYWwtdGltZSB3aXRo IGV2ZXJ5PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGFjY2VzcyByZXF1ZXN0IGR1ZSB0 byBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LCBldGMuPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IFRoaXMgd29ya2luZyBncm91cCB0 aGVyZWZvcmUgYWltcyBmb3IgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZm9yPGJyPiZndDsmZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHRvIGVu YWJsZSBhdXRob3JpemVkIGFjY2VzcyB0bzxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBy ZXNvdXJjZXMgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBBcyBhIHN0YXJ0aW5nIHBvaW50 LCB0aGU8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgd29ya2luZyBncm91cCB3aWxsIGFz c3VtZSB0aGF0IGFjY2VzcyB0byByZXNvdXJjZXMgb2ZmZXJlZCBieSBhPGJyPiZndDsmZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7IHJlc291cmNlIHNlcnZlciBieSBhIGNsaWVudCBkZXZpY2VzIHRha2Vz IHBsYWNlIHVzaW5nIENvQVAgYW5kIGlzIHByb3RlY3RlZDxicj4mZ3Q7Jmd0OyAmZ3Q7IGJ5IERU TFMuPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEJvdGggcmVzb3VyY2Ugc2VydmVyIGFu ZCBjbGllbnQgbWF5IGJlIHJlc291cmNlIGNvbnN0cmFpbnQuIFRoaXM8YnI+Jmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgYWNjZXNzIHdpbGwgYmUgbWVkaWF0ZWQgYnkgYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXIsIHdoaWNoIGRvZXMgbm90PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHN1 ZmZlciBmcm9tIHRoZSBzYW1lIHJlc291cmNlIGxpbWl0YXRpb25zLjxicj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBFeGlzdGluZyBhdXRo ZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgYXJlIHVzZWQgYW5kPGJyPiZn dDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHJlLWFwcGxpZWQgZm9yIHVzZSB3aXRoIGNvbnN0cmFp bmVkIGRldmljZXMsIHdoZXJlIGFwcGxpY2FibGUuIFRoaXM8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsgcmVxdWlyZXMgcmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMgdG8gYmUgcmV2aWV3ZWQg Zm9yIHN1aXRhYmlsaXR5LDxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBzZWxlY3Rpbmcg YSBzdWJzZXQgb2YgdGhlbSwgcmVzdHJpY3RpbmcgdGhlIG9wdGlvbnMgd2l0aGluIGVhY2ggb2Y8 YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhlIHNwZWNpZmljYXRpb25zLiBTb21lIGZ1 bmN0aW9uYWxpdGllcyBtYXksIGhvd2V2ZXIsIG5vdCBiZTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0OyBhdmFpbGFibGUgaW4gZXhpc3RpbmcgcHJvdG9jb2xzIGFuZCBmb3IgdGhvc2UgY2Fz ZXMgbmV3PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGZ1bmN0aW9uYWxpdHkgaGFzIHRv IGJlIHN0YW5kYXJkaXplZC4gVGh1cywgZXhpc3Rpbmcgd29yayBjYW4gYmU8YnI+Jmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgbGV2ZXJhZ2VkIGFuZCB0aGUgZ3JvdXAgYmVuZWZpdHMgZnJvbSBh dmFpbGFibGUgc2VjdXJpdHkgYW5hbHlzaXMsPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IGltcGxlbWVudGF0aW9uLCBhbmQgZGVwbG95bWVudCBleHBlcmllbmNlLiBNb3Jlb3ZlciwgYSBz dGFuZGFyZGl6ZWQ8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgc29sdXRpb24gZm9yIGZl ZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB3aWxsIGhlbHAgdG88YnI+ Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgc3RpbXVsYXRlIHRoZSBkZXBsb3ltZW50IG9mIElv VCBkZXZpY2VzIG9mZmVyaW5nIGluY3JlYXNlZCBzZWN1cml0eS48YnI+Jmd0OyZndDsgJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgT25jZSBwcm9ncmVzcyBp biBpZGVudGlmeWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuPGJyPiZn dDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IG1hZGUgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB2ZXJp Znkgd2hldGhlciB0aGUgc2FtZSBtZWNoYW5pc20gYXJlPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IGFsc28gYXBwbGljYWJsZSBiZXlvbmQgdGhlIHVzZSBvZiBDb0FQIGFuZCBEVExTLiBJ biBwYXJ0aWN1bGFyLCB0aGU8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYWJpbGl0eSB0 byB1c2UgdGhlIGRldmVsb3BlZCBzb2x1dGlvbiBvdmVyIEhUVFAgYW5kIFRMUyB3aWxsIGJlPGJy PiZndDsmZ3Q7ICZndDsgaW52ZXN0aWdhdGVkLjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyBGdXJ0aGVybW9yZSwgdG8gZ3VhcmFudGVlIHNtb290aCB0cmFuc2l0aW9uIHRoZSBpbnRlZ3Jh dGlvbiB3aXRoPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGV4aXN0aW5nIGRlcGxveW1l bnQgd2lsbCBiZSBzdHVkaWVkLiBUaGlzIHBhcnRpY3VsYXJseSBjb25jZXJucyB0aGU8YnI+Jmd0 OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdXNlIG9mIHByb3RvY29sIHRyYW5zbGF0aW9uIHByb3hp ZXMuPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IFRvIGJlIHN1Y2Nlc3NmdWwgdGhpcyB3b3JraW5nIGdyb3VwIHJlcXVpcmVzIGV4cGVy dGlzZSBpbiBzZWN1cml0eSw8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgcHJpdmFjeSwg YW5kIGEgZ29vZCB1bmRlcnN0YW5kaW5nIG9mIHVzYWJpbGl0eSBpbiB0aGUgY29uc3RyYWluZWQ8 YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgZW52aXJvbm1lbnQgc3BhY2UuIFRoaXMgd29y ayBkb2VzIG5vdCBtYWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlPGJyPiZndDsmZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7IHBhcnR5IG9mZmVyaW5nIGFwcGxpY2F0aW9uIGxheWVyIHNlcnZpY2VzIGlz IGFsd2F5cyB0aGUgc2FtZSBwYXJ0eTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBvZmZl cmluZyBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlcy48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRo ZSBmb2xsb3dpbmcgdGFza3MgKGluIHRoaXMgb3JkZXIpOjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAxKSBUaGUgd29ya2luZyBncm91 cCBXaWtpIHBhZ2VzIHdpbGwgYmUgdXNlZCB0byBkb2N1bWVudCB1c2UgY2FzZXMsPGJyPiZndDsm Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50cywgYW5kIHByb3RvY29sIGRlc2lnbiBj cml0ZXJpYS4gVGhpcyB3b3JrIHdpbGwgZ3VpZGUgdGhlPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3RvY29sIG1lY2hhbmlzbXMuPGJy PiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IDIpIFNlbGVjdGlvbiBvZiBhbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90 b2NvbCBmb3I8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgY29uc3RyYWluZWQgZW52aXJv bm1lbnRzLjxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyAzKSBFdmFsdWF0aW9uIG9mIHRoZSBjYW5kaWRhdGUgc29sdXRpb24gZm9yIHVz ZSB3aXRoIEhUVFAvVExTIGFuZDxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBwcm94eSBk ZXBsb3ltZW50cy48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgLS0tLS08YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgQ2lhbzxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyBIYW5uZXM8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsgJmx0O3NpZ25hdHVyZS5hc2MmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgQWNl IG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBBY2VAaWV0Zi5vcmc8 YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2U8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7 ICZndDsmZ3Q7IFphY2ggU2hlbGJ5PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgRGlyZWN0b3Ig b2YgVGVjaG5vbG9neTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IEFSTSBJbnRlcm5ldCBvZiBU aGluZ3MgQlU8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyB3d3cuYXJtLmNvbTxicj4mZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7IG1vYmlsZTogKzEgKDQwOCkgMjAzLTk0MzQ8YnI+Jmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyBTa3lwZTogemRzaGVsYnk8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBMaW5r ZWRJbjogZmkubGlua2VkaW4uY29tL2luL3phY2hzaGVsYnkvPGJyPiZndDsmZ3Q7ICZndDsgJmd0 OyZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7 IC0tIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHM8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGU8YnI+Jmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsIG9yPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4mbmJzcDsgVGhhbmsgeW91Ljxicj4mZ3Q7Jmd0OyAmZ3Q7ICZn dDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgQVJNIExpbWl0ZWQsIFJlZ2lzdGVyZWQg b2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiw8YnI+Jmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMsIENvbXBhbnkg Tm86Jm5ic3A7IDI1NTc1OTAgQVJNIEhvbGRpbmdzIHBsYyw8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7 Jmd0OyBSZWdpc3RlcmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5 TkosIFJlZ2lzdGVyZWQgaW48YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBFbmdsYW5kICZhbXA7 IFdhbGVzLCBDb21wYW55IE5vOiZuYnNwOyAyNTQ4NzgyPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyZn dDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IEFjZSBtYWlsaW5n IGxpc3Q8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBBY2VAaWV0Zi5vcmc8YnI+Jmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTxi cj4mZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBB Y2UgbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7ICZndDsgJmd0OyBBY2VAaWV0Zi5vcmc8YnI+Jmd0 OyZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNl PGJyPiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBBY2UgbWFp bGluZyBsaXN0PGJyPiZndDsmZ3Q7IEFjZUBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4mZ3Q7Jmd0OyBBY2UgbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEFj ZUBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FjZTxicj4mZ3Q7PGJyPiZndDsgJmx0O3NtaW1lLnA3cyZndDtfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IEFjZSBtYWlsaW5nIGxpc3Q8 YnI+Jmd0OyBBY2VAaWV0Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FjZTxicj48YnI+WmFjaCBTaGVsYnk8YnI+RGlyZWN0b3Igb2YgVGVjaG5vbG9n eTxicj5BUk0gSW50ZXJuZXQgb2YgVGhpbmdzIEJVPGJyPnd3dy5hcm0uY29tPGJyPm1vYmlsZTog KzEgKDQwOCkgMjAzLTk0MzQ8YnI+U2t5cGU6IHpkc2hlbGJ5PGJyPkxpbmtlZEluOiBmaS5saW5r ZWRpbi5jb20vaW4vemFjaHNoZWxieS88YnI+PGJyPjxicj4tLSBJTVBPUlRBTlQgTk9USUNFOiBU aGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl bnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg ZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQg Zm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg bWVkaXVtLiZuYnNwOyBUaGFuayB5b3UuPGJyPjxicj5BUk0gTGltaXRlZCwgUmVnaXN0ZXJlZCBv ZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRnZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgJmFtcDsgV2FsZXMsIENvbXBhbnkgTm86Jm5ic3A7IDI1NTc1OTA8YnI+QVJNIEhv bGRpbmdzIHBsYywgUmVnaXN0ZXJlZCBvZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRn ZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMsIENvbXBhbnkgTm86 Jm5ic3A7IDI1NDg3ODI8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+QWNlIG1haWxpbmcgbGlzdDxicj5BY2VAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8YnI+PC9ib2R5Pg== ----_com.android.email_809215972640270-- From nobody Tue Mar 18 20:19:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA91A0350 for ; Tue, 18 Mar 2014 20:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8Snh4_uNIo0 for ; Tue, 18 Mar 2014 20:19:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 530181A034F for ; Tue, 18 Mar 2014 20:19:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BES16648; Wed, 19 Mar 2014 03:19:33 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 03:19:21 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 03:19:32 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 19 Mar 2014 11:19:28 +0800 From: Likepeng To: Rafa Marin Lopez , "ace@ietf.org" Thread-Topic: [Ace] ACE Charter Proposal v0.6 Thread-Index: AQHPPrnTmdQyDUaRoUK9ubnDoEoVXJrlGNIP//+rHYCAAZNKAIABbG8g Date: Wed, 19 Mar 2014 03:19:27 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0742C@SZXEMA501-MBS.china.huawei.com> References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/nyfUp5osVvBLFk6FX5JN57RovSg Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 03:19:45 -0000 PiBBcyBwYXJ0IG9mIGEgcmVzZWFyY2ggYWN0aXZpdHkgaGVyZSBhdCB0aGUgVW5pdmVyc2l0eSBv ZiBNdXJjaWEsIHdlIGNyZWF0ZWQgYW4NCj4gaW5pdGlhbCBkZXNpZ24gb2YgYW4gYXV0aGVudGlj YXRpb24gc2VydmljZSBiYXNlZCBvbiBFQVAgZm9yIENvQVAgc29tZXRpbWUNCj4gYWdvLg0KDQpJ dCBpcyB2ZXJ5IGdvb2QgdG8gc2VlIGVhcmx5IGltcGxlbWVudGF0aW9ucyBpbiB0aGlzIHNwYWNl Lg0KDQo+IEkgZ3Vlc3MgdGhpcyBjb3VsZCBiZSBhbHNvIGNhdGVnb3JpemVkIGFzIGFuIEVBUC1i YXNlZCBhcHByb2FjaCwgdGhvdWdoIHdlIGRvDQo+IG5vdCBrbm93IGlmIGl0IHdpbGwgYmUgaW50 ZXJlc3RpbmcgZm9yIEFDRSBtZW1iZXJzLiBJZiBwZW9wbGUgdGhpbmsgaXQgaXMsIHdlIGNhbg0K PiBwcmVwYXJlIGEgc2hvcnQgSS1EIGV4cGxhaW5pbmcgd2hhdCB3ZSBoYXZlIHVudGlsIG5vdy4N Cg0KU3VyZSwgSS1EIGlzIGFsd2F5cyB3ZWxjb21lLiBJdCBpcyBiZW5lZmljaWFsIHRvIG91ciB3 b3JrLg0KDQpUaGFua3MsDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+ILeivP7IyzogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g UmFmYSBNYXJpbiBMb3Bleg0KPiC3osvNyrG85DogMjAxNMTqM9TCMTjI1SAyMToyNQ0KPiDK1bz+ yMs6IGFjZUBpZXRmLm9yZw0KPiDW98ziOiBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9zYWwg djAuNg0KPiANCj4gSGkgTWFyZ2FyZXQsIGFsbA0KPiANCj4gPiBEZXBlbmRpbmcgb24gd2hhdCB5 b3UgbWVhbiBoZXJlLCBJIG1pZ2h0IG9yIG1pZ2h0IG5vdCBhZ3JlZaGtDQo+ID4NCj4gPiBGb3Ig aW5zdGFuY2UsIGlmIHdlIGRlY2lkZSB0aGF0IGFuIEVBUC1iYXNlZCBhcHByb2FjaCBjb3VsZCB3 b3JrIGluDQo+ID4gdGhpcyBlbnZpcm9ubWVudA0KPiANCj4gQXMgcGFydCBvZiBhIHJlc2VhcmNo IGFjdGl2aXR5IGhlcmUgYXQgdGhlIFVuaXZlcnNpdHkgb2YgTXVyY2lhLCB3ZSBjcmVhdGVkIGFu DQo+IGluaXRpYWwgZGVzaWduIG9mIGFuIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2UgYmFzZWQgb24g RUFQIGZvciBDb0FQIHNvbWV0aW1lDQo+IGFnby4gSW4gb3RoZXIgd29yZHMsIENvQVAgbWVzc2Fn ZXMgYXJlIHVzZWQgdG8gdHJhbnNwb3J0IEVBUCBiZXR3ZWVuIHRoZQ0KPiBDb0FQIGNsaWVudCAo RUFQIGF1dGhlbnRpY2F0b3IpIGFuZCB0aGUgQ29BUCBzZXJ2ZXIgKEVBUCBwZWVyLyB0aGUNCj4g Y29uc3RyYWluZWQgbm9kZSkuIEluIHBhcnRpY3VsYXIsIHRoZSBFQVAgbWVzc2FnZXMgYXJlIGRp cmVjdGx5IHRyYW5zcG9ydGVkIGluDQo+IHRoZSBDb0FQIG1lc3NhZ2UgcGF5bG9hZCBmb3IgdGhp cyBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlLiAgSW4gdGhpcyBjYXNlLCB0aGUNCj4gRUFQIGF1dGhl bnRpY2F0b3IgKENvQVAgY2xpZW50KSBjYW4gY29udGFjdCBhbiBleHRlcm5hbCBBQUEgc2VydmVy ICh3aGljaCBpcw0KPiBvbmUgb2YgdGhlIHBvc2libGUgY2hvaWNlcyBpbiBBQ0UsIGFzIGZhciBh cyBJIGhhdmUgcmVhZCkuDQo+IA0KPiBPbmNlIEVBUCBoYXMgZmluaXNoZWQsIHdlIGJvb3RzdHJh cCBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIGJldHdlZW4gQ29BUA0KPiBzZXJ2ZXIgYW5kIENvQVAg Y2xpZW50IGJhc2VkIG9uIHRoZSBNU0suIEluIG91ciBjYXNlLCB0aGlzIHNlY3VyaXR5IGFzc29j aWF0aW9uDQo+IG1pZ2h0IGJlIGJhc2VkIG9uIERUTFMgb3IgYnkgdXNpbmcgYSBuZXcgQVVUSCBv cHRpb24gd2UgaGF2ZSBkZWZpbmVkIHRvIGJlDQo+IGluY2x1ZGVkIGluIGFueSBDb0FQIG1lc3Nh Z2UgKG5vIG5lZWQgb2YgRFRMUyBpbiB0aGUgc2Vjb25kIGNhc2UpLg0KPiANCj4gV2UgaGF2ZSBy ZXN0YXJ0ZWQgdGhlIHdvcmsgc29tZSBtb250aHMgYWdvIGFuZCB3ZSBoYXZlIG5vdyBhIHZlcnkg bGltaXRlZA0KPiBwcm9vZi1vZi1jb25jZXB0IHdpdGggbGliY29hcC4gSXQgaXMgc3RpbGwgaW4g UEMgcGxhdGZvcm0gYnV0IHdlIGhhdmUgc3RhcnRlZCB0bw0KPiBidWlsZCB0aGUgaW1wbGVtZW50 YXRpb24gaW4gQ09PSkEgc2ltdWxhdG9yICh3aXRob3V0IERUTFMgc28gZmFyKS4NCj4gTmV2ZXJ0 aGVsZXNzLCBvdXIgaW50ZW50aW9uIGlzIGFsc28gdG8gdGVzdCBpdCB3aXRoIERUTFMuDQo+IA0K PiBJIGd1ZXNzIHRoaXMgY291bGQgYmUgYWxzbyBjYXRlZ29yaXplZCBhcyBhbiBFQVAtYmFzZWQg YXBwcm9hY2gsIHRob3VnaCB3ZSBkbw0KPiBub3Qga25vdyBpZiBpdCB3aWxsIGJlIGludGVyZXN0 aW5nIGZvciBBQ0UgbWVtYmVycy4gSWYgcGVvcGxlIHRoaW5rIGl0IGlzLCB3ZSBjYW4NCj4gcHJl cGFyZSBhIHNob3J0IEktRCBleHBsYWluaW5nIHdoYXQgd2UgaGF2ZSB1bnRpbCBub3cuDQo+IA0K PiA+IChhcyBpdCBkb2VzIGZvciBldmVyeSB3aS1maSBkZXZpY2UgdGhhdCBuZWVkcyB0byBqb2lu IGFuIDgwMi4xMXgtc2VjdXJlZA0KPiBuZXR3b3JrKSwgSSB0aGluayB3ZSBtaWdodCB3YW50IHRv IGRlZmluZSBhbiBFQVAgbWV0aG9kIHRoYXQgbGV2ZXJhZ2VzIHRoZQ0KPiBleGlzdGluZyBjcnlw dG8gYWxnb3JpdGhtcyBhbmQgc2VjdXJpdHkgcHJvdG9jb2xzIGF2YWlsYWJsZSBvbiB0aGUgY29u c3RyYWluZWQNCj4gZGV2aWNlLCBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBkZXZp Y2Ugd2lsbCBhbHNvIGltcGxlbWVudCBhDQo+IGNvbnN0cmFpbmVkIHZlcnNpb24gb2YgRFRMUyAo YXMgZGVmaW5lZCBieSB0aGUgRElDRSBXRykuDQo+IA0KPiBJbiBvdXIgY2FzZSB3ZSBoYXZlIHRl c3RlZCBFQVAtUFNLIHNpbmNlIGl0IHVzZXMgQUVTLWJhc2VkIGNyeXB0b2dyYXBoeS4gSW4NCj4g ZmFjdCwgd2UgaGF2ZSBwcmV2aW91cyBleHBlcmllbmNlIG9uIHRoYXQgaW4gcmVhbCBjb25zdHJh aW5lZCBkZXZpY2VzDQo+IChQQU5BVElLSTogQSBOZXR3b3JrIEFjY2VzcyBDb250cm9sIEltcGxl bWVudGF0aW9uIEJhc2VkIG9uIFBBTkEgZm9yIElvVA0KPiBEZXZpY2VzIGh0dHA6Ly93d3cubWRw aS5jb20vMTQyNC04MjIwLzEzLzExLzE0ODg4KS4gQnV0IEkgYWdyZWUgdGhhdCBpZg0KPiB3ZSBh c3N1bWUgRFRMUyB3ZSBtYXkgYXNzdW1lIHRoYXQgYW4gRUFQLVRMUyBtZXRob2Qgd291bGQgYmUN Cj4gcmVhc29uYWJsZS4gTmV2ZXJ0aGVsZXNzLCBJIGFncmVlIHdpdGggUm9iZXJ0IHRoYXQgd2Ug bWF5IG5vdCBuZWVkIHRvIGRlc2lnbg0KPiBhIG5ldyBFQVAgbWV0aG9kIGZvciB0aGF0Lg0KPiAN Cj4gSnVzdCBteSAwLjAyIGNlbnRzLg0KPiANCj4gPiAgV2hlcmUgd291bGQgdGhhdCBmYWxsIGlu IHlvdXIgdmlldyBvZiB0aGUgd29ybGQ/ICBJIGRvbid0IHRoaW5rIGl0IHdvdWxkIGJlDQo+IGEg RnJhbmtlbnByb3RvY29sIGF0IGFsbCwgc2luY2UgRUFQIGlzIGRlc2lnbmVkIHRvIGJlIGV4dGVu ZGVkIHRoYXQgd2F5Lg0KPiBUaGVyZSBhbHNvIHdvdWxkbid0IGJlIG11Y2ggbmV3IHByb3RvY29s IHdvcmssIGFzIGFuIEVBUC1EVExTIG1ldGhvZA0KPiBjb3VsZCBiZSBwcmV0dHkgc2ltaWxhciB0 byB0aGUgZXhpc3RpbmcgRUFQLVRMUyBtZXRob2QuICBBc3N1bWluZyBzb21ldGhpbmcNCj4gbGlr ZSB0aGF0IGNvdWxkIG1lZXQgb3VyIGFzLXlldC11bmRldGVybWluZWQgcmVxdWlyZW1lbnRzIGZv ciB0aGlzDQo+IGVudmlyb25tZW50LCB3b3VsZCB5b3UgY29uc2lkZXIgdGhhdCB0byBiZSBhIHN1 Y2Nlc3NmdWwgb3V0Y29tZT8NCj4gPg0KPiA+IE1hcmdhcmV0DQo+ID4NCj4gPg0KPiA+DQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IEFjZSBtYWlsaW5nIGxpc3QNCj4gPiBBY2VAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBSYWZhZWwgTWFyaW4gTG9wZXosIFBo RA0KPiBEZXB0LiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcgKERJ SUMpIEZhY3VsdHkgb2YNCj4gQ29tcHV0ZXIgU2NpZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYQ0K PiAzMDEwMCBNdXJjaWEgLSBTcGFpbg0KPiBUZWxmOiArMzQ4Njg4ODg1MDEgRmF4OiArMzQ4Njg4 ODQxNTEgZS1tYWlsOiByYWZhQHVtLmVzDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFjZSBtYWlsaW5nIGxpc3QN Cj4gQWNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWNlDQo= From nobody Wed Mar 19 01:46:43 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD051A04B4 for ; Wed, 19 Mar 2014 01:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k0T3sojho_c for ; Wed, 19 Mar 2014 01:46:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 250801A065C for ; Wed, 19 Mar 2014 01:46:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BES41369; Wed, 19 Mar 2014 08:46:30 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 08:46:08 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 08:46:19 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 19 Mar 2014 16:46:08 +0800 From: Likepeng To: Margaret Wasserman , Carsten Bormann Thread-Topic: [Ace] ACE Charter Proposal v0.6 Thread-Index: AQHPPrnTmdQyDUaRoUK9ubnDoEoVXJrlGNIP//+rHYCAA1rosA== Date: Wed, 19 Mar 2014 08:46:07 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0757C@SZXEMA501-MBS.china.huawei.com> References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> In-Reply-To: <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/q1H0FKJ7_dn0EYkAOy7z9IvhNdQ Cc: Bert Greevenbosch , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 08:46:42 -0000 Pj4+IDIpIElkZW50aWZ5IHN1aXRhYmxlIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9u IG1lY2hhbmlzbXMsIGluIHBhcnRpY3VsYXIgYWRkcmVzc2luZyBkeW5hbWljIGFuZCBmaW5lIGdy YWluZWQgYWNjZXNzIGNvbnRyb2wgc3VpdGFibGUgZm9yIENvQVAgcmVzb3VyY2UgYWNjZXNzIHJl cXVlc3RzIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCg0KPiBJIHRoaW5rIHRoaXMgZ29l cyB0b28gZmFyIGludG8gdGhlIHJlcXVpcmVtZW50cyBzcGFjZaGtICANCg0KTGV0J3Mgc2ltcGxp ZnkgdGhhdCBhIGxpdHRsZSBiaXQuIEhvdyBhYm91dCB0aGlzOg0KDQpJZGVudGlmeSBzdWl0YWJs ZSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIHN1aXRhYmxlIGZv ciByZXNvdXJjZSBhY2Nlc3MgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQpLaW5kIFJl Z2FyZHMNCktlcGVuZw0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEFjZSBbbWFp bHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE1hcmdhcmV0IFdhc3Nlcm1hbg0KPiC3osvN yrG85DogMjAxNMTqM9TCMTfI1SAyMToyMQ0KPiDK1bz+yMs6IENhcnN0ZW4gQm9ybWFubg0KPiCz rcvNOiBCZXJ0IEdyZWV2ZW5ib3NjaDsgSGFubmVzIFRzY2hvZmVuaWc7IGFjZUBpZXRmLm9yZw0K PiDW98ziOiBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9zYWwgdjAuNg0KPiANCj4gDQo+IEhp IENhcnN0ZW4sDQo+IA0KPiBPbiBNYXIgMTcsIDIwMTQsIGF0IDY6MjMgQU0sIENhcnN0ZW4gQm9y bWFubiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCj4gDQo+ID4gT24gMTcgTWFyIDIwMTQsIGF0IDEw OjMwLCBCZXJ0IEdyZWV2ZW5ib3NjaA0KPiA8QmVydC5HcmVldmVuYm9zY2hAaHVhd2VpLmNvbT4g d3JvdGU6DQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhlcmUgaXMgbW9yZSB0byBpdCB0aGFuICJzZWxl Y3Rpb24iLCBlc3BlY2lhbGx5IHNpbmNlIHdlIG1heSBuZWVkIHRvDQo+IG1ha2Ugc29tZSBhZGp1 c3RtZW50cyBvciBkZWZpbmUgc29tZXRoaW5nIG5ldyBmb3IgdGhlIGNvbnN0cmFpbmVkIGNhc2Uu DQo+ID4NCj4gPiBJbmRlZWQuDQo+IA0KPiBJIGFncmVlIHdpdGggdGhpcywgdG9vLiAgSSB0aGlu ayB0aGUgY2hhcnRlciBzaG91bGQgYmUgb3BlbiB0byBwcm9maWxpbmcsDQo+IGFkanVzdGluZyBv ciBleHRlbmRpbmcgZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcyB0byBtZWV0IHRoZSBuZWVk cyBvZiB0aGlzDQo+IGVudmlyb25tZW50Lg0KPiANCj4gPj4+IDIpIElkZW50aWZ5IHN1aXRhYmxl IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG1lY2hhbmlzbXMsIGluDQo+IHBhcnRp Y3VsYXIgYWRkcmVzc2luZyBkeW5hbWljIGFuZCBmaW5lIGdyYWluZWQgYWNjZXNzIGNvbnRyb2wg c3VpdGFibGUgZm9yDQo+IENvQVAgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3RzIGluIGNvbnN0cmFp bmVkIGVudmlyb25tZW50cy4NCj4gPj4NCj4gPj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+IA0KPiBJ IHRoaW5rIHRoaXMgZ29lcyB0b28gZmFyIGludG8gdGhlIHJlcXVpcmVtZW50cyBzcGFjZaGtICBJ IHRoaW5rIHdlIGFyZSBwbGFubmluZw0KPiB0byBkZWZpbmUgdGhlIHJlcXVpcmVtZW50cyBhbmQg YXJjaGl0ZWN0dXJlIGFzIHBhcnQgb2YgdGhlIGNoYXJ0ZXIsIGFuZCBJIHRoaW5rDQo+IHRoYXQg b25lIGFyZWEgdGhhdCBuZWVkcyBhIGxvdCBvZiBkaXNjdXNzaW9uIGlzIHdoYXQgb3VyIHJlcXVp cmVtZW50cyBhcmUgZm9yDQo+IGFjY2VzcyBjb250cm9sLCBhbmQgd2hhdCByb2xlcyB0aGUgUlMg YW5kIEFTIHdpbGwgcGxheSBpbiB0aGF0LiAgRm9yIGluc3RhbmNlLA0KPiB3ZSBtaWdodCBkZWNp ZGUgdGhhdCB3ZSB3YW50IGFuIGF0dHJpYnV0ZSBvciByb2xlLWJhc2VkIHN5c3RlbSB3aGVyZSB0 aGUNCj4gYXV0aGVudGljYXRpb24gcHJvY2VzcyByZXR1cm5zIHZhcmlvdXMgYXR0cmlidXRlcyBh bmQvb3Igcm9sZXMgYXNzb2NpYXRlZCB3aXRoDQo+IHRoZSBhdXRoZW50aWNhdGVkIHVzZXIsIGFu ZCB0aGF0IGluZm9ybWF0aW9uIGlzIHVzZWQgYnkgdGhlIFJTIHRvIGRldGVybWluZQ0KPiB3aGF0 IGFjY2VzcyBzaG91bGQgYmUgYWxsb3dlZC4gIEluIHRoYXQgY2FzZSwgdGhlIGdyYW51bGFyaXR5 IG9mIHRoZSBhY2Nlc3MNCj4gY29udHJvbCBjb3VsZCBiZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBh bmQgd291bGQgYmUgYSBtYXR0ZXIgb2YgQVMNCj4gY29uZmlndXJhdGlvbiBhbmQgbG9jYWwgaW1w bGVtZW50YXRpb24gb24gdGhlIFJTLg0KPiANCj4gSSB3YW50IG91ciBjaGFydGVyIHRvIGxlYW4g X3N0cm9uZ2x5XyBpbiB0aGUgZGlyZWN0aW9uIG9mIHByZWZlcnJpbmcgYSBzb2x1dGlvbg0KPiB0 aGF0IGlzIGJhc2VkIG9uIGV4aXN0aW5nIHNlY3VyaXR5IHByb3RvY29sIHN0YW5kYXJkcywgdW5s ZXNzL3VudGlsIHdlIGNhbg0KPiBkZXRlcm1pbmUgdGhhdCBub25lIG9mIHRoZW0gY2FuIG1lZXQg dGhlIHJlcXVpcmVtZW50cywgZXZlbiB3aXRoDQo+IGFwcHJvcHJpYXRlIHByb2ZpbGVzLCBleHRl bnNpb25zIG9yIG1vZGlmaWNhdGlvbnMuICBJIHRoaW5rIHRoYXQgaXMgcHJldHR5DQo+IHVubGlr ZWx5IGJhc2VkIG9uIHRoZSBicmVhZHRoIGFuZCB2YXJpZXR5IG9mIGV4aXN0aW5nIHNlY3VyaXR5 IHByb3RvY29scy4gIEkNCj4gdGhpbmsgd2Ugc2hvdWxkIHJlcXVpcmUgYSByZWNoYXJ0ZXIgdG8g dW5kZXJ0YWtlIGRldmVsb3BtZW50IG9mIGEgbmV3DQo+IHNlY3VyaXR5IHByb3RvY29sLg0KPiAN Cj4gU28sIEkgd291bGQgcHJvcG9zZSBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPiANCj4gMikgU2Vs ZWN0aW9uIG9mIGFuIGV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHBy b3RvY29sIHRoYXQgY2FuDQo+IHNlcnZlIGFzIHRoZSBiYXNpcyBvZiBhbiBhdXRoZW50aWNhdGlv biBhbmQgYXV0aG9yaXphdGlvbiBzeXN0ZW0gZm9yDQo+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50 cy4NCj4gDQo+IDMpIERlZmluaXRpb24gb2Ygd2hhdGV2ZXIgcHJvZmlsZXMsIGV4dGVuc2lvbnMg b3IgbW9kaWZpY2F0aW9ucyBhcmUgcmVxdWlyZWQgdG8NCj4gbWFrZSB0aGUgc2VsZWN0ZWQgYXV0 aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgc3VpdGFibGUgZm9yDQo+IGNv bnN0cmFpbmVkIGVudmlyb25tZW50cy4NCj4gDQo+ID4gV2UgY2FuIHRyeSB0byB3ZWFzZWwgYXJv dW5kIHRoaXMsIGJ1dCBpZiB0aGlzIGdyb3VwIGlzIHN1Y2Nlc3NmdWwsIHRoZSByZXN1bHQNCj4g d2lsbCBiZSB0aGUgZGVmaW5pdGlvbiBvZiBjZXJ0YWluIG5ldyBwcm90b2NvbCBjb21wb25lbnRz Lg0KPiA+IFJldXNpbmcgZXhpc3RpbmcgbWVjaGFuaXNtcywgKGFic3RyYWN0KSBwcm90b2NvbHMs IG9yIGV2ZW4gZW5jb2RpbmdzIGFzDQo+IG11Y2ggYXMgcG9zc2libGUgaXMgZGVzaXJhYmxlLCBi dXQgdGhlcmUgYWxzbyBpcyBhbiBvYmplY3RpdmUgdG8gYmUgbWV0IGhlcmUuDQo+ID4gVGhpcyBp cyBub3QgcG9zc2libGUgYnkgc3RpdGNoaW5nIHRvZ2V0aGVyIGEgRnJhbmtlbnByb3RvY29sICh3 aGljaCwgYnkNCj4gY29tcG9zaW5nIG9sZCBlbGVtZW50cyBpbiBhIG5ldyB3YXksIHN0aWxsIHdv dWxkIGJlIGEgbmV3IHByb3RvY29sKS4NCj4gDQo+IERlcGVuZGluZyBvbiB3aGF0IHlvdSBtZWFu IGhlcmUsIEkgbWlnaHQgb3IgbWlnaHQgbm90IGFncmVloa0NCj4gDQo+IEZvciBpbnN0YW5jZSwg aWYgd2UgZGVjaWRlIHRoYXQgYW4gRUFQLWJhc2VkIGFwcHJvYWNoIGNvdWxkIHdvcmsgaW4gdGhp cw0KPiBlbnZpcm9ubWVudCAoYXMgaXQgZG9lcyBmb3IgZXZlcnkgd2ktZmkgZGV2aWNlIHRoYXQg bmVlZHMgdG8gam9pbiBhbg0KPiA4MDIuMTF4LXNlY3VyZWQgbmV0d29yayksIEkgdGhpbmsgd2Ug bWlnaHQgd2FudCB0byBkZWZpbmUgYW4gRUFQIG1ldGhvZA0KPiB0aGF0IGxldmVyYWdlcyB0aGUg ZXhpc3RpbmcgY3J5cHRvIGFsZ29yaXRobXMgYW5kIHNlY3VyaXR5IHByb3RvY29scyBhdmFpbGFi bGUNCj4gb24gdGhlIGNvbnN0cmFpbmVkIGRldmljZSwgYmFzZWQgb24gdGhlIGFzc3VtcHRpb24g dGhhdCB0aGUgZGV2aWNlIHdpbGwgYWxzbw0KPiBpbXBsZW1lbnQgYSBjb25zdHJhaW5lZCB2ZXJz aW9uIG9mIERUTFMgKGFzIGRlZmluZWQgYnkgdGhlIERJQ0UgV0cpLg0KPiBXaGVyZSB3b3VsZCB0 aGF0IGZhbGwgaW4geW91ciB2aWV3IG9mIHRoZSB3b3JsZD8gIEkgZG9uJ3QgdGhpbmsgaXQgd291 bGQgYmUgYQ0KPiBGcmFua2VucHJvdG9jb2wgYXQgYWxsLCBzaW5jZSBFQVAgaXMgZGVzaWduZWQg dG8gYmUgZXh0ZW5kZWQgdGhhdCB3YXkuICBUaGVyZQ0KPiBhbHNvIHdvdWxkbid0IGJlIG11Y2gg bmV3IHByb3RvY29sIHdvcmssIGFzIGFuIEVBUC1EVExTIG1ldGhvZCBjb3VsZCBiZQ0KPiBwcmV0 dHkgc2ltaWxhciB0byB0aGUgZXhpc3RpbmcgRUFQLVRMUyBtZXRob2QuICBBc3N1bWluZyBzb21l dGhpbmcgbGlrZSB0aGF0DQo+IGNvdWxkIG1lZXQgb3VyIGFzLXlldC11bmRldGVybWluZWQgcmVx dWlyZW1lbnRzIGZvciB0aGlzIGVudmlyb25tZW50LA0KPiB3b3VsZCB5b3UgY29uc2lkZXIgdGhh dCB0byBiZSBhIHN1Y2Nlc3NmdWwgb3V0Y29tZT8NCj4gDQo+IE1hcmdhcmV0DQo+IA0KPiANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBBY2UgbWFpbGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K From nobody Wed Mar 19 01:54:13 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91B81A0714 for ; Wed, 19 Mar 2014 01:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msUucE4RGImY for ; Wed, 19 Mar 2014 01:54:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 72F031A0696 for ; Wed, 19 Mar 2014 01:54:05 -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.7-GA FastPath queued) with ESMTP id BCF34033; Wed, 19 Mar 2014 08:53:56 +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.3.158.1; Wed, 19 Mar 2014 08:53:22 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 08:53:33 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Wed, 19 Mar 2014 16:53:27 +0800 From: Likepeng To: Margaret Wasserman , Zach Shelby , "robert.cragie@gridmerge.com" Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: AQHPQq9FmD28fVgNqkuQ/CK86XiTM5roGf6w Date: Wed, 19 Mar 2014 08:53:26 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B07596@SZXEMA501-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B07596SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/CVLBfzxuvzoVSo5ETCzznsrHIvU Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 08:54:11 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B07596SZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pkkgd291bGQgb2JqZWN0IHRvIGEgcGhhc2VkIGNoYXJ0ZXIgdGhhdCByZXF1aXJlcyB1cyB0byBw dWJsaXNoIG91ciB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBhcyBSRkNzIGJlZm9yZSB3ZSBk byBhbnkgcHJvdG9jb2wgd29yay4NCg0KTGV04oCZcyByZW1vdmUg4oCcaW4gdGhpcyBvcmRlcuKA nSBiZWZvcmUgdGhlIHRhc2sgbGlzdCBpbiB0aGUgY2hhcnRlci4NCj4gVGhlIHdvcmtpbmcgZ3Jv dXAgaGFzIHRoZSBmb2xsb3dpbmcgdGFza3MgKGluIHRoaXMgb3JkZXIpOg0KDQo+SSdkIGJlIHBl cmZlY3RseSBoYXBweSB3aXRoIHB1Ymxpc2hpbmcgdGhlbSBhcyBSRkNzIGxhdGVyIGluIHRoZSBw cm9jZXNzLCB0aG91Z2guDQoNCk9LLCBnb3QgaXQuDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoN CuWPkeS7tuS6ujogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBNYXJn YXJldCBXYXNzZXJtYW4NCuWPkemAgeaXtumXtDogMjAxNOW5tDPmnIgxOOaXpSAyMTozOA0K5pS2 5Lu25Lq6OiBaYWNoIFNoZWxieTsgcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tDQrmioTpgIE6 IGFjZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9zYWwgdjAu NQ0KDQpQdWJsaXNoaW5nIHRoZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBpbiBhbiBSRkMg aXMgTk9UIHRoZSBzYW1lIHRoaW5nIGFzIGdhdGluZyBvdXIgb3RoZXIgd29yayBvbiBwdWJsaXNo aW5nIHRob3NlIHRoaW5ncyBmaXJzdCAtLSBJIHdvdWxkIG9iamVjdCB0byBhIHBoYXNlZCBjaGFy dGVyIHRoYXQgcmVxdWlyZXMgdXMgdG8gcHVibGlzaCBvdXIgdXNlIGNhc2VzIGFuZCByZXF1aXJl bWVudHMgYXMgUkZDcyBiZWZvcmUgd2UgZG8gYW55IHByb3RvY29sIHdvcmssIGFuZCBJIGxpa2Ug dGhlIGlkZWEgb2YgdXNpbmcgYSB3aWtpIHRvIGNvbGxlY3QgYW5kIHJlZmluZSB0aGVtLg0KDQpX ZSBzaG91bGQgcmVtZW1iZXIsIHRob3VnaCwgdGhhdCB3ZSB3aWxsIG5lZWQgdG8gaW52b2x2ZSBh IHdpZGUgcmFuZ2Ugb2YgSUVURiBwYXJ0aWNpcGFudHMsIGluY2x1ZGluZyBtdWx0aXBsZSBJRVRG IHNlY3VyaXR5IGV4cGVydHMsIHRvIGJlIHN1Y2Nlc3NmdWwuICBOb3QgYWxsIG9mIHRob3NlIHBl b3BsZSB3aWxsIGhhdmUgd29ya2VkIGluIHRoZSBJb1QvZW1iZWRkZWQgc3BhY2UsIHNvIGRvY3Vt ZW50aW5nIHRoZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBlYXJseSBpbiB0aGUgcHJvY2Vz cyAob24gYSB3aWtpIHBhZ2UgaXMgZmluZSkgd2lsbCBiZSBlc3NlbnRpYWwgdG8gYWxsb3dpbmcg dGhhdCB3aWRlciBzZXQgb2YgSUVURiBwYXJ0aWNpcGFudHMgdG8gZW5nYWdlIGNvbnN0cnVjdGl2 ZWx5Lg0KDQpJJ2QgcGVyc29uYWxseSBsaWtlIHRvIHNlZSB0aGUgdXNlIGNhc2VzIGFuZCByZXF1 aXJlbWVudHMgY2FwdHVyZWQgaW4gYW4gYWNoaXZhbCBmb3JtIHRoYXQgY2FuIGJlIHJlZmVyZW5j ZWQgbGF0ZXIsIGJlY2F1c2UgSSB0aGluayB0aGUgdXNlIGNhc2VzLCBpbiBwYXJ0aWN1bGFyLCBt aWdodCBiZSB1c2VmdWwgZm9yIGxhdGVyIHdvcmsuICBJJ2QgYmUgcGVyZmVjdGx5IGhhcHB5IHdp dGggcHVibGlzaGluZyB0aGVtIGFzIFJGQ3MgbGF0ZXIgaW4gdGhlIHByb2Nlc3MsIHRob3VnaC4N Cg0KSWYgcGVvcGxlIHdvdWxkIHJhdGhlciB0cnkgdG8gY2FwdHVyZSB0aGUgbWFqb3IgdXNlIGNh c2VzIGFuZCBtb3RpdmF0aW9ucyBpbiB0aGUgcHJvdG9jb2wgc3BlYyBpbnN0ZWFkLCBJIGd1ZXNz IHRoYXQgd291bGQgd29yayBmb3IgbWUsIGJ1dCBJIHdvdWxkIHNvbWV3aGF0IHByZWZlciBhbiB1 bmNsdXR0ZXJlZCBwcm90b2NvbCBzcGVjIHRoYXQgcmVmZXJzIHRvIHN1cHBvcnRpbmcgaW5mb3Jt YXRpb25hbCBkb2N1bWVudHMuDQoNCk1hcmdhcmV0DQoNCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tDQpGcm9tIFphY2ggU2hlbGJ5IDxaYWNoLlNoZWxieUBhcm0uY29tPG1h aWx0bzpaYWNoLlNoZWxieUBhcm0uY29tPj4NCkRhdGU6IDAzLzE0LzIwMTQgMTE6MzEgQU0gKEdN VC0wNTowMCkNClRvIHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTxtYWlsdG86cm9iZXJ0LmNy YWdpZUBncmlkbWVyZ2UuY29tPg0KQ2MgYWNlQGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+ DQpTdWJqZWN0IFJlOiBbQWNlXSBBQ0UgQ2hhcnRlciBQcm9wb3NhbCB2MC41DQoNCkFzIEkgbWVu dGlvbmVkIGluIHRoZSBCb0YsIG15IGFkdmljZSB3b3VsZCBiZSB0byBqdXN0IHVzZSBhIHdpa2kg dG8gY29sbGVjdCB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cy4NCg0KTm93LCBpZiB3ZSB3YW50 IHRvIHdhc3RlIHRoZSBmaXJzdCBoYWxmIHllYXIgYnJpbmluZyBzdWNoIGRyYWZ0cyB0aHJvdWdo IHRoZSBSRkMgcHJvY2VzcyB0aGVuIGdvIGFoZWFkLiBGcm9tIG15IGV4cGVyaWVuY2UgdGhlc2Ug a2luZHMgb2Ygd29yayBpdGVtcyBhcmUganVzdCBhIFdHIGJsYWNrIGhvbGUuIFlvdSBjYW4gYWx3 YXlzIGRvY3VtZW50IHRoZSBhc3N1bWVkIHVzZSBjYXNlcyB3aXRoaW4gdGhlIGFjdHVhbCB0ZWNo bmljYWwgc3BlY2lmaWNhdGlvbiB0byBtYWtlIGl0IGNsZWFyIHdoYXQgcHJvYmxlbSBpdCBpcyB0 cnlpbmcgdG8gc29sdmUuDQoNClphY2gNCg0KT24gTWFyIDE0LCAyMDE0LCBhdCA4OjAyIEFNLCBS b2JlcnQgQ3JhZ2llIDxyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb208bWFpbHRvOnJvYmVydC5j cmFnaWVAZ3JpZG1lcmdlLmNvbT4+IHdyb3RlOg0KDQo+ICsxIHRvIGJvdGggTWFyZ2FyZXQncyBz dGF0ZW1lbnRzLg0KPg0KPiBSb2JlcnQNCj4NCj4gT24gMTMvMDMvMjAxNCAxMDo1NSBBTSwgTWFy Z2FyZXQgV2Fzc2VybWFuIHdyb3RlOg0KPj4gUGVyc29uYWxseSwgSSB3b3VsZCBhbHNvIHJhdGhl ciBzZWUgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIHB1Ymxpc2hlZCBhcyBpbmZvcm1h dGlvbmFsUkZDcy4gIEkgdGhpbmsgdGhhdCBhIHdpa2kgbWlnaHQgYmUgYSBnb29kIHdheSB0byBj b2xsZWN0IHRoZW0gYXQgZmlyc3QsIGJ1dCBJIHdvdWxkIHByZWZlciB0byBiZSBzdXJlIHRoYXQg d2UgaGF2ZSBjb25zZW5zdXMgb24gdGhlIHByb2JsZW0ocykgd2UgYXJlIHRyeWluZyB0byBzb2x2 ZS4gIEkgYWxzbyB0aGluayBpdCB3aWxsIGJlIHVzZWZ1bCB0byBoYXZlIHRoZXNlIHRoaW5ncyBp biBhcmNoaXZhbCBmb3JtIGxhdGVyLg0KPj4NCj4+IEkgZG8gbm90IHRoaW5rIHRoZSBvdGhlciB3 b3JrIG9mIHRoZSBncm91cCBzaG91bGQgYmUgZ2F0ZWQgb24gdGhlIHJlcXVpcmVtZW50cywgdGhv dWdoLCBhcyBJIHRoaW5rIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gZXhwbG9yZSBob3cgZXhpc3Rp bmcgdGVjaG5vbG9naWVzIGNvdWxkIG9yIGNvdWxkbid0IG1lZXQgdGhlIHJlcXVpcmVtZW50cyB0 byBpbnN1cmUgdGhhdCBvdXIgcmVxdWlyZW1lbnRzIGFyZSByZWFsaXR5LWJhc2VkLg0KPj4NCj4+ IE1hcmdhcmV0DQo+Pg0KPj4NCj4+DQo+PiAtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tDQo+PiBGcm9tIExpa2VwZW5nIDxsaWtlcGVuZ0BodWF3ZWkuY29tPG1haWx0bzpsaWtlcGVu Z0BodWF3ZWkuY29tPj4NCj4+IERhdGU6IDAzLzEzLzIwMTQgNDoyOCBBTSAoR01ULTA1OjAwKQ0K Pj4gVG8gSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRv Omhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PixHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFu ZGVyQGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPj4sWmFj aCBTaGVsYnkgPFphY2guU2hlbGJ5QGFybS5jb208bWFpbHRvOlphY2guU2hlbGJ5QGFybS5jb20+ Pg0KPj4gQ2MgYWNlQGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0IFJl OiBbQWNlXSBBQ0UgQ2hhcnRlciBQcm9wb3NhbCB2MC41DQo+Pg0KPj4NCj4+IE15IHBlcnNvbmFs IG9waW5pb24gaXMgdGhhdCB0aGUgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50cyBkb2N1bWVudCBj YW4gaGVscCBwZW9wbGUgdG8gdW5kZXJzdGFuZCB3aGF0IGtpbmQgb2YgaXNzdWVzIHdlIGFyZSB0 cnlpbmcgdG8gcmVzb2x2ZS4NCj4+DQo+PiBJIGNhbiBzZWUgc29tZSB2YWx1ZXMgdG8gcHVibGlz aCBpdCBpbnRvIFJGQ3MuIElmIGl0IGlzIGEgd2lraSBwYWdlLCB3ZSB3aWxsIGhhdmUgbGVzcyBw ZW9wbGUgdG8gcmV2aWV3IGl0IG9yIGltcHJvdmUgaXQuDQo+Pg0KPj4gRXNwZWNpYWxseSB0aGUg dXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50IGRvY3VtZW50IGlzIGFscmVhZHkgaW4gYSBnb29kIHNo YXBlIGFuZCBpdCBpcyByZWZlcmVuY2VkIHNldmVyYWwgdGltZXMgaW4gdGhlIG1haWxpbmcgbGlz dCB0byBpbnRyb2R1Y2Ugb3VyIHdvcmsgdG8gb3V0c2lkZS4NCj4+DQo+PiBUaGFua3MsDQo+Pg0K Pj4gS2luZCBSZWdhcmRzDQo+PiBLZXBlbmcNCj4+DQo+PiA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCj4+ID4g5Y+R5Lu25Lq6OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10g5Luj 6KGoIEhhbm5lcyBUc2Nob2ZlbmlnDQo+PiA+IOWPkemAgeaXtumXtDogMjAxNOW5tDPmnIgxM+aX pSA0OjMzDQo+PiA+IOaUtuS7tuS6ujogR8O2cmFuIFNlbGFuZGVyOyBaYWNoIFNoZWxieQ0KPj4g PiDmioTpgIE6IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0KPj4gPiDkuLvpopg6 IFJlOiBbQWNlXSBBQ0UgQ2hhcnRlciBQcm9wb3NhbCB2MC41DQo+PiA+DQo+PiA+IEhpIEdvZXJh biwNCj4+ID4NCj4+ID4gSSByZWFkIGEgbGl0dGxlIGJpdCBiZXR3ZWVuIHRoZSBsaW5lcyBvZiB5 b3VyIG1haWwgYW5kIHlvdXIgbWFpbiBjb25jZXJuIGlzIHRoYXQNCj4+ID4geW91IHdhbnQgdG8g aGF2ZSBhbiBSRkMgcHVibGlzaGVkIHdpdGggeW91ciBuYW1lIG9uIGl0Lg0KPj4gPiBBIHdpa2kg cGFnZSB0byBkb2N1bWVudCB0aGUgcmVxdWlyZW1lbnRzLCBhbmQgdXNlIGNhc2VzIGlzIG5vdCBn b29kIGVub3VnaA0KPj4gPiBmb3IgeW91Lg0KPj4gPg0KPj4gPiBGb3IgeW91IHB1dHRpbmcgdGhl IGRyYWZ0IHRleHQgb24gYSBXRyB3aWtpIGZlZWxzIGxpa2Ugd2FzdGVkIHRpbWUuDQo+PiA+IEl0 IGlzIGp1c3QgYSBkaWZmZXJlbnQgZm9ybSBvZiBkb2N1bWVudGluZyB0aGUgd29yay4NCj4+ID4N Cj4+ID4gTXkgZXhwZXJpZW5jZSB3aXRoIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGhhcyBu b3QgYmVlbiBncmVhdCBpbiB0aGUgSUVURi4NCj4+ID4gSW4gZXNzZW5jZSBldmVyeW9uZSBxdWlj a2x5IG1vdmVzIG9uIG9uY2UgdGhlIGdyb3VwIGRlY2lkZXMgYWJvdXQgYQ0KPj4gPiBwYXJ0aWN1 bGFyIHNvbHV0aW9uIGRpcmVjdGlvbi4gSXQgdGhlbiBiZWNvbWVzIHZlcnkgaGFyZCAoZm9yIHRo ZQ0KPj4gPiBjaGFpcnMpIHRvIGZpbmlzaCB0aGUgcmVxdWlyZW1lbnRzIHdvcmsgc2luY2Ugbm9i b2R5IHdhbnRzIHRvIHJldmlldyBvciBsb29rDQo+PiA+IGF0IHRoZW0gYW55bW9yZS4NCj4+ID4N Cj4+ID4gVXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgYXJlIGdyZWF0IGR1cmluZyB0aGUgaW5p dGlhbCBwYXJ0IG9mIHRoZSB3b3JrIHRvIGdldA0KPj4gPiBhbiB1bmRlcnN0YW5kaW5nIG9mIHRo ZSBtYWluIGNoYWxsZW5nZXMuDQo+PiA+DQo+PiA+IEhhdmluZyBzYWlkIHRoYXQgSSB3aWxsIGxl YXZlIGl0IHRvIHRoZSBncm91cCB0byBkZWNpZGUgd2hhdCB0aGV5IHdhbnQgdG8gZG86DQo+PiA+ IFJGQ3Mgb3IgV2lraSBwYWdlDQo+PiA+DQo+PiA+IENpYW8NCj4+ID4gSGFubmVzDQo+PiA+DQo+ PiA+IFBTOiBSZWdhcmRpbmcgeW91ciBvdGhlciBjb21tZW50IGFib3V0IHBvaW50aW5nIHRvIHRo ZSBjb25zdHJhaW50IG5hdHVyZSB0bw0KPj4gPiBldmVyeSBpdGVtLiBXZSBjYW4gZG8gdGhhdCBp ZiB5b3UgZmVlbCBiZXR0ZXIgYnV0IHRoZSBlbnRpcmUgY2hhcnRlciBwYWdlDQo+PiA+IGFscmVh ZHkgc2F5cyAxMCB0aW1lcyB0aGF0IHdlIGFyZSBmb2N1c2luZyBvbiB0aGUgY29uc3RyYWludCBz cGFjZS4NCj4+ID4gSSBhbSBzdXJlIHRoYXQgdGhlIHJlYWRlciB3aWxsIGhhdmUgdW5kZXJzdG9v ZCB0aGF0IHdoZW4gdGhleSBnZXQgdG8gdGhlIHRhc2sNCj4+ID4gbGlzdC4NCj4+ID4NCj4+ID4N Cj4+ID4gT24gMDMvMTIvMjAxNCAxMDozMiBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4g PiA+IEhhbm5lcywgWmFjaCBhbmQgYWxsLA0KPj4gPiA+DQo+PiA+ID4gSSBtdXN0IHNheSBJIGRv bsK5dCBmaW5kIHRoZSB0YXNrIGxpc3Qgb2YgdGhlIGN1cnJlbnQgY2hhcnRlciB2ZXJ5IGhlbHBm dWw6DQo+PiA+ID4NCj4+ID4gPiDCs1RoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5n IHRhc2tzIChpbiB0aGlzIG9yZGVyKToNCj4+ID4gPg0KPj4gPiA+IDEpIFRoZSB3b3JraW5nIGdy b3VwIFdpa2kgcGFnZXMgd2lsbCBiZSB1c2VkIHRvIGRvY3VtZW50IHVzZSBjYXNlcywNCj4+ID4g PiByZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEuIFRoaXMgd29yayB3 aWxsIGd1aWRlIHRoZQ0KPj4gPiA+IGlkZW50aWZpY2F0aW9uIG9mIHN1aXRhYmxlIHByb3RvY29s IG1lY2hhbmlzbXMuDQo+PiA+ID4NCj4+ID4gPiAyKSBTZWxlY3Rpb24gb2YgYW4gYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9yDQo+PiA+ID4gY29uc3RyYWluZWQg ZW52aXJvbm1lbnRzLg0KPj4gPiA+DQo+PiA+ID4gMykgRXZhbHVhdGlvbiBvZiB0aGUgY2FuZGlk YXRlIHNvbHV0aW9uIGZvciB1c2Ugd2l0aCBIVFRQL1RMUyBhbmQNCj4+ID4gPiBwcm94eSBkZXBs b3ltZW50cy7Csg0KPj4gPiA+DQo+PiA+ID4gVGhpcyBsaXN0IGRvZXMgbm90IGdpdmUgbXVjaCBt b3JlIGRldGFpbHMgYWJvdXQgdGhlIHdvcmsgdG8gYmUNCj4+ID4gPiBjb25kdWN0ZWQgdGhhbiBp cyBhbHJlYWR5IGdpdmVuIGJ5IHRoZSB0aXRsZSBvZiB0aGUgV0cuIFRvIGEgcGVyc29uDQo+PiA+ ID4gbm90IGhhdmluZyBmb2xsb3dlZCB0aGUgZGlzY3Vzc2lvbiwgdGhlIGltcHJlc3Npb24gaXMg dGhhdCB0aGUgd29yaw0KPj4gPiA+IHN0YXJ0cyBmcm9tIHNjcmF0Y2ggYW5kIHRoZXJlIGlzIG5v IGNsZWFyIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB0byBkby4NCj4+ID4gPg0KPj4gPiA+IElmIHdl IGNhbsK5dCBmb3JtdWxhdGUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBmaXJzdCBzdGVwIHRv d2FyZHMgYQ0KPj4gPiA+IHNvbHV0aW9uIGluIHNvbWUgZGVncmVlIG9mIGRldGFpbCBiZWZvcmUg c3RhcnRpbmcgdGhlIFdHIHRoYXQgd2lsbA0KPj4gPiA+IGFueXdheSBiZSB0aGUgZmlyc3QgdGFz ayB0byBkbywgc28gbGV0wrlzIHRyeSB0byBnZXQgc29tZXRoaW5nIGluIHdyaXRpbmcuDQo+PiA+ ID4NCj4+ID4gPg0KPj4gPiA+ICIxKSBUaGUgd29ya2luZyBncm91cCBXaWtpIHBhZ2VzIHdpbGwg YmUgdXNlZCB0byBkb2N1bWVudCB1c2UgY2FzZXMsDQo+PiA+ID4gcmVxdWlyZW1lbnRzLCBhbmQg cHJvdG9jb2wgZGVzaWduIGNyaXRlcmlhLiBUaGlzIHdvcmsgd2lsbCBndWlkZSB0aGUNCj4+ID4g PiBpZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNoYW5pc21zLiINCj4+ID4g Pg0KPj4gPiA+IFRoaXMgaXMgaGlkaW5nIHRoZSBmYWN0IHRoYXQgdGhlcmUgaGFzIGJlZW4gNiBt b250aHMgb2Ygd29yayBvbiB0aGUNCj4+ID4gPiB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRy YWZ0ICh0aGUgZmlyc3QgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHdhcw0KPj4gPiA+IHN1Ym1pdHRl ZCB0byBDb1JFIGluIElFVEY4OCksIHdoaWNoIG5vIG9uZSBoYXMgZGlzYWdyZWVkIGlzIHNldHRp bmcNCj4+ID4gPiB0aGUgc3RhZ2UgZm9yIHRoaXMgd29yay4gTG9vayBhdCBwYXJhbGxlbCB0aHJl YWRzIG9uIHRoaXMgbWFpbGluZyBsaXN0DQo+PiA+ID4gd2hlcmUgcGVvcGxlIGFzayB3aGV0aGVy IHRoZWlyIHBhcnRpY3VsYXIgc2VjdXJpdHktZm9yLUlvVCBkcmFmdCBmaXRzDQo+PiA+ID4gaW50 byBBQ0UuIFRoZSBhbnN3ZXIgSGFubmVzIGlzIGdpdmluZyBpcyBjb3JyZWN0bHk6IHRoZSBzY29w ZSBvZiB0aGlzDQo+PiA+ID4gd29yayBpcyB3aGF0IGlzIG91dGxpbmVkIGJ5IHRoZSB1c2UgY2Fz ZSBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0LiBJDQo+PiA+ID4gZG9uwrl0IG1pbmQgdXNpbmcgdGhl IFdpa2kgYXMgYSB3b3JraW5nIHRvb2wgYnV0IHRoaXMgZG9lcyBub3QgZ2l2ZQ0KPj4gPiA+IHRy YWNlYWJpbGl0eSBhIHllYXIgbGF0ZXIuIEFuZCBJIGRvbsK5dCBzZWUgdGhlIHBvaW50IGlmIGNv cHlpbmcgdGhlDQo+PiA+ID4gdXNlIGNhc2UgZG9jdW1lbnQgaW50byBhIFdpa2kgcGFnZSAtIHJl YWQgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIHlvdXINCj4+ID4gY29tbWVudHMhDQo+PiA+ID4NCj4+ ID4gPiBXaGVuIGl0IGNvbWVzIHRvIHByb3RvY29sIGRlc2lnbiBjcml0ZXJpYSwgSSBhZ3JlZSB0 aGF0IG1vcmUgd29yayBpcw0KPj4gPiA+IG5lZWRlZCwgZm9yIHdoaWNoIHRoZSBXaWtpIG1heSBi ZSBzdWl0YWJsZS4gTmV2ZXJ0aGVsZXNzIEkgaW5zaXN0IG9uDQo+PiA+ID4gZG9jdW1lbnRpbmcg dGhlIGRlc2lnbiBjcml0ZXJpYSBhbmQgaXRzIHJhdGlvbmFsZSBzaW5jZSB0aGF0IHByb3ZpZGVz DQo+PiA+ID4gYSBtZWFucyBmb3IgdHJhY2VhYmlsaXR5LiBNYWtlIGl0IGEgbWlsZXN0b25lIHRv IGhhdmUgYSBkcmFmdCB3aXRoDQo+PiA+ID4gYXNzdW1wdGlvbnMgYW5kIGRlc2lnbiBjcml0ZXJp YSAgKHlvdSBtYXkgaW5jbHVkZSDCs2FyY2hpdGVjdHVyZcKyIGluDQo+PiA+ID4gdGhpcyBkb2N1 bWVudCkuIFRoaXMgd29yayBpcyBhbnl3YXkgYSBwcmUtcmVxdWlzaXRlIGZvciBjb21pbmcgdG8g YQ0KPj4gPiA+IHNvbHV0aW9uLCBhbmQgb25jZSB5b3UgaGF2ZSB0aGlzIGNvbnRlbnQsIHRoZSBj YW5kaWRhdGUgc29sdXRpb25zIGFyZQ0KPj4gPiA+IG11Y2ggZWFzaWVyIGV2YWx1YXRlZC4NCj4+ ID4gPg0KPj4gPiA+IFNvLCBjaGFuZ2UgMSkgdG8gc3RhdGUgc29tZXRoaW5nIGxpa2UNCj4+ID4g Pg0KPj4gPiA+ICIxwrkgKQ0KPj4gPiA+IGEpIGNvbXBsZXRlIHRoZSB3b3JrIG9uIHVzZSBjYXNl IGFuZCByZXF1aXJlbWVudHMNCj4+ID4gPiBiKSB1c2UgV2lraSBwYWdlcyBmb3IgbGlzdGluZyBh c3N1bXB0aW9ucyBhbmQgcHJvdG9jb2wgZGVzaWduDQo+PiA+ID4gY3JpdGVyaWEsIGRvY3VtZW50 IHRoZSByZXN1bHQgaW4gYSBkcmFmdCINCj4+ID4gPg0KPj4gPiA+IFByb3h5IGRlcGxveW1lbnQg YXNwZWN0cyBmaXRzIHdlbGwgaW50byAxYikgIFttb3JlIGluIHNlcGFyYXRlDQo+PiA+ID4gdXBj b21pbmcgbWFpbF0NCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4gMikgU2VsZWN0aW9uIG9mIGFuIGF1 dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sIGZvcg0KPj4gPiA+IGNvbnN0 cmFpbmVkIGVudmlyb25tZW50cy4NCj4+ID4gPg0KPj4gPiA+IEhlcmUgScK5bSBtaXNzaW5nIGFt b25nIG90aGVyIHRoaW5ncyB0aGUgc3BlY2lmaWMgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+PiA+ID4g VGhlIHByZWxpbWluYXJ5IGNvbmNsdXNpb25zIGZyb20gdGhlIHVzZSBjYXNlIGFuZCByZXF1aXJl bWVudHMgZHJhZnQNCj4+ID4gPiBmb3JtZWQgdGhlIGJhc2lzIGZvciB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQgYXMgcHJlc2VudGVkIGluIHRoZSBCT0Y6IFdlDQo+PiA+ID4gbGFjayBhIG1lY2hhbmlz bSBmb3IgZHluYW1pYyBhbmQgZmluZSBncmFpbmVkIGFjY2VzcyBjb250cm9sIGZvcg0KPj4gPiA+ IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCj4+ID4gPg0KPj4gPiA+IFRoZSBwcm9jZXNzIGhl cmUgc2hvdWxkIGJlIHRvOg0KPj4gPiA+ICIywrkpIGlkZW50aWZ5IHN1aXRhYmxlIHByb3RvY29s IG1lY2hhbmlzbXMgYW5kIG1hdGNoIGNhbmRpZGF0ZQ0KPj4gPiA+IGF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIHByb3RvY29scyBhZ2FpbnN0IHJlcXVpcmVtZW50cyBhbmQNCj4+ID4g PiBkZXNpZ24gY3JpdGVyaWEsIGluIHBhcnRpY3VsYXIgYWRkcmVzc2luZyBkeW5hbWljIGFuZCBm aW5lIGdyYWluZWQNCj4+ID4gPiBhY2Nlc3MgY29udHJvbCBzdWl0YWJsZSBmb3IgQ29BUCByZXNv dXJjZSBhY2Nlc3MgcmVxdWVzdHMgaW4gY29uc3RyYWluZWQNCj4+ID4gZW52aXJvbm1lbnRzLiIN Cj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPiAzKSBFdmFsdWF0aW9uIG9mIHRoZSBjYW5k aWRhdGUgc29sdXRpb24gZm9yIHVzZSB3aXRoIEhUVFAvVExTIGFuZA0KPj4gPiA+IHByb3h5IGRl cGxveW1lbnRzLsKyDQo+PiA+ID4NCj4+ID4gPg0KPj4gPiA+IEFzIG1lbnRpb25lZCBhYm92ZSwg cHJveHkgZGVwbG95bWVudHMgY291bGQgYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mDQo+PiA+IDHC uWIpLg0KPj4gPiA+IEluIDLCuSkgaXQgaXMgYWxyZWFkeSBzdGF0ZWQgdGhhdCBpbiBwYXJ0aWN1 bGFyIHdlIHNob3VsZCBjb25zaWRlciBDb0FQDQo+PiA+ID4gb24gaW50ZXJmYWNlIChJSSkuIEFz IGZvciB1c2Ugb2Ygb3RoZXIgcHJvdG9jb2xzIGJlc2lkZXMgQ29BUCB0aGF0DQo+PiA+ID4gaXNz dWUgaXMgb3J0aG9nb25hbCB0byB0aGlzIHNvIEkgbGVhdmUgdGhhdCBvdXQgZnJvbSB0aGlzIGRp c2N1c3Npb24uDQo+PiA+ID4NCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4gR8O2cmFuDQo+PiA+ID4N Cj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPg0KPj4gPiA+IE9uIDExLzAzLzE0IDE2OjQ5 LCAiWmFjaCBTaGVsYnkiIDxaYWNoLlNoZWxieUBhcm0uY29tPG1haWx0bzpaYWNoLlNoZWxieUBh cm0uY29tPj4gd3JvdGU6DQo+PiA+ID4NCj4+ID4gPj4gSGFubmVzLA0KPj4gPiA+Pg0KPj4gPiA+ PiBJIGFtIGhhcHB5IHdpdGggdGhpcyBjaGFydGVyIHdpdGggb25lIGV4Y2VwdGlvbi4gVGhlIHBy b3h5IGl0ZW0gaGVyZQ0KPj4gPiA+PiBzZWVtcyB0byBiZSBtb3JlIG9mIGEgZGlzdHJhY3Rpb24g dGhhbiBhbnl0aGluZyBlbHNlLCBhbmQgd2lsbA0KPj4gPiA+PiBwcm9iYWJseSByZXN1bHQgaW4g aW5jcmVhc2VkIGNvbXBsZXhpdHkuIFdhcyBwcm94eSBzdXBwb3J0IG1heWJlIGp1c3QNCj4+ID4g Pj4gYSBtaXN1bmRlcnN0YW5kaW5nPyBEbyB3ZSByZWFsbHkgc2VlIHRoZSBuZWVkIGZvciBhIHBy b3h5IGluIHRoZQ0KPj4gPiA+PiBtaWRkbGUgb2YgSSBvciBJSUk/DQo+PiA+ID4+DQo+PiA+ID4+ IEkgdGhpbmsgd2hhdCB3ZSByZWFsbHkgd2FudCBoZXJlIGlzIHRvIG1ha2Ugc3VyZSB0aGF0IGUu Zy4gZXZlbg0KPj4gPiA+PiB0aHJvdWdoIEkgaXMgYmFzZWQgb24gSFRUUC9UTFMsIElJIGFuZCBJ SUkgZm9yIGV4YW1wbGUgY2FuIHJ1bg0KPj4gPiA+PiBDb0FQL0RUTFMuIEluIG90aGVyIHdvcmRz LCBzb21lIGludGVyZmFjZXMgY2FuIGJlIGNvbnN0cmFpbmVkIHdoaWxlDQo+PiA+ID4+IG90aGVy cyBhcmUgbm90LiBJIHRoaW5rIHRoZSBjaGFydGVyIGFscmVhZHkgY292ZXJzIHRoaXMgZmluZS4N Cj4+ID4gPj4NCj4+ID4gPj4gU28gbXkgcHJvcG9zYWwgd291bGQgYmUgdG8gcmVtb3ZlIHRoZSBt ZW50aW9uIG9mIHByb3RvY29sIHRyYW5zbGF0aW9uDQo+PiA+ID4+IHByb3hpZXMuIElmIHdlIHJl YWxseSBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgc29tZSBkYXkgaW4gdGhlIGZ1dHVyZSwNCj4+ID4g Pj4gaXQgY291bGQgYmUgdGFja2xlZCB0aGVuLg0KPj4gPiA+Pg0KPj4gPiA+PiBaYWNoDQo+PiA+ ID4+DQo+PiA+ID4+IE9uIE1hciAxMSwgMjAxNCwgYXQgMTI6NTAgQU0sIEhhbm5lcyBUc2Nob2Zl bmlnDQo+PiA+ID4+IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQo+PiA+ID4+DQo+PiA+ID4+PiBIaSBhbGwsDQo+PiA+ ID4+Pg0KPj4gPiA+Pj4gSSBoYXZlIHRha2VuIHRoZSBmZWVkYmFjayBmcm9tIHRoZSBtZWV0aW5n IGFuZCB0aGUgcmVjZW50DQo+PiA+ID4+PiBkaXNjdXNzaW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0 IGFuZCBwcm9kdWNlZCBhIG5ldyBzdHJhd21hbiBwcm9wb3NhbC4NCj4+ID4gPj4+DQo+PiA+ID4+ PiBUaGUgY2hhbmdlcyBpbmNsdWRlOg0KPj4gPiA+Pj4gKiBBZGRlZCB0aGUgZm9jdXMgb24gRFRM Uy9Db0FQIHdpdGggYW4gaW5kaWNhdGlvbiB0aGF0IHdlIHdpbGwgY2hlY2sNCj4+ID4gPj4+IGEg Y2FuZGlkYXRlIHNvbHV0aW9uIGZvciBzdWl0YWJpbGl0eSB3aXRoIEhUVFAvVExTLg0KPj4gPiA+ Pj4gKiBBZGRlZCB0ZXh0IHRvIGluZGljYXRlIHRoYXQgd2Ugd2lsbCBhbHNvIHZlcmlmeSB0aGUg c3VpdGFiaWxpdHkgb2YNCj4+ID4gPj4+IHRoZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggcHJvdG9j b2wgdHJhbnNsYXRpb24gcHJveGllcy4NCj4+ID4gPj4+ICogU2ltcGxpZmllZCB0aGUgdGFzayBs aXN0IGJ5IHJlbW92aW5nIHNvbHV0aW9uIHNwZWNpZmljIGl0ZW1zLg0KPj4gPiA+Pj4gKiBNZXJn ZWQgc2V2ZXJhbCBpdGVtcyBvbiB0aGUgdGFzayBsaXN0ICh1c2UgY2FzZXMsIHJlcXVpcmVtZW50 cywNCj4+ID4gPj4+IGFuZCBwcm90b2NvbCBkZXNpZ24gZ3VpZGVsaW5lcykuIEZvbGxvd2VkIHRo ZSBzdWdnZXN0aW9uIHRvIHVzZSBvZiBhDQo+PiA+ID4+PiBXaWtpIGZvciBjYXB0dXJpbmcgdGhv c2UuDQo+PiA+ID4+Pg0KPj4gPiA+Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+PiA+ID4+Pg0KPj4g PiA+Pj4gLS0tLS0NCj4+ID4gPj4+DQo+PiA+ID4+PiBEcmFmdCBDaGFydGVyIFYwLjUgLSBBdXRo ZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3INCj4+ID4gPj4+IENvbnN0cmFpbmVkIEVu dmlyb25tZW50IChBQ0UpDQo+PiA+ID4+Pg0KPj4gPiA+Pj4gVGhlIElFVEYgaGFzIHJlY2VudGx5 IGRldmVsb3BlZCBwcm90b2NvbHMgZm9yIHVzZSBpbiBlbnZpcm9ubWVudHMNCj4+ID4gPj4+IHdo ZXJlIG5ldHdvcmsgbm9kZXMgYXJlIGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnksIGFuZCBwb3dlci4g SXQgd2FzDQo+PiA+ID4+PiBvYnNlcnZlZCB0aGF0IEludGVybmV0IHByb3RvY29scyBjYW4gYmUg YXBwbGllZCB0byB0aGVzZSBjb25zdHJhaW5lZA0KPj4gPiA+Pj4gZW52aXJvbm1lbnRzLCBvZnRl biBvbmx5IHJlcXVpcmluZyBtaW5vciB0d2Vha2luZyBhbmQgcHJvZmlsaW5nLiBJbg0KPj4gPiA+ Pj4gb3RoZXIgY2FzZXMsIG5ldyBwcm90b2NvbHMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gYWRkcmVz cyB0aGUgc3BlY2lmaWMNCj4+ID4gPj4+IHJlcXVpcmVtZW50cyBvZiBjb25zdHJhaW5lZCBkZXZp Y2VzIGFuZCBuZXR3b3Jrcy4gQW4gZXhhbXBsZSBvZiBzdWNoDQo+PiA+ID4+PiBhIHByb3RvY29s IGlzIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkuDQo+PiA+ID4+ PiBjb21wb25lbnRzDQo+PiA+ID4+PiBBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHF1ZXN0aW9uDQo+PiA+ID4+PiBhbHNvIGFyaXNlIGlu IGVudmlyb25tZW50cyB3aXRoIGNvbnN0cmFpbmVkIG5vZGVzIGFuZCBuZXR3b3Jrcy4gRm9yDQo+ PiA+ID4+PiBleGFtcGxlLCBhIGRvb3IgbG9jayBoYXMgdG8gYXV0aG9yaXplIHRoZSBwZXJzb24g c2Vla2luZyBhY2Nlc3MNCj4+ID4gPj4+IHVzaW5nIGEgImRpZ2l0YWwga2V5Ii4gV2hlcmUgYXJl IHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBzdG9yZWQ/DQo+PiA+ID4+PiBIb3cgZG9lcyB0 aGUgZGlnaXRhbCBrZXkgY29tbXVuaWNhdGUgd2l0aCB0aGUgbG9jaz8gRG9lcyB0aGUgbG9jaw0K Pj4gPiA+Pj4gaW50ZXJhY3Qgd2l0aCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBvYnRhaW4g YXV0aG9yaXphdGlvbg0KPj4gPiA+Pj4gaW5mb3JtYXRpb24/IEhvdyBjYW4gYWNjZXNzIGJlIGdy YW50ZWQgdG8gb3RoZXIgcGVyc29ucyB0ZW1wb3JhcmlseT8NCj4+ID4gSG93IGNhbiBhY2Nlc3Mg YmUgcmV2b2tlZD8NCj4+ID4gPj4+IFRoZXNlIHR5cGVzIG9mIHF1ZXN0aW9ucyBoYXZlIGJlZW4g YW5zd2VyZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzDQo+PiA+ID4+PiBmb3IgdXNlIGNhc2VzIG91 dHNpZGUgdGhlIGNvbnN0cmFpbmVkIGVudmlyb25tZW50LiBCdXQgaW4NCj4+ID4gPj4+IGNvbnN0 cmFpbmVkIGVudmlyb25tZW50LCBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBwb3NlIGNoYWxsZW5n ZXMgZm9yDQo+PiA+ID4+PiB0aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHkgcHJvdG9jb2xzLg0K Pj4gPiA+Pj4NCj4+ID4gPj4+IFRoZSBJRVRGIGhhcyBhIGxvbmcgaGlzdG9yeSBpbiBkZXZlbG9w aW5nIHRocmVlIHBhcnR5IGF1dGhlbnRpY2F0aW9uDQo+PiA+ID4+PiBhbmQgYXV0aG9yaXphdGlv biBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXMNCj4+ID4g Pj4+IGluY2x1ZGUgS2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kp LCB0aGUNCj4+ID4gPj4+IEF1dGhlbnRpY2F0aW9uLCBBdXRob3JpemF0aW9uLCBhbmQgQWNjb3Vu dGluZyAoQUFBKSBpbmZyYXN0cnVjdHVyZSwNCj4+ID4gPj4+IGFuZCB0aGUgV2ViIEF1dGhvcml6 YXRpb24gUHJvdG9jb2wgKE9BdXRoKS4gQWxsIHRoZXNlIHByb3RvY29scw0KPj4gPiA+Pj4gZW5q b3kgd2lkZXNwcmVhZCBkZXBsb3ltZW50IG9uIHRoZSBJbnRlcm5ldC4gQWx0aG91Z2ggdGhleSBh bGwgYWltDQo+PiA+ID4+PiB0byBzb2x2ZSBhIHNpbWlsYXIgZ29hbCwgYXQgYW4gYWJzdHJhY3Qg bGV2ZWwsIHRoZXkgb2ZmZXIgcXVpdGUNCj4+ID4gPj4+IGRpZmZlcmVudCBmdW5jdGlvbnMgYW5k IHV0aWxpemUgZGlmZmVyZW50IG1lc3NhZ2UgZXhjaGFuZ2VzLiBUaGVzZQ0KPj4gPiA+Pj4gZGlm ZmVyZW5jZXMgYXJlIG1vdGl2YXRlZCBieSB0aGUgbWFpbiBkZXBsb3ltZW50IHVzZSBjYXNlcyB0 aGV5IHdlcmUNCj4+ID4gZGVzaWduZWQgZm9yLg0KPj4gPiA+Pj4NCj4+ID4gPj4+IFJlcXVpcmVt ZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGluZGljYXRlIHRoZSBzdWl0YWJpbGl0eSBvZg0K Pj4gPiA+Pj4gYWxyZWFkeSBleGlzdGluZyB3b3JrLCBzdWNoIGFzIE9BdXRoLCBhcyBhIHNvbHV0 aW9uIGZvciBjb25zdHJhaW5lZA0KPj4gPiA+Pj4gZW52aXJvbm1lbnRzLiBUaGVzZSBwcm90b2Nv bHMgd2VyZSwgaG93ZXZlciwgbm90IG9wdGltaXplZCBmb3INCj4+ID4gPj4+IGNvbnN0cmFpbmVk IGVudmlyb25tZW50cy4gQWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBuZWVkIHRvIGJlDQo+ PiA+ID4+PiB0YWtlbiBpbnRvIGFjY291bnQgYXJlIHRoZSBsYWNrIG9mIGEgc3VpdGFibGUgdXNl ci1pbnRlcmZhY2UgZm9yDQo+PiA+ID4+PiBvYnRhaW5pbmcgdGhlIGNvbnNlbnQgb2YgdGhlIHVz ZXIgYW5kIHRoZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQNCj4+ID4gPj4+IGRldmljZXMgdG8gY29u dGFjdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBpbiByZWFsLXRpbWUgd2l0aCBldmVyeQ0KPj4g PiA+Pj4gYWNjZXNzIHJlcXVlc3QgZHVlIHRvIGludGVybWl0dGVudCBjb25uZWN0aXZpdHksIGV0 Yy4NCj4+ID4gPj4+DQo+PiA+ID4+PiBUaGlzIHdvcmtpbmcgZ3JvdXAgdGhlcmVmb3JlIGFpbXMg Zm9yIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvcg0KPj4gPiA+Pj4gYXV0aGVudGljYXRpb24g YW5kIGF1dGhvcml6YXRpb24gdG8gZW5hYmxlIGF1dGhvcml6ZWQgYWNjZXNzIHRvDQo+PiA+ID4+ PiByZXNvdXJjZXMgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBBcyBhIHN0YXJ0aW5nIHBv aW50LCB0aGUNCj4+ID4gPj4+IHdvcmtpbmcgZ3JvdXAgd2lsbCBhc3N1bWUgdGhhdCBhY2Nlc3Mg dG8gcmVzb3VyY2VzIG9mZmVyZWQgYnkgYQ0KPj4gPiA+Pj4gcmVzb3VyY2Ugc2VydmVyIGJ5IGEg Y2xpZW50IGRldmljZXMgdGFrZXMgcGxhY2UgdXNpbmcgQ29BUCBhbmQgaXMgcHJvdGVjdGVkDQo+ PiA+IGJ5IERUTFMuDQo+PiA+ID4+PiBCb3RoIHJlc291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1h eSBiZSByZXNvdXJjZSBjb25zdHJhaW50LiBUaGlzDQo+PiA+ID4+PiBhY2Nlc3Mgd2lsbCBiZSBt ZWRpYXRlZCBieSBhbiBhdXRob3JpemF0aW9uIHNlcnZlciwgd2hpY2ggZG9lcyBub3QNCj4+ID4g Pj4+IHN1ZmZlciBmcm9tIHRoZSBzYW1lIHJlc291cmNlIGxpbWl0YXRpb25zLg0KPj4gPiA+Pj4N Cj4+ID4gPj4+IEV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3Rv Y29scyBhcmUgdXNlZCBhbmQNCj4+ID4gPj4+IHJlLWFwcGxpZWQgZm9yIHVzZSB3aXRoIGNvbnN0 cmFpbmVkIGRldmljZXMsIHdoZXJlIGFwcGxpY2FibGUuIFRoaXMNCj4+ID4gPj4+IHJlcXVpcmVz IHJlbGV2YW50IHNwZWNpZmljYXRpb25zIHRvIGJlIHJldmlld2VkIGZvciBzdWl0YWJpbGl0eSwN Cj4+ID4gPj4+IHNlbGVjdGluZyBhIHN1YnNldCBvZiB0aGVtLCByZXN0cmljdGluZyB0aGUgb3B0 aW9ucyB3aXRoaW4gZWFjaCBvZg0KPj4gPiA+Pj4gdGhlIHNwZWNpZmljYXRpb25zLiBTb21lIGZ1 bmN0aW9uYWxpdGllcyBtYXksIGhvd2V2ZXIsIG5vdCBiZQ0KPj4gPiA+Pj4gYXZhaWxhYmxlIGlu IGV4aXN0aW5nIHByb3RvY29scyBhbmQgZm9yIHRob3NlIGNhc2VzIG5ldw0KPj4gPiA+Pj4gZnVu Y3Rpb25hbGl0eSBoYXMgdG8gYmUgc3RhbmRhcmRpemVkLiBUaHVzLCBleGlzdGluZyB3b3JrIGNh biBiZQ0KPj4gPiA+Pj4gbGV2ZXJhZ2VkIGFuZCB0aGUgZ3JvdXAgYmVuZWZpdHMgZnJvbSBhdmFp bGFibGUgc2VjdXJpdHkgYW5hbHlzaXMsDQo+PiA+ID4+PiBpbXBsZW1lbnRhdGlvbiwgYW5kIGRl cGxveW1lbnQgZXhwZXJpZW5jZS4gTW9yZW92ZXIsIGEgc3RhbmRhcmRpemVkDQo+PiA+ID4+PiBz b2x1dGlvbiBmb3IgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdp bGwgaGVscCB0bw0KPj4gPiA+Pj4gc3RpbXVsYXRlIHRoZSBkZXBsb3ltZW50IG9mIElvVCBkZXZp Y2VzIG9mZmVyaW5nIGluY3JlYXNlZCBzZWN1cml0eS4NCj4+ID4gPj4+DQo+PiA+ID4+PiBPbmNl IHByb2dyZXNzIGluIGlkZW50aWZ5aW5nIHN1aXRhYmxlIGNhbmRpZGF0ZSBzb2x1dGlvbnMgaGFz IGJlZW4NCj4+ID4gPj4+IG1hZGUgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB2ZXJpZnkgd2hldGhl ciB0aGUgc2FtZSBtZWNoYW5pc20gYXJlDQo+PiA+ID4+PiBhbHNvIGFwcGxpY2FibGUgYmV5b25k IHRoZSB1c2Ugb2YgQ29BUCBhbmQgRFRMUy4gSW4gcGFydGljdWxhciwgdGhlDQo+PiA+ID4+PiBh YmlsaXR5IHRvIHVzZSB0aGUgZGV2ZWxvcGVkIHNvbHV0aW9uIG92ZXIgSFRUUCBhbmQgVExTIHdp bGwgYmUNCj4+ID4gaW52ZXN0aWdhdGVkLg0KPj4gPiA+Pj4gRnVydGhlcm1vcmUsIHRvIGd1YXJh bnRlZSBzbW9vdGggdHJhbnNpdGlvbiB0aGUgaW50ZWdyYXRpb24gd2l0aA0KPj4gPiA+Pj4gZXhp c3RpbmcgZGVwbG95bWVudCB3aWxsIGJlIHN0dWRpZWQuIFRoaXMgcGFydGljdWxhcmx5IGNvbmNl cm5zIHRoZQ0KPj4gPiA+Pj4gdXNlIG9mIHByb3RvY29sIHRyYW5zbGF0aW9uIHByb3hpZXMuDQo+ PiA+ID4+Pg0KPj4gPiA+Pj4gVG8gYmUgc3VjY2Vzc2Z1bCB0aGlzIHdvcmtpbmcgZ3JvdXAgcmVx dWlyZXMgZXhwZXJ0aXNlIGluIHNlY3VyaXR5LA0KPj4gPiA+Pj4gcHJpdmFjeSwgYW5kIGEgZ29v ZCB1bmRlcnN0YW5kaW5nIG9mIHVzYWJpbGl0eSBpbiB0aGUgY29uc3RyYWluZWQNCj4+ID4gPj4+ IGVudmlyb25tZW50IHNwYWNlLiBUaGlzIHdvcmsgZG9lcyBub3QgbWFrZSB0aGUgYXNzdW1wdGlv biB0aGF0IHRoZQ0KPj4gPiA+Pj4gcGFydHkgb2ZmZXJpbmcgYXBwbGljYXRpb24gbGF5ZXIgc2Vy dmljZXMgaXMgYWx3YXlzIHRoZSBzYW1lIHBhcnR5DQo+PiA+ID4+PiBvZmZlcmluZyBuZXR3b3Jr IGFjY2VzcyBzZXJ2aWNlcy4NCj4+ID4gPj4+DQo+PiA+ID4+PiBUaGUgd29ya2luZyBncm91cCBo YXMgdGhlIGZvbGxvd2luZyB0YXNrcyAoaW4gdGhpcyBvcmRlcik6DQo+PiA+ID4+Pg0KPj4gPiA+ Pj4gMSkgVGhlIHdvcmtpbmcgZ3JvdXAgV2lraSBwYWdlcyB3aWxsIGJlIHVzZWQgdG8gZG9jdW1l bnQgdXNlIGNhc2VzLA0KPj4gPiA+Pj4gcmVxdWlyZW1lbnRzLCBhbmQgcHJvdG9jb2wgZGVzaWdu IGNyaXRlcmlhLiBUaGlzIHdvcmsgd2lsbCBndWlkZSB0aGUNCj4+ID4gPj4+IGlkZW50aWZpY2F0 aW9uIG9mIHN1aXRhYmxlIHByb3RvY29sIG1lY2hhbmlzbXMuDQo+PiA+ID4+Pg0KPj4gPiA+Pj4g MikgU2VsZWN0aW9uIG9mIGFuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3Rv Y29sIGZvcg0KPj4gPiA+Pj4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KPj4gPiA+Pj4NCj4+ ID4gPj4+IDMpIEV2YWx1YXRpb24gb2YgdGhlIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdXNlIHdp dGggSFRUUC9UTFMgYW5kDQo+PiA+ID4+PiBwcm94eSBkZXBsb3ltZW50cy4NCj4+ID4gPj4+DQo+ PiA+ID4+PiAtLS0tLQ0KPj4gPiA+Pj4NCj4+ID4gPj4+IENpYW8NCj4+ID4gPj4+IEhhbm5lcw0K Pj4gPiA+Pj4NCj4+ID4gPj4+IDxzaWduYXR1cmUuYXNjPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ID4+PiBBY2UgbWFpbGluZyBsaXN0DQo+PiA+ ID4+PiBBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCj4+ID4gPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+PiA+ID4+DQo+PiA+ID4+IFphY2gg U2hlbGJ5DQo+PiA+ID4+IERpcmVjdG9yIG9mIFRlY2hub2xvZ3kNCj4+ID4gPj4gQVJNIEludGVy bmV0IG9mIFRoaW5ncyBCVQ0KPj4gPiA+PiB3d3cuYXJtLmNvbTxodHRwOi8vd3d3LmFybS5jb20+ DQo+PiA+ID4+IG1vYmlsZTogKzEgKDQwOCkgMjAzLTk0MzQNCj4+ID4gPj4gU2t5cGU6IHpkc2hl bGJ5DQo+PiA+ID4+IExpbmtlZEluOiBmaS5saW5rZWRpbi5jb20vaW4vemFjaHNoZWxieS8NCj4+ ID4gPj4NCj4+ID4gPj4NCj4+ID4gPj4gLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cw0KPj4gPiA+PiBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4+ID4g Pj4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdA0KPj4gPiA+PiBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3INCj4+ID4gPj4gc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gIFRoYW5rIHlvdS4NCj4+ID4gPj4NCj4+ ID4gPj4gQVJNIExpbWl0ZWQsIFJlZ2lzdGVyZWQgb2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBD YW1icmlkZ2UgQ0IxIDlOSiwNCj4+ID4gPj4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMs IENvbXBhbnkgTm86ICAyNTU3NTkwIEFSTSBIb2xkaW5ncyBwbGMsDQo+PiA+ID4+IFJlZ2lzdGVy ZWQgb2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0ZXJl ZCBpbg0KPj4gPiA+PiBFbmdsYW5kICYgV2FsZXMsIENvbXBhbnkgTm86ICAyNTQ4NzgyDQo+PiA+ ID4+DQo+PiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiA+ID4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+ID4gPj4gQWNlQGlldGYub3JnPG1haWx0 bzpBY2VAaWV0Zi5vcmc+DQo+PiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYWNlDQo+PiA+ID4NCj4+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gPiA+IEFjZSBtYWlsaW5nIGxpc3QNCj4+ID4gPiBBY2VAaWV0 Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCj4+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FjZQ0KPj4gPiA+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+IEFjZUBp ZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2UNCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+DQo+PiBBY2VAaWV0 Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlDQo+DQo+IDxzbWltZS5wN3M+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gQWNlIG1haWxpbmcgbGlzdA0KPiBBY2VAaWV0Zi5v cmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hY2UNCg0KWmFjaCBTaGVsYnkNCkRpcmVjdG9yIG9mIFRlY2hub2xvZ3kNCkFSTSBJ bnRlcm5ldCBvZiBUaGluZ3MgQlUNCnd3dy5hcm0uY29tPGh0dHA6Ly93d3cuYXJtLmNvbT4NCm1v YmlsZTogKzEgKDQwOCkgMjAzLTk0MzQNClNreXBlOiB6ZHNoZWxieQ0KTGlua2VkSW46IGZpLmxp bmtlZGluLmNvbS9pbi96YWNoc2hlbGJ5Lw0KDQoNCi0tIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uICBUaGFuayB5b3UuDQoNCkFSTSBMaW1pdGVkLCBSZWdpc3RlcmVkIG9mZmljZSAxMTAgRnVs Ym91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdh bGVzLCBDb21wYW55IE5vOiAgMjU1NzU5MA0KQVJNIEhvbGRpbmdzIHBsYywgUmVnaXN0ZXJlZCBv ZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRnZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgJiBXYWxlcywgQ29tcGFueSBObzogIDI1NDg3ODINCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0 Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYWNlDQo= --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B07596SZXEMA501MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9 kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDc4MzAxNTkyOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzk0MTIxNDcyIDEwNDk5MDAyMzYgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyMDsNCglt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNt O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpI LUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDtJIHdvdWxkIG9iamVjdCB0byBhIHBoYXNlZCBj aGFydGVyIHRoYXQgcmVxdWlyZXMgdXMgdG8gcHVibGlzaCBvdXIgdXNlIGNhc2VzIGFuZCByZXF1 aXJlbWVudHMgYXMgUkZDcyBiZWZvcmUgd2UgZG8gYW55IHByb3RvY29sIHdvcmsuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxldOKAmXMgcmVtb3ZlIOKAnGluIHRoaXMgb3Jk ZXLigJ0gYmVmb3JlIHRoZSB0YXNrIGxpc3QgaW4gdGhlIGNoYXJ0ZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IFRoZSB3b3JraW5nIGdyb3VwIGhhcyB0 aGUgZm9sbG93aW5nIHRhc2tzPHU+IChpbiB0aGlzIG9yZGVyKTwvdT46PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDtJJ2QgYmUgcGVyZmVjdGx5IGhhcHB5IHdpdGggcHVi bGlzaGluZyB0aGVtIGFzIFJGQ3MgbGF0ZXIgaW4gdGhlIHByb2Nlc3MsIHRob3VnaC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIGdvdCBpdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+S2luZCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5LZXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4gQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddDQo8 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS7o+ihqCA8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TWFyZ2FyZXQgV2Fz c2VybWFuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hp gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4zPC9zcGFuPuaciDxzcGFu IGxhbmc9IkVOLVVTIj4xODwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDIxOjM4PGJyPg0K PC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IFphY2ggU2hlbGJ5OyByb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb208YnI+ DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gYWNlQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbQWNlXSBBQ0UgQ2hh cnRlciBQcm9wb3NhbCB2MC41PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlB1Ymxpc2hpbmcgdGhlIHJlcXVpcmVtZW50cyBhbmQgdXNlIGNhc2VzIGluIGFuIFJGQyBp cyBOT1QgdGhlIHNhbWUgdGhpbmcgYXMgZ2F0aW5nIG91ciBvdGhlciB3b3JrIG9uIHB1Ymxpc2hp bmcgdGhvc2UgdGhpbmdzIGZpcnN0IC0tIEkgd291bGQgb2JqZWN0IHRvIGEgcGhhc2VkIGNoYXJ0 ZXIgdGhhdCByZXF1aXJlcyB1cyB0byBwdWJsaXNoIG91ciB1c2UgY2FzZXMgYW5kIHJlcXVpcmVt ZW50cw0KIGFzIFJGQ3MgYmVmb3JlIHdlIGRvIGFueSBwcm90b2NvbCB3b3JrLCBhbmQgSSBsaWtl IHRoZSBpZGVhIG9mIHVzaW5nIGEgd2lraSB0byBjb2xsZWN0IGFuZCByZWZpbmUgdGhlbS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBzaG91bGQgcmVtZW1iZXIs IHRob3VnaCwgdGhhdCB3ZSB3aWxsIG5lZWQgdG8gaW52b2x2ZSBhIHdpZGUgcmFuZ2Ugb2YgSUVU RiBwYXJ0aWNpcGFudHMsIGluY2x1ZGluZyBtdWx0aXBsZSBJRVRGIHNlY3VyaXR5IGV4cGVydHMs IHRvIGJlIHN1Y2Nlc3NmdWwuICZuYnNwO05vdCBhbGwgb2YgdGhvc2UgcGVvcGxlIHdpbGwgaGF2 ZSB3b3JrZWQgaW4gdGhlIElvVC9lbWJlZGRlZCBzcGFjZSwNCiBzbyBkb2N1bWVudGluZyB0aGUg dXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZWFybHkgaW4gdGhlIHByb2Nlc3MgKG9uIGEgd2lr aSBwYWdlIGlzIGZpbmUpIHdpbGwgYmUgZXNzZW50aWFsIHRvIGFsbG93aW5nIHRoYXQgd2lkZXIg c2V0IG9mIElFVEYgcGFydGljaXBhbnRzIHRvIGVuZ2FnZSBjb25zdHJ1Y3RpdmVseS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSdkIHBlcnNvbmFsbHkgbGlrZSB0byBzZWUgdGhl IHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGNhcHR1cmVkIGluIGFuIGFjaGl2YWwgZm9ybSB0 aGF0IGNhbiBiZSByZWZlcmVuY2VkIGxhdGVyLCBiZWNhdXNlIEkgdGhpbmsgdGhlIHVzZSBjYXNl cywgaW4gcGFydGljdWxhciwgbWlnaHQgYmUgdXNlZnVsIGZvciBsYXRlciB3b3JrLiAmbmJzcDtJ J2QgYmUgcGVyZmVjdGx5IGhhcHB5DQogd2l0aCBwdWJsaXNoaW5nIHRoZW0gYXMgUkZDcyBsYXRl ciBpbiB0aGUgcHJvY2VzcywgdGhvdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPklmIHBlb3BsZSB3b3VsZCByYXRoZXIgdHJ5IHRvIGNhcHR1cmUgdGhlIG1ham9y IHVzZSBjYXNlcyBhbmQgbW90aXZhdGlvbnMgaW4gdGhlIHByb3RvY29sIHNwZWMgaW5zdGVhZCwg SSBndWVzcyB0aGF0IHdvdWxkIHdvcmsgZm9yIG1lLCBidXQgSSB3b3VsZCBzb21ld2hhdCBwcmVm ZXIgYW4gdW5jbHV0dGVyZWQgcHJvdG9jb2wgc3BlYyB0aGF0IHJlZmVycyB0byBzdXBwb3J0aW5n DQogaW5mb3JtYXRpb25hbCBkb2N1bWVudHMuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWFyZ2FyZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLSBPcmlnaW5hbCBtZXNz YWdlIC0tLS0tLS0tPGJyPg0KRnJvbSBaYWNoIFNoZWxieSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlph Y2guU2hlbGJ5QGFybS5jb20iPlphY2guU2hlbGJ5QGFybS5jb208L2E+Jmd0OyA8YnI+DQpEYXRl OiAwMy8xNC8yMDE0IDExOjMxIEFNIChHTVQtMDU6MDApIDxicj4NClRvIDxhIGhyZWY9Im1haWx0 bzpyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20iPnJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNv bTwvYT4gPGJyPg0KQ2MgPGEgaHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3Jn PC9hPiA8YnI+DQpTdWJqZWN0IFJlOiBbQWNlXSBBQ0UgQ2hhcnRlciBQcm9wb3NhbCB2MC41IDxi cj4NCjxicj4NCkFzIEkgbWVudGlvbmVkIGluIHRoZSBCb0YsIG15IGFkdmljZSB3b3VsZCBiZSB0 byBqdXN0IHVzZSBhIHdpa2kgdG8gY29sbGVjdCB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cy48 YnI+DQo8YnI+DQpOb3csIGlmIHdlIHdhbnQgdG8gd2FzdGUgdGhlIGZpcnN0IGhhbGYgeWVhciBi cmluaW5nIHN1Y2ggZHJhZnRzIHRocm91Z2ggdGhlIFJGQyBwcm9jZXNzIHRoZW4gZ28gYWhlYWQu IEZyb20gbXkgZXhwZXJpZW5jZSB0aGVzZSBraW5kcyBvZiB3b3JrIGl0ZW1zIGFyZSBqdXN0IGEg V0cgYmxhY2sgaG9sZS4gWW91IGNhbiBhbHdheXMgZG9jdW1lbnQgdGhlIGFzc3VtZWQgdXNlIGNh c2VzIHdpdGhpbiB0aGUgYWN0dWFsIHRlY2huaWNhbCBzcGVjaWZpY2F0aW9uDQogdG8gbWFrZSBp dCBjbGVhciB3aGF0IHByb2JsZW0gaXQgaXMgdHJ5aW5nIHRvIHNvbHZlLjxicj4NCjxicj4NClph Y2g8YnI+DQo8YnI+DQpPbiBNYXIgMTQsIDIwMTQsIGF0IDg6MDIgQU0sIFJvYmVydCBDcmFnaWUg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20iPnJvYmVydC5j cmFnaWVAZ3JpZG1lcmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgJiM0Mzsx IHRvIGJvdGggTWFyZ2FyZXQncyBzdGF0ZW1lbnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJvYmVy dDxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDEzLzAzLzIwMTQgMTA6NTUgQU0sIE1hcmdhcmV0IFdh c3Nlcm1hbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBQZXJzb25hbGx5LCBJIHdvdWxkIGFsc28gcmF0 aGVyIHNlZSB0aGUgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgcHVibGlzaGVkIGFzIGluZm9y bWF0aW9uYWxSRkNzLiZuYnNwOyBJIHRoaW5rIHRoYXQgYSB3aWtpIG1pZ2h0IGJlIGEgZ29vZCB3 YXkgdG8gY29sbGVjdCB0aGVtIGF0IGZpcnN0LCBidXQgSSB3b3VsZCBwcmVmZXIgdG8gYmUgc3Vy ZSB0aGF0IHdlIGhhdmUgY29uc2Vuc3VzIG9uIHRoZSBwcm9ibGVtKHMpIHdlIGFyZSB0cnlpbmcg dG8NCiBzb2x2ZS4mbmJzcDsgSSBhbHNvIHRoaW5rIGl0IHdpbGwgYmUgdXNlZnVsIHRvIGhhdmUg dGhlc2UgdGhpbmdzIGluIGFyY2hpdmFsIGZvcm0gbGF0ZXIuPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBJIGRvIG5vdCB0aGluayB0aGUgb3RoZXIgd29yayBvZiB0aGUgZ3JvdXAgc2hvdWxk IGJlIGdhdGVkIG9uIHRoZSByZXF1aXJlbWVudHMsIHRob3VnaCwgYXMgSSB0aGluayB0aGF0IGl0 IG1ha2VzIHNlbnNlIHRvIGV4cGxvcmUgaG93IGV4aXN0aW5nIHRlY2hub2xvZ2llcyBjb3VsZCBv ciBjb3VsZG4ndCBtZWV0IHRoZSByZXF1aXJlbWVudHMgdG8gaW5zdXJlIHRoYXQgb3VyIHJlcXVp cmVtZW50cyBhcmUgcmVhbGl0eS1iYXNlZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1h cmdhcmV0PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj4NCiZndDsmZ3Q7IEZy b20gTGlrZXBlbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tIj5saWtl cGVuZ0BodWF3ZWkuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBEYXRlOiAwMy8xMy8yMDE0IDQ6 MjggQU0gKEdNVC0wNTowMCk8YnI+DQomZ3Q7Jmd0OyBUbyBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2Zl bmlnQGdteC5uZXQ8L2E+Jmd0OyxHw7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpn b3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20iPmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTwv YT4mZ3Q7LFphY2ggU2hlbGJ5ICZsdDs8YSBocmVmPSJtYWlsdG86WmFjaC5TaGVsYnlAYXJtLmNv bSI+WmFjaC5TaGVsYnlAYXJtLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgQ2MgPGEgaHJlZj0i bWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1Ympl Y3QgUmU6IFtBY2VdIEFDRSBDaGFydGVyIFByb3Bvc2FsIHYwLjU8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0IHRoZSB1 c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGNhbiBoZWxwIHBlb3BsZSB0byB1bmRl cnN0YW5kIHdoYXQga2luZCBvZiBpc3N1ZXMgd2UgYXJlIHRyeWluZyB0byByZXNvbHZlLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBjYW4gc2VlIHNvbWUgdmFsdWVzIHRvIHB1Ymxpc2gg aXQgaW50byBSRkNzLiBJZiBpdCBpcyBhIHdpa2kgcGFnZSwgd2Ugd2lsbCBoYXZlIGxlc3MgcGVv cGxlIHRvIHJldmlldyBpdCBvciBpbXByb3ZlIGl0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgRXNwZWNpYWxseSB0aGUgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50IGRvY3VtZW50IGlzIGFs cmVhZHkgaW4gYSBnb29kIHNoYXBlIGFuZCBpdCBpcyByZWZlcmVuY2VkIHNldmVyYWwgdGltZXMg aW4gdGhlIG1haWxpbmcgbGlzdCB0byBpbnRyb2R1Y2Ugb3VyIHdvcmsgdG8gb3V0c2lkZS48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IEtpbmQgUmVnYXJkczxicj4NCiZndDsmZ3Q7IEtlcGVuZzxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyAtLS0tLTwvc3Bhbj7pgq7ku7bljp/ku7Y8c3BhbiBsYW5nPSJFTi1VUyI+ LS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDwvc3Bhbj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+OiBBY2UgWzxhIGhyZWY9Im1haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmFj ZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj7ku6Pooag8c3BhbiBsYW5nPSJFTi1VUyI+ IEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KJmd0OyZndDsgJmd0OyA8L3NwYW4+5Y+R6YCB5pe26Ze0 PHNwYW4gbGFuZz0iRU4tVVMiPjogMjAxNDwvc3Bhbj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Mzwv c3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTM8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMi PiA0OjMzPGJyPg0KJmd0OyZndDsgJmd0OyA8L3NwYW4+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4t VVMiPjogR8O2cmFuIFNlbGFuZGVyOyBaYWNoIFNoZWxieTxicj4NCiZndDsmZ3Q7ICZndDsgPC9z cGFuPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5v cmciPmFjZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDwvc3Bhbj7kuLvpopg8c3Bh biBsYW5nPSJFTi1VUyI+OiBSZTogW0FjZV0gQUNFIENoYXJ0ZXIgUHJvcG9zYWwgdjAuNTxicj4N CiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEhpIEdvZXJhbiw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBJIHJlYWQgYSBsaXR0bGUgYml0IGJldHdlZW4gdGhl IGxpbmVzIG9mIHlvdXIgbWFpbCBhbmQgeW91ciBtYWluIGNvbmNlcm4gaXMgdGhhdDxicj4NCiZn dDsmZ3Q7ICZndDsgeW91IHdhbnQgdG8gaGF2ZSBhbiBSRkMgcHVibGlzaGVkIHdpdGggeW91ciBu YW1lIG9uIGl0Ljxicj4NCiZndDsmZ3Q7ICZndDsgQSB3aWtpIHBhZ2UgdG8gZG9jdW1lbnQgdGhl IHJlcXVpcmVtZW50cywgYW5kIHVzZSBjYXNlcyBpcyBub3QgZ29vZCBlbm91Z2g8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IGZvciB5b3UuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsg Rm9yIHlvdSBwdXR0aW5nIHRoZSBkcmFmdCB0ZXh0IG9uIGEgV0cgd2lraSBmZWVscyBsaWtlIHdh c3RlZCB0aW1lLjxicj4NCiZndDsmZ3Q7ICZndDsgSXQgaXMganVzdCBhIGRpZmZlcmVudCBmb3Jt IG9mIGRvY3VtZW50aW5nIHRoZSB3b3JrLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IE15IGV4cGVyaWVuY2Ugd2l0aCB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBoYXMg bm90IGJlZW4gZ3JlYXQgaW4gdGhlIElFVEYuPGJyPg0KJmd0OyZndDsgJmd0OyBJbiBlc3NlbmNl IGV2ZXJ5b25lIHF1aWNrbHkgbW92ZXMgb24gb25jZSB0aGUgZ3JvdXAgZGVjaWRlcyBhYm91dCBh PGJyPg0KJmd0OyZndDsgJmd0OyBwYXJ0aWN1bGFyIHNvbHV0aW9uIGRpcmVjdGlvbi4gSXQgdGhl biBiZWNvbWVzIHZlcnkgaGFyZCAoZm9yIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsgY2hhaXJzKSB0 byBmaW5pc2ggdGhlIHJlcXVpcmVtZW50cyB3b3JrIHNpbmNlIG5vYm9keSB3YW50cyB0byByZXZp ZXcgb3IgbG9vazxicj4NCiZndDsmZ3Q7ICZndDsgYXQgdGhlbSBhbnltb3JlLjxicj4NCiZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGFy ZSBncmVhdCBkdXJpbmcgdGhlIGluaXRpYWwgcGFydCBvZiB0aGUgd29yayB0byBnZXQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7IGFuIHVuZGVyc3RhbmRpbmcgb2YgdGhlIG1haW4gY2hhbGxlbmdlcy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBIYXZpbmcgc2FpZCB0aGF0IEkgd2ls bCBsZWF2ZSBpdCB0byB0aGUgZ3JvdXAgdG8gZGVjaWRlIHdoYXQgdGhleSB3YW50IHRvIGRvOjxi cj4NCiZndDsmZ3Q7ICZndDsgUkZDcyBvciBXaWtpIHBhZ2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyBDaWFvPGJyPg0KJmd0OyZndDsgJmd0OyBIYW5uZXM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBQUzogUmVnYXJkaW5nIHlvdXIgb3RoZXIgY29t bWVudCBhYm91dCBwb2ludGluZyB0byB0aGUgY29uc3RyYWludCBuYXR1cmUgdG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IGV2ZXJ5IGl0ZW0uIFdlIGNhbiBkbyB0aGF0IGlmIHlvdSBmZWVsIGJldHRlciBi dXQgdGhlIGVudGlyZSBjaGFydGVyIHBhZ2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGFscmVhZHkgc2F5 cyAxMCB0aW1lcyB0aGF0IHdlIGFyZSBmb2N1c2luZyBvbiB0aGUgY29uc3RyYWludCBzcGFjZS48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEkgYW0gc3VyZSB0aGF0IHRoZSByZWFkZXIgd2lsbCBoYXZlIHVu ZGVyc3Rvb2QgdGhhdCB3aGVuIHRoZXkgZ2V0IHRvIHRoZSB0YXNrPGJyPg0KJmd0OyZndDsgJmd0 OyBsaXN0Ljxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyBPbiAwMy8xMi8yMDE0IDEwOjMyIEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6PGJy Pg0KJmd0OyZndDsgJmd0OyAmZ3Q7IEhhbm5lcywgWmFjaCBhbmQgYWxsLDxicj4NCiZndDsmZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBJIG11c3Qgc2F5IEkgZG9uwrl0IGZp bmQgdGhlIHRhc2sgbGlzdCBvZiB0aGUgY3VycmVudCBjaGFydGVyIHZlcnkgaGVscGZ1bDo8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgwrNUaGUgd29ya2lu ZyBncm91cCBoYXMgdGhlIGZvbGxvd2luZyB0YXNrcyAoaW4gdGhpcyBvcmRlcik6PGJyPg0KJmd0 OyZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IDEpIFRoZSB3b3JraW5nIGdy b3VwIFdpa2kgcGFnZXMgd2lsbCBiZSB1c2VkIHRvIGRvY3VtZW50IHVzZSBjYXNlcyw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzLCBhbmQgcHJvdG9jb2wgZGVzaWduIGNyaXRl cmlhLiBUaGlzIHdvcmsgd2lsbCBndWlkZSB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgaWRl bnRpZmljYXRpb24gb2Ygc3VpdGFibGUgcHJvdG9jb2wgbWVjaGFuaXNtcy48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgMikgU2VsZWN0aW9uIG9mIGFuIGF1 dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sIGZvcjxicj4NCiZndDsmZ3Q7 ICZndDsgJmd0OyBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuPGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IDMpIEV2YWx1YXRpb24gb2YgdGhlIGNhbmRpZGF0 ZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggSFRUUC9UTFMgYW5kPGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7IHByb3h5IGRlcGxveW1lbnRzLsKyPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyAmZ3Q7IFRoaXMgbGlzdCBkb2VzIG5vdCBnaXZlIG11Y2ggbW9yZSBkZXRhaWxz IGFib3V0IHRoZSB3b3JrIHRvIGJlPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IGNvbmR1Y3RlZCB0 aGFuIGlzIGFscmVhZHkgZ2l2ZW4gYnkgdGhlIHRpdGxlIG9mIHRoZSBXRy4gVG8gYSBwZXJzb248 YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgbm90IGhhdmluZyBmb2xsb3dlZCB0aGUgZGlzY3Vzc2lv biwgdGhlIGltcHJlc3Npb24gaXMgdGhhdCB0aGUgd29yazxicj4NCiZndDsmZ3Q7ICZndDsgJmd0 OyBzdGFydHMgZnJvbSBzY3JhdGNoIGFuZCB0aGVyZSBpcyBubyBjbGVhciB1bmRlcnN0YW5kaW5n IG9mIHdoYXQgdG8gZG8uPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyAmZ3Q7IElmIHdlIGNhbsK5dCBmb3JtdWxhdGUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBm aXJzdCBzdGVwIHRvd2FyZHMgYTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBzb2x1dGlvbiBpbiBz b21lIGRlZ3JlZSBvZiBkZXRhaWwgYmVmb3JlIHN0YXJ0aW5nIHRoZSBXRyB0aGF0IHdpbGw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgYW55d2F5IGJlIHRoZSBmaXJzdCB0YXNrIHRvIGRvLCBzbyBs ZXTCuXMgdHJ5IHRvIGdldCBzb21ldGhpbmcgaW4gd3JpdGluZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgJnF1 b3Q7MSkgVGhlIHdvcmtpbmcgZ3JvdXAgV2lraSBwYWdlcyB3aWxsIGJlIHVzZWQgdG8gZG9jdW1l bnQgdXNlIGNhc2VzLDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHMsIGFuZCBw cm90b2NvbCBkZXNpZ24gY3JpdGVyaWEuIFRoaXMgd29yayB3aWxsIGd1aWRlIHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsgJmd0OyBpZGVudGlmaWNhdGlvbiBvZiBzdWl0YWJsZSBwcm90b2NvbCBtZWNo YW5pc21zLiZxdW90Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsg Jmd0OyBUaGlzIGlzIGhpZGluZyB0aGUgZmFjdCB0aGF0IHRoZXJlIGhhcyBiZWVuIDYgbW9udGhz IG9mIHdvcmsgb24gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IHVzZSBjYXNlIGFuZCByZXF1 aXJlbWVudHMgZHJhZnQgKHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgd2FzPGJyPg0K Jmd0OyZndDsgJmd0OyAmZ3Q7IHN1Ym1pdHRlZCB0byBDb1JFIGluIElFVEY4OCksIHdoaWNoIG5v IG9uZSBoYXMgZGlzYWdyZWVkIGlzIHNldHRpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgdGhl IHN0YWdlIGZvciB0aGlzIHdvcmsuIExvb2sgYXQgcGFyYWxsZWwgdGhyZWFkcyBvbiB0aGlzIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyB3aGVyZSBwZW9wbGUgYXNrIHdoZXRo ZXIgdGhlaXIgcGFydGljdWxhciBzZWN1cml0eS1mb3ItSW9UIGRyYWZ0IGZpdHM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7ICZndDsgaW50byBBQ0UuIFRoZSBhbnN3ZXIgSGFubmVzIGlzIGdpdmluZyBpcyBj b3JyZWN0bHk6IHRoZSBzY29wZSBvZiB0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IHdvcmsg aXMgd2hhdCBpcyBvdXRsaW5lZCBieSB0aGUgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50cyBkcmFm dC4gSTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBkb27CuXQgbWluZCB1c2luZyB0aGUgV2lraSBh cyBhIHdvcmtpbmcgdG9vbCBidXQgdGhpcyBkb2VzIG5vdCBnaXZlPGJyPg0KJmd0OyZndDsgJmd0 OyAmZ3Q7IHRyYWNlYWJpbGl0eSBhIHllYXIgbGF0ZXIuIEFuZCBJIGRvbsK5dCBzZWUgdGhlIHBv aW50IGlmIGNvcHlpbmcgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IHVzZSBjYXNlIGRvY3Vt ZW50IGludG8gYSBXaWtpIHBhZ2UgLSByZWFkIHRoZSBkcmFmdCBhbmQgcHJvdmlkZSB5b3VyPGJy Pg0KJmd0OyZndDsgJmd0OyBjb21tZW50cyE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7ICZndDsgV2hlbiBpdCBjb21lcyB0byBwcm90b2NvbCBkZXNpZ24gY3JpdGVy aWEsIEkgYWdyZWUgdGhhdCBtb3JlIHdvcmsgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgbmVl ZGVkLCBmb3Igd2hpY2ggdGhlIFdpa2kgbWF5IGJlIHN1aXRhYmxlLiBOZXZlcnRoZWxlc3MgSSBp bnNpc3Qgb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgZG9jdW1lbnRpbmcgdGhlIGRlc2lnbiBj cml0ZXJpYSBhbmQgaXRzIHJhdGlvbmFsZSBzaW5jZSB0aGF0IHByb3ZpZGVzPGJyPg0KJmd0OyZn dDsgJmd0OyAmZ3Q7IGEgbWVhbnMgZm9yIHRyYWNlYWJpbGl0eS4gTWFrZSBpdCBhIG1pbGVzdG9u ZSB0byBoYXZlIGEgZHJhZnQgd2l0aDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBhc3N1bXB0aW9u cyBhbmQgZGVzaWduIGNyaXRlcmlhJm5ic3A7ICh5b3UgbWF5IGluY2x1ZGUgwrNhcmNoaXRlY3R1 cmXCsiBpbjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyB0aGlzIGRvY3VtZW50KS4gVGhpcyB3b3Jr IGlzIGFueXdheSBhIHByZS1yZXF1aXNpdGUgZm9yIGNvbWluZyB0byBhPGJyPg0KJmd0OyZndDsg Jmd0OyAmZ3Q7IHNvbHV0aW9uLCBhbmQgb25jZSB5b3UgaGF2ZSB0aGlzIGNvbnRlbnQsIHRoZSBj YW5kaWRhdGUgc29sdXRpb25zIGFyZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBtdWNoIGVhc2ll ciBldmFsdWF0ZWQuPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7IFNvLCBjaGFuZ2UgMSkgdG8gc3RhdGUgc29tZXRoaW5nIGxpa2U8YnI+DQomZ3Q7Jmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgJnF1b3Q7McK5ICk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsgYSkgY29tcGxldGUgdGhlIHdvcmsgb24gdXNlIGNhc2UgYW5kIHJlcXVpcmVt ZW50czxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBiKSB1c2UgV2lraSBwYWdlcyBmb3IgbGlzdGlu ZyBhc3N1bXB0aW9ucyBhbmQgcHJvdG9jb2wgZGVzaWduPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7 IGNyaXRlcmlhLCBkb2N1bWVudCB0aGUgcmVzdWx0IGluIGEgZHJhZnQmcXVvdDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgUHJveHkgZGVwbG95bWVudCBh c3BlY3RzIGZpdHMgd2VsbCBpbnRvIDFiKSZuYnNwOyBbbW9yZSBpbiBzZXBhcmF0ZTxicj4NCiZn dDsmZ3Q7ICZndDsgJmd0OyB1cGNvbWluZyBtYWlsXTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyAyKSBTZWxlY3Rp b24gb2YgYW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9yPGJy Pg0KJmd0OyZndDsgJmd0OyAmZ3Q7IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgSGVyZSBJwrltIG1pc3Npbmcg YW1vbmcgb3RoZXIgdGhpbmdzIHRoZSBzcGVjaWZpYyBwcm9ibGVtIHN0YXRlbWVudC48YnI+DQom Z3Q7Jmd0OyAmZ3Q7ICZndDsgVGhlIHByZWxpbWluYXJ5IGNvbmNsdXNpb25zIGZyb20gdGhlIHVz ZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZHJhZnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgZm9y bWVkIHRoZSBiYXNpcyBmb3IgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFzIHByZXNlbnRlZCBpbiB0 aGUgQk9GOiBXZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBsYWNrIGEgbWVjaGFuaXNtIGZvciBk eW5hbWljIGFuZCBmaW5lIGdyYWluZWQgYWNjZXNzIGNvbnRyb2wgZm9yPGJyPg0KJmd0OyZndDsg Jmd0OyAmZ3Q7IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgVGhlIHByb2Nlc3MgaGVyZSBzaG91bGQgYmUgdG86 PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7ICZxdW90OzLCuSkgaWRlbnRpZnkgc3VpdGFibGUgcHJv dG9jb2wgbWVjaGFuaXNtcyBhbmQgbWF0Y2ggY2FuZGlkYXRlPGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyBhZ2FpbnN0IHJl cXVpcmVtZW50cyBhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgZGVzaWduIGNyaXRlcmlhLCBp biBwYXJ0aWN1bGFyIGFkZHJlc3NpbmcgZHluYW1pYyBhbmQgZmluZSBncmFpbmVkPGJyPg0KJmd0 OyZndDsgJmd0OyAmZ3Q7IGFjY2VzcyBjb250cm9sIHN1aXRhYmxlIGZvciBDb0FQIHJlc291cmNl IGFjY2VzcyByZXF1ZXN0cyBpbiBjb25zdHJhaW5lZDxicj4NCiZndDsmZ3Q7ICZndDsgZW52aXJv bm1lbnRzLiZxdW90Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyAzKSBF dmFsdWF0aW9uIG9mIHRoZSBjYW5kaWRhdGUgc29sdXRpb24gZm9yIHVzZSB3aXRoIEhUVFAvVExT IGFuZDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBwcm94eSBkZXBsb3ltZW50cy7Csjxicj4NCiZn dDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsgJmd0OyBBcyBtZW50aW9uZWQgYWJvdmUsIHByb3h5IGRlcGxveW1lbnRzIGNvdWxkIGJlIGNv bnNpZGVyZWQgYXMgcGFydCBvZjxicj4NCiZndDsmZ3Q7ICZndDsgMcK5YikuPGJyPg0KJmd0OyZn dDsgJmd0OyAmZ3Q7IEluIDLCuSkgaXQgaXMgYWxyZWFkeSBzdGF0ZWQgdGhhdCBpbiBwYXJ0aWN1 bGFyIHdlIHNob3VsZCBjb25zaWRlciBDb0FQPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IG9uIGlu dGVyZmFjZSAoSUkpLiBBcyBmb3IgdXNlIG9mIG90aGVyIHByb3RvY29scyBiZXNpZGVzIENvQVAg dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyBpc3N1ZSBpcyBvcnRob2dvbmFsIHRvIHRoaXMg c28gSSBsZWF2ZSB0aGF0IG91dCBmcm9tIHRoaXMgZGlzY3Vzc2lvbi48YnI+DQomZ3Q7Jmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgR8O2cmFuPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7IE9uIDExLzAzLzE0IDE2OjQ5LCAmcXVvdDtaYWNoIFNoZWxieSZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOlphY2guU2hlbGJ5QGFybS5jb20iPlphY2guU2hlbGJ5QGFybS5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7IEhhbm5lcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyBJIGFtIGhhcHB5IHdpdGggdGhpcyBjaGFydGVyIHdpdGggb25lIGV4Y2VwdGlv bi4gVGhlIHByb3h5IGl0ZW0gaGVyZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgc2VlbXMg dG8gYmUgbW9yZSBvZiBhIGRpc3RyYWN0aW9uIHRoYW4gYW55dGhpbmcgZWxzZSwgYW5kIHdpbGw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IHByb2JhYmx5IHJlc3VsdCBpbiBpbmNyZWFzZWQg Y29tcGxleGl0eS4gV2FzIHByb3h5IHN1cHBvcnQgbWF5YmUganVzdDxicj4NCiZndDsmZ3Q7ICZn dDsgJmd0OyZndDsgYSBtaXN1bmRlcnN0YW5kaW5nPyBEbyB3ZSByZWFsbHkgc2VlIHRoZSBuZWVk IGZvciBhIHByb3h5IGluIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgbWlkZGxlIG9m IEkgb3IgSUlJPzxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 ICZndDsmZ3Q7IEkgdGhpbmsgd2hhdCB3ZSByZWFsbHkgd2FudCBoZXJlIGlzIHRvIG1ha2Ugc3Vy ZSB0aGF0IGUuZy4gZXZlbjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgdGhyb3VnaCBJIGlz IGJhc2VkIG9uIEhUVFAvVExTLCBJSSBhbmQgSUlJIGZvciBleGFtcGxlIGNhbiBydW48YnI+DQom Z3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IENvQVAvRFRMUy4gSW4gb3RoZXIgd29yZHMsIHNvbWUgaW50 ZXJmYWNlcyBjYW4gYmUgY29uc3RyYWluZWQgd2hpbGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7IG90aGVycyBhcmUgbm90LiBJIHRoaW5rIHRoZSBjaGFydGVyIGFscmVhZHkgY292ZXJzIHRo aXMgZmluZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7Jmd0OyBTbyBteSBwcm9wb3NhbCB3b3VsZCBiZSB0byByZW1vdmUgdGhlIG1lbnRpb24gb2Yg cHJvdG9jb2wgdHJhbnNsYXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IHByb3hpZXMu IElmIHdlIHJlYWxseSBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgc29tZSBkYXkgaW4gdGhlIGZ1dHVy ZSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IGl0IGNvdWxkIGJlIHRhY2tsZWQgdGhlbi48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBa YWNoPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsgT24gTWFyIDExLCAyMDE0LCBhdCAxMjo1MCBBTSwgSGFubmVzIFRzY2hvZmVuaWc8YnI+DQom Z3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldCI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBI aSBhbGwsPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyBJIGhhdmUgdGFrZW4gdGhlIGZlZWRiYWNrIGZyb20gdGhlIG1lZXRpbmcg YW5kIHRoZSByZWNlbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBkaXNjdXNzaW9u cyBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBwcm9kdWNlZCBhIG5ldyBzdHJhd21hbiBwcm9wb3Nh bC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0 OyZndDsmZ3Q7IFRoZSBjaGFuZ2VzIGluY2x1ZGU6PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgKiBBZGRlZCB0aGUgZm9jdXMgb24gRFRMUy9Db0FQIHdpdGggYW4gaW5kaWNhdGlvbiB0 aGF0IHdlIHdpbGwgY2hlY2s8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhIGNhbmRp ZGF0ZSBzb2x1dGlvbiBmb3Igc3VpdGFiaWxpdHkgd2l0aCBIVFRQL1RMUy48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAqIEFkZGVkIHRleHQgdG8gaW5kaWNhdGUgdGhhdCB3ZSB3aWxs IGFsc28gdmVyaWZ5IHRoZSBzdWl0YWJpbGl0eSBvZjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IHRoZSBzb2x1dGlvbiBmb3IgdXNlIHdpdGggcHJvdG9jb2wgdHJhbnNsYXRpb24gcHJv eGllcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAqIFNpbXBsaWZpZWQgdGhlIHRh c2sgbGlzdCBieSByZW1vdmluZyBzb2x1dGlvbiBzcGVjaWZpYyBpdGVtcy48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAqIE1lcmdlZCBzZXZlcmFsIGl0ZW1zIG9uIHRoZSB0YXNrIGxp c3QgKHVzZSBjYXNlcywgcmVxdWlyZW1lbnRzLDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IGFuZCBwcm90b2NvbCBkZXNpZ24gZ3VpZGVsaW5lcykuIEZvbGxvd2VkIHRoZSBzdWdnZXN0 aW9uIHRvIHVzZSBvZiBhPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgV2lraSBmb3Ig Y2FwdHVyaW5nIHRob3NlLjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgV2hhdCBkbyB5b3UgdGhpbms/PGJyPg0KJmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAtLS0tLTxi cj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgRHJhZnQgQ2hhcnRlciBWMC41IC0gQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRp b24gZm9yPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgQ29uc3RyYWluZWQgRW52aXJv bm1lbnQgKEFDRSk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IFRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9j b2xzIGZvciB1c2UgaW4gZW52aXJvbm1lbnRzPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSwgYW5kIHBv d2VyLiBJdCB3YXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBvYnNlcnZlZCB0aGF0 IEludGVybmV0IHByb3RvY29scyBjYW4gYmUgYXBwbGllZCB0byB0aGVzZSBjb25zdHJhaW5lZDxi cj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGVudmlyb25tZW50cywgb2Z0ZW4gb25seSBy ZXF1aXJpbmcgbWlub3IgdHdlYWtpbmcgYW5kIHByb2ZpbGluZy4gSW48YnI+DQomZ3Q7Jmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyBvdGhlciBjYXNlcywgbmV3IHByb3RvY29scyBoYXZlIGJlZW4gZGVm aW5lZCB0byBhZGRyZXNzIHRoZSBzcGVjaWZpYzxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IHJlcXVpcmVtZW50cyBvZiBjb25zdHJhaW5lZCBkZXZpY2VzIGFuZCBuZXR3b3Jrcy4gQW4g ZXhhbXBsZSBvZiBzdWNoPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYSBwcm90b2Nv bCBpcyB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLjxicj4NCiZn dDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGNvbXBvbmVudHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyBBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIHF1ZXN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYWxz byBhcmlzZSBpbiBlbnZpcm9ubWVudHMgd2l0aCBjb25zdHJhaW5lZCBub2RlcyBhbmQgbmV0d29y a3MuIEZvcjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGV4YW1wbGUsIGEgZG9vciBs b2NrIGhhcyB0byBhdXRob3JpemUgdGhlIHBlcnNvbiBzZWVraW5nIGFjY2Vzczxicj4NCiZndDsm Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHVzaW5nIGEgJnF1b3Q7ZGlnaXRhbCBrZXkmcXVvdDsuIFdo ZXJlIGFyZSB0aGUgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMgc3RvcmVkPzxicj4NCiZndDsmZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IEhvdyBkb2VzIHRoZSBkaWdpdGFsIGtleSBjb21tdW5pY2F0ZSB3 aXRoIHRoZSBsb2NrPyBEb2VzIHRoZSBsb2NrPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsgaW50ZXJhY3Qgd2l0aCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBvYnRhaW4gYXV0aG9y aXphdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGluZm9ybWF0aW9uPyBIb3cg Y2FuIGFjY2VzcyBiZSBncmFudGVkIHRvIG90aGVyIHBlcnNvbnMgdGVtcG9yYXJpbHk/PGJyPg0K Jmd0OyZndDsgJmd0OyBIb3cgY2FuIGFjY2VzcyBiZSByZXZva2VkPzxicj4NCiZndDsmZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7IFRoZXNlIHR5cGVzIG9mIHF1ZXN0aW9ucyBoYXZlIGJlZW4gYW5zd2Vy ZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsg Zm9yIHVzZSBjYXNlcyBvdXRzaWRlIHRoZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudC4gQnV0IGlu PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgY29uc3RyYWluZWQgZW52aXJvbm1lbnQs IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHBvc2UgY2hhbGxlbmdlcyBmb3I8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHkgcHJvdG9jb2xz Ljxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsgVGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5IGluIGRldmVsb3BpbmcgdGhyZWUg cGFydHkgYXV0aGVudGljYXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhbmQg YXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhh bXBsZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBpbmNsdWRlIEtlcmJlcm9zLCB0 aGUgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKSwgdGhlPGJyPg0KJmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgQXV0aGVudGljYXRpb24sIEF1dGhvcml6YXRpb24sIGFuZCBBY2NvdW50 aW5nIChBQUEpIGluZnJhc3RydWN0dXJlLDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IGFuZCB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgKE9BdXRoKS4gQWxsIHRoZXNlIHBy b3RvY29sczxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGVuam95IHdpZGVzcHJlYWQg ZGVwbG95bWVudCBvbiB0aGUgSW50ZXJuZXQuIEFsdGhvdWdoIHRoZXkgYWxsIGFpbTxicj4NCiZn dDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHRvIHNvbHZlIGEgc2ltaWxhciBnb2FsLCBhdCBhbiBh YnN0cmFjdCBsZXZlbCwgdGhleSBvZmZlciBxdWl0ZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kIHV0aWxpemUgZGlmZmVyZW50IG1lc3NhZ2Ug ZXhjaGFuZ2VzLiBUaGVzZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGRpZmZlcmVu Y2VzIGFyZSBtb3RpdmF0ZWQgYnkgdGhlIG1haW4gZGVwbG95bWVudCB1c2UgY2FzZXMgdGhleSB3 ZXJlPGJyPg0KJmd0OyZndDsgJmd0OyBkZXNpZ25lZCBmb3IuPGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBSZXF1aXJlbWVudHMg ZGVyaXZlZCBmcm9tIHVzZSBjYXNlcyBpbmRpY2F0ZSB0aGUgc3VpdGFiaWxpdHkgb2Y8YnI+DQom Z3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhbHJlYWR5IGV4aXN0aW5nIHdvcmssIHN1Y2ggYXMg T0F1dGgsIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkPGJyPg0KJmd0OyZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsgZW52aXJvbm1lbnRzLiBUaGVzZSBwcm90b2NvbHMgd2VyZSwgaG93ZXZlciwg bm90IG9wdGltaXplZCBmb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBjb25zdHJh aW5lZCBlbnZpcm9ubWVudHMuIEFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHRoYXQgbmVlZCB0byBi ZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHRha2VuIGludG8gYWNjb3VudCBhcmUg dGhlIGxhY2sgb2YgYSBzdWl0YWJsZSB1c2VyLWludGVyZmFjZSBmb3I8YnI+DQomZ3Q7Jmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyBvYnRhaW5pbmcgdGhlIGNvbnNlbnQgb2YgdGhlIHVzZXIgYW5kIHRo ZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBk ZXZpY2VzIHRvIGNvbnRhY3QgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4gcmVhbC10aW1lIHdp dGggZXZlcnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhY2Nlc3MgcmVxdWVzdCBk dWUgdG8gaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSwgZXRjLjxicj4NCiZndDsmZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyB3b3JraW5n IGdyb3VwIHRoZXJlZm9yZSBhaW1zIGZvciBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3I8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXph dGlvbiB0byBlbmFibGUgYXV0aG9yaXplZCBhY2Nlc3MgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyByZXNvdXJjZXMgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBBcyBhIHN0 YXJ0aW5nIHBvaW50LCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyB3b3JraW5n IGdyb3VwIHdpbGwgYXNzdW1lIHRoYXQgYWNjZXNzIHRvIHJlc291cmNlcyBvZmZlcmVkIGJ5IGE8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyByZXNvdXJjZSBzZXJ2ZXIgYnkgYSBjbGll bnQgZGV2aWNlcyB0YWtlcyBwbGFjZSB1c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0ZWQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7IGJ5IERUTFMuPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgQm90 aCByZXNvdXJjZSBzZXJ2ZXIgYW5kIGNsaWVudCBtYXkgYmUgcmVzb3VyY2UgY29uc3RyYWludC4g VGhpczxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGFjY2VzcyB3aWxsIGJlIG1lZGlh dGVkIGJ5IGFuIGF1dGhvcml6YXRpb24gc2VydmVyLCB3aGljaCBkb2VzIG5vdDxicj4NCiZndDsm Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHN1ZmZlciBmcm9tIHRoZSBzYW1lIHJlc291cmNlIGxpbWl0 YXRpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgRXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24g cHJvdG9jb2xzIGFyZSB1c2VkIGFuZDxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHJl LWFwcGxpZWQgZm9yIHVzZSB3aXRoIGNvbnN0cmFpbmVkIGRldmljZXMsIHdoZXJlIGFwcGxpY2Fi bGUuIFRoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyByZXF1aXJlcyByZWxldmFu dCBzcGVjaWZpY2F0aW9ucyB0byBiZSByZXZpZXdlZCBmb3Igc3VpdGFiaWxpdHksPGJyPg0KJmd0 OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgc2VsZWN0aW5nIGEgc3Vic2V0IG9mIHRoZW0sIHJlc3Ry aWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsgdGhlIHNwZWNpZmljYXRpb25zLiBTb21lIGZ1bmN0aW9uYWxpdGllcyBtYXksIGhv d2V2ZXIsIG5vdCBiZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGF2YWlsYWJsZSBp biBleGlzdGluZyBwcm90b2NvbHMgYW5kIGZvciB0aG9zZSBjYXNlcyBuZXc8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBmdW5jdGlvbmFsaXR5IGhhcyB0byBiZSBzdGFuZGFyZGl6ZWQu IFRodXMsIGV4aXN0aW5nIHdvcmsgY2FuIGJlPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsgbGV2ZXJhZ2VkIGFuZCB0aGUgZ3JvdXAgYmVuZWZpdHMgZnJvbSBhdmFpbGFibGUgc2VjdXJp dHkgYW5hbHlzaXMsPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgaW1wbGVtZW50YXRp b24sIGFuZCBkZXBsb3ltZW50IGV4cGVyaWVuY2UuIE1vcmVvdmVyLCBhIHN0YW5kYXJkaXplZDxi cj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHNvbHV0aW9uIGZvciBmZWRlcmF0ZWQgYXV0 aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gd2lsbCBoZWxwIHRvPGJyPg0KJmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgc3RpbXVsYXRlIHRoZSBkZXBsb3ltZW50IG9mIElvVCBkZXZpY2Vz IG9mZmVyaW5nIGluY3JlYXNlZCBzZWN1cml0eS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IE9uY2UgcHJvZ3Jlc3MgaW4gaWRl bnRpZnlpbmcgc3VpdGFibGUgY2FuZGlkYXRlIHNvbHV0aW9ucyBoYXMgYmVlbjxicj4NCiZndDsm Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IG1hZGUgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB2ZXJpZnkg d2hldGhlciB0aGUgc2FtZSBtZWNoYW5pc20gYXJlPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgYWxzbyBhcHBsaWNhYmxlIGJleW9uZCB0aGUgdXNlIG9mIENvQVAgYW5kIERUTFMuIElu IHBhcnRpY3VsYXIsIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGFiaWxpdHkg dG8gdXNlIHRoZSBkZXZlbG9wZWQgc29sdXRpb24gb3ZlciBIVFRQIGFuZCBUTFMgd2lsbCBiZTxi cj4NCiZndDsmZ3Q7ICZndDsgaW52ZXN0aWdhdGVkLjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IEZ1cnRoZXJtb3JlLCB0byBndWFyYW50ZWUgc21vb3RoIHRyYW5zaXRpb24gdGhlIGlu dGVncmF0aW9uIHdpdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBleGlzdGluZyBk ZXBsb3ltZW50IHdpbGwgYmUgc3R1ZGllZC4gVGhpcyBwYXJ0aWN1bGFybHkgY29uY2VybnMgdGhl PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdXNlIG9mIHByb3RvY29sIHRyYW5zbGF0 aW9uIHByb3hpZXMuPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBUbyBiZSBzdWNjZXNzZnVsIHRoaXMgd29ya2luZyBncm91cCBy ZXF1aXJlcyBleHBlcnRpc2UgaW4gc2VjdXJpdHksPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgcHJpdmFjeSwgYW5kIGEgZ29vZCB1bmRlcnN0YW5kaW5nIG9mIHVzYWJpbGl0eSBpbiB0 aGUgY29uc3RyYWluZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBlbnZpcm9ubWVu dCBzcGFjZS4gVGhpcyB3b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBwYXJ0eSBvZmZlcmluZyBhcHBsaWNhdGlv biBsYXllciBzZXJ2aWNlcyBpcyBhbHdheXMgdGhlIHNhbWUgcGFydHk8YnI+DQomZ3Q7Jmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyBvZmZlcmluZyBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlcy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IFRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIHRhc2tzIChpbiB0aGlzIG9yZGVy KTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0 OyZndDsmZ3Q7IDEpIFRoZSB3b3JraW5nIGdyb3VwIFdpa2kgcGFnZXMgd2lsbCBiZSB1c2VkIHRv IGRvY3VtZW50IHVzZSBjYXNlcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyByZXF1 aXJlbWVudHMsIGFuZCBwcm90b2NvbCBkZXNpZ24gY3JpdGVyaWEuIFRoaXMgd29yayB3aWxsIGd1 aWRlIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGlkZW50aWZpY2F0aW9uIG9m IHN1aXRhYmxlIHByb3RvY29sIG1lY2hhbmlzbXMuPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAyKSBTZWxlY3Rpb24gb2YgYW4g YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgZm9yPGJyPg0KJmd0OyZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLjxicj4NCiZndDsm Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgMykg RXZhbHVhdGlvbiBvZiB0aGUgY2FuZGlkYXRlIHNvbHV0aW9uIGZvciB1c2Ugd2l0aCBIVFRQL1RM UyBhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBwcm94eSBkZXBsb3ltZW50cy48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IC0tLS0tPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBDaWFvPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsg SGFubmVzPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmbHQ7c2lnbmF0dXJlLmFzYyZndDtfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IEFjZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86QWNlQGlldGYub3JnIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxi cj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IFph Y2ggU2hlbGJ5PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBEaXJlY3RvciBvZiBUZWNobm9s b2d5PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBBUk0gSW50ZXJuZXQgb2YgVGhpbmdzIEJV PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmFybS5jb20i Pnd3dy5hcm0uY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgbW9iaWxlOiAmIzQz OzEgKDQwOCkgMjAzLTk0MzQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IFNreXBlOiB6ZHNo ZWxieTxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgTGlua2VkSW46IGZpLmxpbmtlZGluLmNv bS9pbi96YWNoc2hlbGJ5Lzxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyAtLSBJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzPGJy Pg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsm Z3Q7IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvcjxi cj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IG1lZGl1bS4mbmJzcDsgVGhhbmsgeW91Ljxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IEFSTSBMaW1pdGVkLCBSZWdpc3RlcmVkIG9m ZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosPGJyPg0KJmd0OyZndDsg Jmd0OyAmZ3Q7Jmd0OyBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMsIENvbXBhbnkg Tm86Jm5ic3A7IDI1NTc1OTAgQVJNIEhvbGRpbmdzIHBsYyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZn dDsmZ3Q7IFJlZ2lzdGVyZWQgb2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0Ix IDlOSiwgUmVnaXN0ZXJlZCBpbjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyZndDsgRW5nbGFuZCAm YW1wOyBXYWxlcywgQ29tcGFueSBObzombmJzcDsgMjU0ODc4Mjxicj4NCiZndDsmZ3Q7ICZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyBB Y2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86QWNlQGlldGYub3JnIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PGJyPg0KJmd0OyZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7IEFjZSBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOkFjZUBp ZXRmLm9yZyI+QWNlQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsgJmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IEFjZSBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86QWNlQGlldGYub3JnIj5BY2VAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IEFjZSBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpBY2VAaWV0Zi5v cmciPkFjZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2U8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgJmx0O3NtaW1lLnA3cyZndDtf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg QWNlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOkFjZUBpZXRmLm9yZyI+ QWNlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYWNlPC9hPjxicj4NCjxicj4NClphY2ggU2hlbGJ5PGJyPg0KRGlyZWN0b3Igb2YgVGVjaG5v bG9neTxicj4NCkFSTSBJbnRlcm5ldCBvZiBUaGluZ3MgQlU8YnI+DQo8YSBocmVmPSJodHRwOi8v d3d3LmFybS5jb20iPnd3dy5hcm0uY29tPC9hPjxicj4NCm1vYmlsZTogJiM0MzsxICg0MDgpIDIw My05NDM0PGJyPg0KU2t5cGU6IHpkc2hlbGJ5PGJyPg0KTGlua2VkSW46IGZpLmxpbmtlZGluLmNv bS9pbi96YWNoc2hlbGJ5Lzxicj4NCjxicj4NCjxicj4NCi0tIElNUE9SVEFOVCBOT1RJQ0U6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55DQogcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55 IG1lZGl1bS4mbmJzcDsgVGhhbmsgeW91Ljxicj4NCjxicj4NCkFSTSBMaW1pdGVkLCBSZWdpc3Rl cmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcywgQ29tcGFueSBObzombmJzcDsgMjU1NzU5MDxicj4N CkFSTSBIb2xkaW5ncyBwbGMsIFJlZ2lzdGVyZWQgb2ZmaWNlIDExMCBGdWxib3VybiBSb2FkLCBD YW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzLCBDb21w YW55IE5vOiZuYnNwOyAyNTQ4NzgyPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOkFjZUBpZXRmLm9yZyI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FjZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B07596SZXEMA501MBSchi_-- From nobody Wed Mar 19 03:07:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541B31A06C8 for ; Wed, 19 Mar 2014 03:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhRofEOXRGp5 for ; Wed, 19 Mar 2014 03:07:04 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0E1A06F6 for ; Wed, 19 Mar 2014 03:07:04 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s2JA2krT015994 for ; Wed, 19 Mar 2014 11:06:53 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jpfqevhqb-1 for ; Wed, 19 Mar 2014 11:06:53 +0100 Received: from [192.168.0.102] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 615C940116 for ; Wed, 19 Mar 2014 11:06:53 +0100 (CET) Message-ID: <53296C32.1030602@sics.se> Date: Wed, 19 Mar 2014 11:06:42 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ace@ietf.org References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> <1148.1394721425@sandelman.ca> In-Reply-To: <1148.1394721425@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080800000002060201060606" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-19_04:2014-03-19,2014-03-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403190020 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/_zpC2C6brWve5tbHgyATusDsC5U Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 10:07:09 -0000 This is a cryptographically signed message in MIME format. --------------ms080800000002060201060606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 03/13/2014 03:37 PM, Michael Richardson wrote: > > I propose that there be a use case Informational ID, which over time, > will transform into a roadmap/architectural document. It will not be > published "prior" to the standards track documents, but since it will > be referenced by them all, they won't go forward either without it. =2E.. > Pick someone to edit the use case document who really wants an RFC cred= it, > and their personal motiviation will get it done. +1 I would do it "for the honour". /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms080800000002060201060606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTkxMDA2NDJaMCMGCSqGSIb3DQEJBDEW BBTfwLqDJmo90F5Q/uawHIf8Md/G+TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAfxKSI/cdtWPSR2kMY389ZaAsQ0R9nwMLvKrWUPZdV2Mgqf3vlJm4dcUrhm/miSX9vQzs mJNTMnIK9dfCgqNcaNwXGRnoSHY1wiR8itZrfvSkjmUPl8kQRastKodHo9Gz/nIieNG2M2lw uIgww2WuaBbFXtshqrvuAagsrA4FP+8vAmdgxcGTxya6Kb2oxsyNLd6YG4PIF+cdi3SctvfF v/zDqyjrFlHIKU0/6XaphewKvHcUVkcCVedSeSg7d1xQYSDfApQGHXTf3FRzHosq3pkRkhAM 7qoBbA04vPdd0+2XySudu91X2Oo3sXgHfLUlHj6bMQZIZzSObBUxwnI+awAAAAAAAA== --------------ms080800000002060201060606-- From nobody Wed Mar 19 04:42:28 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB921A06DD for ; Wed, 19 Mar 2014 04:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPa9fxp_ojcI for ; Wed, 19 Mar 2014 04:42:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AA8531A03D6 for ; Wed, 19 Mar 2014 04:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2JBgCJY005788; Wed, 19 Mar 2014 12:42:12 +0100 (CET) Received: from [134.102.218.207] (dynamic-218-h.informatik.uni-bremen.de [134.102.218.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E2BA870B; Wed, 19 Mar 2014 12:42:12 +0100 (CET) Message-ID: <5329828F.80505@tzi.de> Date: Wed, 19 Mar 2014 12:42:07 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ludwig Seitz , ace@ietf.org References: <3ai2vu1bh1hq4roxt53capi0.1394707574966@email.android.com> <53210BE1.5070702@gmx.net> <1148.1394721425@sandelman.ca> <53296C32.1030602@sics.se> In-Reply-To: <53296C32.1030602@sics.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0TCuik5QciL4LFVGHHa_EYMzLxI Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 11:42:25 -0000 On 03/19/2014 11:06 AM, Ludwig Seitz wrote: > On 03/13/2014 03:37 PM, Michael Richardson wrote: >> >> I propose that there be a use case Informational ID, which over time, >> will transform into a roadmap/architectural document. It will not be >> published "prior" to the standards track documents, but since it will >> be referenced by them all, they won't go forward either without it. > ... >> Pick someone to edit the use case document who really wants an RFC >> credit, >> and their personal motiviation will get it done. > > +1 > > I would do it "for the honour". I would contribute. Steffi From nobody Wed Mar 19 05:41:33 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3491A06E0 for ; Wed, 19 Mar 2014 05:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGSK7K57agxw for ; Wed, 19 Mar 2014 05:41:28 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0D1A0223 for ; Wed, 19 Mar 2014 05:41:28 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so9454645qcq.23 for ; Wed, 19 Mar 2014 05:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qauYbcoQRRwI7zX5BzIrp5FYI8AbiPcn6aF01U04R40=; b=uKs5LPK07dru09lImUe5fcLrUDsZfCBHeWCM9QYz+tPZLrYIVc/BwqC1Zg2HjuvyMy 9hhsuvfzpAiL/K3wo1CLbOT1xr66uGG4BCV+SBJAzu0NgO4IZz/zu864FN8VwwBnUYz7 ZoxL6+17LEjXUGUQkrwlPBBWMY9CEgdwMbCeQQBXEHV2ge1CvPqpTYFSB2jeM+TYDh/v YHmouotpCPumzQEq4ZYllWtRWfLckrAc5v2SxqzXiohKCwK0AkEbwI1yVesn4lQol3f4 kg5brpzezcUO2eA54qgXfvwxa6GTp7BdBroW2z9W71oiEe5Lt/QHP2ByS46/oq6YveyI zkLg== MIME-Version: 1.0 X-Received: by 10.140.92.201 with SMTP id b67mr29404361qge.58.1395232879232; Wed, 19 Mar 2014 05:41:19 -0700 (PDT) Received: by 10.140.27.101 with HTTP; Wed, 19 Mar 2014 05:41:19 -0700 (PDT) Received: by 10.140.27.101 with HTTP; Wed, 19 Mar 2014 05:41:19 -0700 (PDT) In-Reply-To: References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> Date: Wed, 19 Mar 2014 08:41:19 -0400 Message-ID: From: Margaret Wasserman To: Rafa Marin Lopez Content-Type: multipart/alternative; boundary=001a113a7b0c254b7e04f4f4f8d3 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/DZP_B226y_0beyX4t3sIrSOpSnc Cc: ace@ietf.org Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 12:41:31 -0000 --001a113a7b0c254b7e04f4f4f8d3 Content-Type: text/plain; charset=ISO-8859-1 Hi Rafa, I would be very interested in hearing more about this work. So, it would be great if you could prepare an ID describing your implementation and the results you achieved. Thanks, Margaret On Mar 18, 2014 9:24 AM, "Rafa Marin Lopez" wrote: > Hi Margaret, all > > > Depending on what you mean here, I might or might not agree... > > > > For instance, if we decide that an EAP-based approach could work in this > environment > > As part of a research activity here at the University of Murcia, we > created an initial design of an authentication service based on EAP for > CoAP sometime ago. In other words, CoAP messages are used to transport EAP > between the CoAP client (EAP authenticator) and the CoAP server (EAP peer/ > the constrained node). In particular, the EAP messages are directly > transported in the CoAP message payload for this authentication service. > In this case, the EAP authenticator (CoAP client) can contact an external > AAA server (which is one of the posible choices in ACE, as far as I have > read). > > Once EAP has finished, we bootstrap a security association between CoAP > server and CoAP client based on the MSK. In our case, this security > association might be based on DTLS or by using a new AUTH option we have > defined to be included in any CoAP message (no need of DTLS in the second > case). > > We have restarted the work some months ago and we have now a very limited > proof-of-concept with libcoap. It is still in PC platform but we have > started to build the implementation in COOJA simulator (without DTLS so > far). Nevertheless, our intention is also to test it with DTLS. > > I guess this could be also categorized as an EAP-based approach, though we > do not know if it will be interesting for ACE members. If people think it > is, we can prepare a short I-D explaining what we have until now. > > > (as it does for every wi-fi device that needs to join an 802.11x-secured > network), I think we might want to define an EAP method that leverages the > existing crypto algorithms and security protocols available on the > constrained device, based on the assumption that the device will also > implement a constrained version of DTLS (as defined by the DICE WG). > > In our case we have tested EAP-PSK since it uses AES-based cryptography. > In fact, we have previous experience on that in real constrained devices > (PANATIKI: A Network Access Control Implementation Based on PANA for IoT > Devices http://www.mdpi.com/1424-8220/13/11/14888). But I agree that if > we assume DTLS we may assume that an EAP-TLS method would be reasonable. > Nevertheless, I agree with Robert that we may not need to design a new EAP > method for that. > > Just my 0.02 cents. > > > Where would that fall in your view of the world? I don't think it > would be a Frankenprotocol at all, since EAP is designed to be extended > that way. There also wouldn't be much new protocol work, as an EAP-DTLS > method could be pretty similar to the existing EAP-TLS method. Assuming > something like that could meet our as-yet-undetermined requirements for > this environment, would you consider that to be a successful outcome? > > > > Margaret > > > > > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a113a7b0c254b7e04f4f4f8d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Rafa,

I would be very interested in hearing more about this work.&= nbsp; So, it would be great if you could prepare an ID describing your impl= ementation and the results you achieved.

Thanks,
Margaret

On Mar 18, 2014 9:24 AM, "Rafa Marin Lopez&= quot; <rafa@um.es> wrote:
Hi Margaret, all

> Depending on what you mean here, I might or might not agree… >
> For instance, if we decide that an EAP-based approach could work in th= is environment

As part of a research activity here at the University of Murcia, we created= an initial design of an authentication service based on EAP for CoAP somet= ime ago. In other words, CoAP messages are used to transport EAP between th= e CoAP client (EAP authenticator) and the CoAP server (EAP peer/ the constr= ained node). In particular, the EAP messages are directly transported in th= e CoAP message payload for this authentication service.  In this case,= the EAP authenticator (CoAP client) can contact an external AAA server (wh= ich is one of the posible choices in ACE, as far as I have read).

Once EAP has finished, we bootstrap a security association between CoAP ser= ver and CoAP client based on the MSK. In our case, this security associatio= n might be based on DTLS or by using a new AUTH option we have defined to b= e included in any CoAP message (no need of DTLS in the second case).

We have restarted the work some months ago and we have now a very limited p= roof-of-concept with libcoap. It is still in PC platform but we have starte= d to build the implementation in COOJA simulator (without DTLS so far). Nev= ertheless, our intention is also to test it with DTLS.

I guess this could be also categorized as an EAP-based approach, though we = do not know if it will be interesting for ACE members. If people think it i= s, we can prepare a short I-D explaining what we have until now.

> (as it does for every wi-fi device that needs to join an 802.11x-secur= ed network), I think we might want to define an EAP method that leverages t= he existing crypto algorithms and security protocols available on the const= rained device, based on the assumption that the device will also implement = a constrained version of DTLS (as defined by the DICE WG).

In our case we have tested EAP-PSK since it uses AES-based cryptography. In= fact, we have previous experience on that in real constrained devices (PAN= ATIKI: A Network Access Control Implementation Based on PANA for IoT Device= s h= ttp://www.mdpi.com/1424-8220/13/11/14888). But I agree that if we assum= e DTLS we may assume that an EAP-TLS method would be reasonable. Neverthele= ss, I agree with Robert that we may not need to design a new EAP method for= that.

Just my 0.02 cents.

>  Where would that fall in your view of the world?  I don'= ;t think it would be a Frankenprotocol at all, since EAP is designed to be = extended that way.  There also wouldn't be much new protocol work,= as an EAP-DTLS method could be pretty similar to the existing EAP-TLS meth= od.  Assuming something like that could meet our as-yet-undetermined r= equirements for this environment, would you consider that to be a successfu= l outcome?
>
> Margaret
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

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




_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace
--001a113a7b0c254b7e04f4f4f8d3-- From nobody Thu Mar 20 02:04:31 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7521A0691 for ; Thu, 20 Mar 2014 02:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U53h6Q0ZSDag for ; Thu, 20 Mar 2014 02:04:23 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBF31A08AF for ; Thu, 20 Mar 2014 02:04:22 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-24-532aaf0deb70 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E2.6A.23809.D0FAA235; Thu, 20 Mar 2014 10:04:13 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.80]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 10:04:12 +0100 From: =?Windows-1252?Q?G=F6ran_Selander?= To: Margaret Wasserman , Zach Shelby , "robert.cragie@gridmerge.com" Thread-Topic: [Ace] ACE Charter Proposal v0.5 Thread-Index: AQHPQq9FXnQfvixAoUyrPsxr924da5rpsVcA Date: Thu, 20 Mar 2014 09:04:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_CF50667ABD7Fgoranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+JvjS7veq1ggzXfxSy+f+thtnjwYh6T xc1995gtLl17wu7A4rFm3hpGj52z7rJ73PnzjNljyZKfTAEsUVw2Kak5mWWpRfp2CVwZy+Z/ ZSx4ZFWx/vVv1gbGU4ZdjJwcEgImEmcfnmGGsMUkLtxbz9bFyMUhJHCIUeLBxkYoZzGjxIZd z1lBqtgE3CUe92xkAUmICExilJgxbxU7SIJZQFFi3Zw+JhBbWEBH4vrcC0BFHEBFuhJT3rqA hEUEjCT2rN3BDhJmEVCVOP1dBCTMK2AusfnfBBYQW0jATWJPx2M2EJsTaFVTy3qwtYxAx30/ tYYJYpO4xK0n85kgjhaQWLLnPNQDohIvH/8DqxcV0JO492guC0RcSWLR7c9QvTESrbsuMkHs FZQ4OfMJywRGsVlIxs5CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hL3u2exIKtZ wMixipE9NzEzJ73caBMjMFYPbvmtuoPxzjmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamDUW3ZN814Rh33s4YobcRoX3n2eKbnwj3TCuz+Tfk9W5qoOLnafaRrlv2CV wRSP/T6/3v/w6X8e38zaqsnKOGWm0ryvj28vV7ybu5Ffm81dtGR1m0XxH2OJNUefzXMUezD1 gIJhr/QlrchTj+zK9hlrRKW0Bf9ev61s6WOHOhWOf9tsApTm1AgqsRRnJBpqMRcVJwIAZKVq rqMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/FcJpgprAfPQzJqmfrpx94WilIpg Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Charter Proposal v0.5 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 09:04:26 -0000 --_000_CF50667ABD7Fgoranselanderericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Margaret Wasserman > Reply-To: Margaret Wasserman > Date: Tuesday 18 March 2014 14:37 To: Zach Shelby >, "robert.= cragie@gridmerge.com" > Cc: "ace@ietf.org" > Subject: Re: [Ace] ACE Charter Proposal v0.5 Publishing the requirements and use cases in an RFC is NOT the same thing a= s gating our other work on publishing those things first -- I would object = to a phased charter that requires us to publish our use cases and requireme= nts as RFCs before we do any protocol work, I agree and I like the idea of using a wiki to collect and refine them. We should remember, though, that we will need to involve a wide range of IE= TF participants, including multiple IETF security experts, to be successful= . Not all of those people will have worked in the IoT/embedded space, so d= ocumenting the use cases and requirements early in the process (on a wiki p= age is fine) will be essential to allowing that wider set of IETF participa= nts to engage constructively. I agree and I do think we already have a document on a first set of use cas= es and requirements to put in the hands of those security experts. Disregar= ding the wrapping (draft or Wiki) I have heard very few comments about cont= ent or structure. I'd personally like to see the use cases and requirements captured in an ac= hival form that can be referenced later, because I think the use cases, in = particular, might be useful for later work. I'd be perfectly happy with pu= blishing them as RFCs later in the process, though. If people would rather try to capture the major use cases and motivations i= n the protocol spec instead, I guess that would work for me, but I would so= mewhat prefer an uncluttered protocol spec that refers to supporting inform= ational documents. I support that. And we could use a Wiki first and then copy into a draft. W= hat I=92d like to know is what are the concerns about the current draft or = could we reuse the structure and have the Wiki as a medium for editing this= draft? G=F6ran --_000_CF50667ABD7Fgoranselanderericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Margaret Wasserman <margaretw42@gmail.com>
Reply-To: Margaret Wasserman <margaretw42@gmail.com>
Date: Tuesday 18 March 2014 14:37 To: Zach Shelby <Zach.Shelby@arm.com>, "robert.cragie@gridmerge.com" <robert.cragie@gridmerge.com>
Cc: "ace@ietf.org" <ace@ietf.= org>
Subject: Re: [Ace] ACE Charter Prop= osal v0.5

Publishing the requirements and use cases in an RFC is NOT the same th= ing as gating our other work on publishing those things first -- I would ob= ject to a phased charter that requires us to publish our use cases and requ= irements as RFCs before we do any protocol work,

I agree

and I like the idea of using a wiki to collect and refine them.

We should remember, though, that we will need to involve a wide range = of IETF participants, including multiple IETF security experts, to be succe= ssful.  Not all of those people will have worked in the IoT/embedded s= pace, so documenting the use cases and requirements early in the process (on a wiki page is fine) will be essenti= al to allowing that wider set of IETF participants to engage constructively= .

I agree and I do think we already have a document on a first set of us= e cases and requirements to put in the hands of those security experts. Dis= regarding the wrapping (draft or Wiki) I have heard very few comments about= content or structure. 


I'd personally like to see the use cases and requirements captured in = an achival form that can be referenced later, because I think the use cases= , in particular, might be useful for later work.  I'd be perfectly hap= py with publishing them as RFCs later in the process, though.

If people would rather try to capture the major use cases and motivati= ons in the protocol spec instead, I guess that would work for me, but I wou= ld somewhat prefer an uncluttered protocol spec that refers to supporting i= nformational documents.  

I support that. And we could use a Wiki first and then copy into a dra= ft. What I=92d like to know is what are the concerns about the current draf= t or could we reuse the structure and have the Wiki as a medium for editing= this draft?


G=F6ran


 --_000_CF50667ABD7Fgoranselanderericssoncom_-- From nobody Thu Mar 20 08:41:01 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A2F1A03FD for ; Thu, 20 Mar 2014 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlBhknq5aVcY for ; Thu, 20 Mar 2014 08:40:51 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id E88471A0750 for ; Thu, 20 Mar 2014 08:40:46 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s2KFcQpf019231 for ; Thu, 20 Mar 2014 16:40:36 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jpfqf0ksj-1 for ; Thu, 20 Mar 2014 16:40:36 +0100 Received: from [192.168.0.102] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 9D43640116 for ; Thu, 20 Mar 2014 16:40:36 +0100 (CET) Message-ID: <532B0BF4.9040803@sics.se> Date: Thu, 20 Mar 2014 16:40:36 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ace@ietf.org" References: <532B0BB8.8090105@sics.se> In-Reply-To: <532B0BB8.8090105@sics.se> X-Forwarded-Message-Id: <532B0BB8.8090105@sics.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080400060703050904070908" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-20_04:2014-03-20,2014-03-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403200082 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/32zP7wWjc-xELoRRA4m54syy-Nc Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 15:40:59 -0000 This is a cryptographically signed message in MIME format. --------------ms080400060703050904070908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/19/2014 09:46 AM, Likepeng wrote: >>>> 2) Identify suitable authentication and authorization mechanisms, in= particular addressing dynamic and fine grained access control suitable f= or CoAP resource access requests in constrained environments. > >> I think this goes too far into the requirements space=E2=80=A6 > > Let's simplify that a little bit. How about this: > > Identify suitable authentication and authorization mechanisms suitable = for resource access in constrained environments. > > Kind Regards > Kepeng > Since you mention simplifying, I think we should also simplify and condense the descriptive text in the charter. Currently it is quite verbose and feels like it hides the purpose of the group behind a wall of text. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms080400060703050904070908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMjAxNTQwMzZaMCMGCSqGSIb3DQEJBDEW BBTrdiaE7JK1qREIY/bq2RNJM5SKmDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAAhy32owOVdFPaDzL7ri0QH5AJd0ZglMpaIouxZNMpKeDnNJd7pgR6unJePp1tu0uO5dw ojqQ7jy6OWb9AFUsN9PMR5YaHnnjTuakxtGMvwGi6rgCP5F/4R3v2TnPHq6YufcFwInXXQMr 5BgeXSiI6krzhxKI+3hepWqfogsXGjuXEVrGRSA0QF6Be+5bl8PX1VOPtoD7oyQTvk1j5VYP cp+02fO8lNEfWGgj5gtxdCW1/OUDChSVVppQfk+mc6OtQ6JALRegSCff5Q4k1h6boKB/Hm8t nMn58kyVeXZqx/tgY99AqvMticWpawJZFZQCldBckvzz+uUBoSxEmokcuwAAAAAAAA== --------------ms080400060703050904070908-- From nobody Thu Mar 20 19:06:18 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CF21A0834 for ; Thu, 20 Mar 2014 19:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9n8Yt8OMNHD for ; Thu, 20 Mar 2014 19:06:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C36051A084D for ; Thu, 20 Mar 2014 19:06:12 -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.7-GA FastPath queued) with ESMTP id BCG99790; Fri, 21 Mar 2014 02:06:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Mar 2014 02:05:45 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Mar 2014 02:06:02 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Fri, 21 Mar 2014 10:05:57 +0800 From: Likepeng To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] ACE Charter Proposal v0.6 Thread-Index: AQHPPrnTmdQyDUaRoUK9ubnDoEoVXJrlGNIP//+rHYCAA1rosIABgsoAgAAASACAARx30A== Date: Fri, 21 Mar 2014 02:05:56 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B083A0@SZXEMA501-MBS.china.huawei.com> References: <532B0BB8.8090105@sics.se> <532B0BF4.9040803@sics.se> In-Reply-To: <532B0BF4.9040803@sics.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ER4dw3fwtrKyBmC01cTsd9ldOVk Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 02:06:16 -0000 PiBTaW5jZSB5b3UgbWVudGlvbiBzaW1wbGlmeWluZywgSSB0aGluayB3ZSBzaG91bGQgYWxzbyBz aW1wbGlmeSBhbmQgY29uZGVuc2UNCj4gdGhlIGRlc2NyaXB0aXZlIHRleHQgaW4gdGhlIGNoYXJ0 ZXIuIEN1cnJlbnRseSBpdCBpcyBxdWl0ZSB2ZXJib3NlIGFuZCBmZWVscyBsaWtlIGl0DQo+IGhp ZGVzIHRoZSBwdXJwb3NlIG9mIHRoZSBncm91cCBiZWhpbmQgYSB3YWxsIG9mIHRleHQuDQoNClRo ZSBtYWluIHJlYXNvbiB0byBzaW1wbGlmeSB0aGUgc2Vjb25kIHRhc2sgaXMgdG8ga2VlcCB0aGUg Y29uc2lzdGVuY3kgd2l0aCB0aGUgb3RoZXIgdHdvIHRhc2tzLiBUaGUgb3RoZXIgdHdvIHRhc2tz IGFyZSBxdWl0ZSBzaW1wbGUuDQoNCkFib3V0IHRoZSBkZXNjcmlwdGl2ZSB0ZXh0IGluIHRoZSBj aGFydGVyLCB0aGUgbWFpbiBwdXJwb3NlIGlzIHRvIGhlbHAgb3V0c2lkZSBwZW9wbGUgdG8gdW5k ZXJzdGFuZCB0aGUgYmFja2dyb3VuZCwgcHJvYmxlbXMsIGNoYWxsZW5nZXMsIGV0Yy4gQnV0IGZv ciB0aGUgdGFzayBsaXN0LCBpbiBMb25kb24gQm9GIG1lZXRpbmcsIHdlIHJlY2VpdmUgY29tbWVu dHMgdGhhdCB3ZSBzaG91bGQgbm90IGdvIHRvbyBkZXRhaWxlZCBpbnRvIHRoZSBzb2x1dGlvbiBz cGFjZS4gQWxzbyB3ZSByZWNlaXZlIGNvbW1lbnRzIGZyb20gTWFyZ2FyZXQgdGhhdCB3ZSBzaG91 bGQgbm90IGdvIHRvbyBkZXRhaWxlZCBpbnRvIHRoZSByZXF1aXJlbWVudCBzcGFjZS4gVGhhdCBp cyB3aHkgd2Ugc2ltcGxpZnkgdGhlIHRhc2sgbGlzdCBhbmQgaGF2ZSBtb3JlIHRleHRzIGluIHRo ZSBkZXNjcmlwdGl2ZSBwYXJ0IHRoYW4gaW4gdGhlIHRhc2sgbGlzdC4gDQoNClRoYW5rcywNCg0K S2luZCBSZWdhcmRzDQpLZXBlbmcNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7 tuS6ujogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBMdWR3aWcgU2Vp dHoNCj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0M+aciDIw5pelIDIzOjQxDQo+IOaUtuS7tuS6ujog YWNlQGlldGYub3JnDQo+IOS4u+mimDogUmU6IFtBY2VdIEFDRSBDaGFydGVyIFByb3Bvc2FsIHYw LjYNCj4gDQo+IE9uIDAzLzE5LzIwMTQgMDk6NDYgQU0sIExpa2VwZW5nIHdyb3RlOg0KPiA+Pj4+ IDIpIElkZW50aWZ5IHN1aXRhYmxlIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG1l Y2hhbmlzbXMsIGluDQo+IHBhcnRpY3VsYXIgYWRkcmVzc2luZyBkeW5hbWljIGFuZCBmaW5lIGdy YWluZWQgYWNjZXNzIGNvbnRyb2wgc3VpdGFibGUgZm9yDQo+IENvQVAgcmVzb3VyY2UgYWNjZXNz IHJlcXVlc3RzIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCj4gPg0KPiA+PiBJIHRoaW5r IHRoaXMgZ29lcyB0b28gZmFyIGludG8gdGhlIHJlcXVpcmVtZW50cyBzcGFjZeKApg0KPiA+DQo+ ID4gTGV0J3Mgc2ltcGxpZnkgdGhhdCBhIGxpdHRsZSBiaXQuIEhvdyBhYm91dCB0aGlzOg0KPiA+ DQo+ID4gSWRlbnRpZnkgc3VpdGFibGUgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24g bWVjaGFuaXNtcyBzdWl0YWJsZSBmb3INCj4gcmVzb3VyY2UgYWNjZXNzIGluIGNvbnN0cmFpbmVk IGVudmlyb25tZW50cy4NCj4gPg0KPiA+IEtpbmQgUmVnYXJkcw0KPiA+IEtlcGVuZw0KPiA+DQo+ IA0KPiBTaW5jZSB5b3UgbWVudGlvbiBzaW1wbGlmeWluZywgSSB0aGluayB3ZSBzaG91bGQgYWxz byBzaW1wbGlmeSBhbmQgY29uZGVuc2UNCj4gdGhlIGRlc2NyaXB0aXZlIHRleHQgaW4gdGhlIGNo YXJ0ZXIuIEN1cnJlbnRseSBpdCBpcyBxdWl0ZSB2ZXJib3NlIGFuZCBmZWVscyBsaWtlIGl0DQo+ IGhpZGVzIHRoZSBwdXJwb3NlIG9mIHRoZSBncm91cCBiZWhpbmQgYSB3YWxsIG9mIHRleHQuDQo+ IA0KPiAvTHVkd2lnDQo+IA0KPiAtLQ0KPiBMdWR3aWcgU2VpdHosIFBoRA0KPiBTSUNTIFN3ZWRp c2ggSUNUIEFCDQo+IElkZW9uIFNjaWVuY2UgUGFyaw0KPiBCdWlsZGluZyBCZXRhIDINCj4gU2No ZWVsZXbDpGdlbiAxNw0KPiBTRS0yMjMgNzAgTHVuZA0KPiANCj4gUGhvbmUgKzQ2KDApNzAtMzQ5 IDkyIDUxDQo+IGh0dHA6Ly93d3cuc2ljcy5zZQ0KDQo= From nobody Fri Mar 21 03:07:45 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A31A06B4 for ; Fri, 21 Mar 2014 03:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sL-5TzXV5mr for ; Fri, 21 Mar 2014 03:07:37 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id CA3661A065C for ; Fri, 21 Mar 2014 03:07:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 3C8D8B885; Fri, 21 Mar 2014 11:07:23 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4VtXOzX65k4B; Fri, 21 Mar 2014 11:07:23 +0100 (CET) Received: from inf-205-186.inf.um.es (inf-205-186.inf.um.es [155.54.205.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon22.um.es (Postfix) with ESMTPSA id DF6B4B205; Fri, 21 Mar 2014 11:07:21 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_49153A21-439B-4E11-B2CF-646332A25440" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rafa Marin Lopez In-Reply-To: Date: Fri, 21 Mar 2014 11:07:20 +0100 Message-Id: <573AC6AE-F977-4E64-A9F7-102734DC3C9A@um.es> References: <532108F4.10007@gmx.net> <46A1DF3F04371240B504290A071B4DB63E463630@SZXEMA510-MBX.china.huawei.com> <7E54736F-B1B0-4BFC-9BED-9B61939D8145@tzi.org> <028713D6-43AA-4A43-A25D-CFA86DE2917D@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0c6AYcHCpJBGt-lvakJWeZtga_4 Cc: ace@ietf.org Subject: Re: [Ace] ACE Charter Proposal v0.6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 10:07:42 -0000 --Apple-Mail=_49153A21-439B-4E11-B2CF-646332A25440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Margaret, Kapeng Many thanks for your interest. We'll do it, then. Best Regards. El 19/03/2014, a las 13:41, Margaret Wasserman = escribi=F3: > Hi Rafa, >=20 > I would be very interested in hearing more about this work. So, it = would be great if you could prepare an ID describing your implementation = and the results you achieved. >=20 > Thanks, > Margaret >=20 > On Mar 18, 2014 9:24 AM, "Rafa Marin Lopez" wrote: > Hi Margaret, all >=20 > > Depending on what you mean here, I might or might not agree=85 > > > > For instance, if we decide that an EAP-based approach could work in = this environment >=20 > As part of a research activity here at the University of Murcia, we = created an initial design of an authentication service based on EAP for = CoAP sometime ago. In other words, CoAP messages are used to transport = EAP between the CoAP client (EAP authenticator) and the CoAP server (EAP = peer/ the constrained node). In particular, the EAP messages are = directly transported in the CoAP message payload for this authentication = service. In this case, the EAP authenticator (CoAP client) can contact = an external AAA server (which is one of the posible choices in ACE, as = far as I have read). >=20 > Once EAP has finished, we bootstrap a security association between = CoAP server and CoAP client based on the MSK. In our case, this security = association might be based on DTLS or by using a new AUTH option we have = defined to be included in any CoAP message (no need of DTLS in the = second case). >=20 > We have restarted the work some months ago and we have now a very = limited proof-of-concept with libcoap. It is still in PC platform but we = have started to build the implementation in COOJA simulator (without = DTLS so far). Nevertheless, our intention is also to test it with DTLS. >=20 > I guess this could be also categorized as an EAP-based approach, = though we do not know if it will be interesting for ACE members. If = people think it is, we can prepare a short I-D explaining what we have = until now. >=20 > > (as it does for every wi-fi device that needs to join an = 802.11x-secured network), I think we might want to define an EAP method = that leverages the existing crypto algorithms and security protocols = available on the constrained device, based on the assumption that the = device will also implement a constrained version of DTLS (as defined by = the DICE WG). >=20 > In our case we have tested EAP-PSK since it uses AES-based = cryptography. In fact, we have previous experience on that in real = constrained devices (PANATIKI: A Network Access Control Implementation = Based on PANA for IoT Devices = http://www.mdpi.com/1424-8220/13/11/14888). But I agree that if we = assume DTLS we may assume that an EAP-TLS method would be reasonable. = Nevertheless, I agree with Robert that we may not need to design a new = EAP method for that. >=20 > Just my 0.02 cents. >=20 > > Where would that fall in your view of the world? I don't think it = would be a Frankenprotocol at all, since EAP is designed to be extended = that way. There also wouldn't be much new protocol work, as an EAP-DTLS = method could be pretty similar to the existing EAP-TLS method. Assuming = something like that could meet our as-yet-undetermined requirements for = this environment, would you consider that to be a successful outcome? > > > > Margaret > > > > > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_49153A21-439B-4E11-B2CF-646332A25440 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Margaret, Kapeng

Many thanks for your interest. We'll = do it, then.

Best = Regards.

El 19/03/2014, a las 13:41, Margaret = Wasserman <margaretw42@gmail.com> = escribi=F3:

Hi Rafa,

I would be very = interested in hearing more about this work.  So, it would be great = if you could prepare an ID describing your implementation and the = results you achieved.

Thanks,
Margaret

On Mar 18, 2014 9:24 AM, "Rafa Marin Lopez" = <rafa@um.es> wrote:
Hi Margaret, all

> Depending on what you mean here, I might or might not agree=85
>
> For instance, if we decide that an EAP-based approach could work in = this environment

As part of a research activity here at the University of Murcia, we = created an initial design of an authentication service based on EAP for = CoAP sometime ago. In other words, CoAP messages are used to transport = EAP between the CoAP client (EAP authenticator) and the CoAP server (EAP = peer/ the constrained node). In particular, the EAP messages are = directly transported in the CoAP message payload for this authentication = service.  In this case, the EAP authenticator (CoAP client) can = contact an external AAA server (which is one of the posible choices in = ACE, as far as I have read).

Once EAP has finished, we bootstrap a security association between CoAP = server and CoAP client based on the MSK. In our case, this security = association might be based on DTLS or by using a new AUTH option we have = defined to be included in any CoAP message (no need of DTLS in the = second case).

We have restarted the work some months ago and we have now a very = limited proof-of-concept with libcoap. It is still in PC platform but we = have started to build the implementation in COOJA simulator (without = DTLS so far). Nevertheless, our intention is also to test it with = DTLS.

I guess this could be also categorized as an EAP-based approach, though = we do not know if it will be interesting for ACE members. If people = think it is, we can prepare a short I-D explaining what we have until = now.

> (as it does for every wi-fi device that needs to join an = 802.11x-secured network), I think we might want to define an EAP method = that leverages the existing crypto algorithms and security protocols = available on the constrained device, based on the assumption that the = device will also implement a constrained version of DTLS (as defined by = the DICE WG).

In our case we have tested EAP-PSK since it uses AES-based cryptography. = In fact, we have previous experience on that in real constrained devices = (PANATIKI: A Network Access Control Implementation Based on PANA for IoT = Devices http://www.mdpi.com/1424-8220/13/11/14888). But I = agree that if we assume DTLS we may assume that an EAP-TLS method would = be reasonable. Nevertheless, I agree with Robert that we may not need to = design a new EAP method for that.

Just my 0.02 cents.

>  Where would that fall in your view of the world?  I = don't think it would be a Frankenprotocol at all, since EAP is designed = to be extended that way.  There also wouldn't be much new protocol = work, as an EAP-DTLS method could be pretty similar to the existing = EAP-TLS method.  Assuming something like that could meet our = as-yet-undetermined requirements for this environment, would you = consider that to be a successful outcome?
>
> Margaret
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

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




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing = list
Ace@ietf.org
https://www.ietf.org/mail= man/listinfo/ace

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




= --Apple-Mail=_49153A21-439B-4E11-B2CF-646332A25440-- From nobody Sun Mar 23 15:59:38 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B636A1A0A71 for ; Sun, 23 Mar 2014 15:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQZeoOG76iCm for ; Sun, 23 Mar 2014 15:59:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id B158A1A0A23 for ; Sun, 23 Mar 2014 15:59:34 -0700 (PDT) Received: from [192.168.10.150] ([93.158.42.212]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M4B71-1XHtgc0279-00rrLT for ; Sun, 23 Mar 2014 23:59:33 +0100 Message-ID: <532F6752.5030909@gmx.net> Date: Sun, 23 Mar 2014 23:59:30 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ace@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7pC1weNLtc1lirJbLQp5jTItd91Dwm2bQ" X-Provags-ID: V03:K0:D+lC6OMRwj8VPGu6uM727nigWRpHafSBO9+fl8A5LnxgnSSyTjo h/qDQfDHz4ZHdrbB87jVHfcSw433mYTaq1MbjCXY96koS40qFNIKr037Zk+qioHLNBpixJM KIV6jb+4Y3tB8ypI6X1fd44ta6zurd5mjw8SwjWimreZ7KHH6KDkupGOq2jUVvH/Bra+ZGo 3PZljYonyvgODLJPRcP8g== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/rY_Yzdz10BsY2NILQry06Fw24Mk Subject: [Ace] Summary of the "Constrained Authorization Server" Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 22:59:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7pC1weNLtc1lirJbLQp5jTItd91Dwm2bQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, we had a discussion on the list about the nature of the authorization server and whether it is constrained in a way similarly to the resource server. My impression from the feedback is that we should see the authorization server as a device that has sufficient network connectivity, is not battery-powered, and has sufficient processing power and storage. No changes or additions to the charter are necessary but we should capture this observation in the use case/requirements document. Ciao Hannes --7pC1weNLtc1lirJbLQp5jTItd91Dwm2bQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTL2dSAAoJEGhJURNOOiAtn9wIAJg8snaoDHbavW1FMeJLZRoy pcwigFaE3znREhFat9SmRFZfLYPcxRXrqdimRKkcl3g0feK4vZlD7JswWUSdXAed kfYjfckm56QqPIQ1h8rqGtvdiF1hTsErQq7uJfIuBBsJ/7vh5TkAPzlCG5eBHinQ uxg4cs6hhgbGkEec7dECFV0mhgD9m/ksZ6gkISRmYrkU5k2m+UU8voeyJuAL934o PJqx8Eea4eYoVxgI6h+szi27LPOPBH58eU4EqSYyTtOgWtF6PPilzh64hNL0dH7a wF4itNpknSmK7HI0eJQC8Bm22F67ymybDSlB6a02xkKYdQCkEhOEtjLg3DraXpQ= =kMFE -----END PGP SIGNATURE----- --7pC1weNLtc1lirJbLQp5jTItd91Dwm2bQ-- From nobody Sun Mar 23 16:06:25 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047431A0A2A for ; Sun, 23 Mar 2014 16:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXBhmaOWLVCz for ; Sun, 23 Mar 2014 16:06:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9501A6F97 for ; Sun, 23 Mar 2014 16:06:20 -0700 (PDT) Received: from [192.168.10.150] ([93.158.42.212]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MaW7Z-1WguPa0HbF-00K7Hm for ; Mon, 24 Mar 2014 00:06:19 +0100 Message-ID: <532F68E7.7000802@gmx.net> Date: Mon, 24 Mar 2014 00:06:15 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ace@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hKi98Dd1AvOksFG0u5qiNx2m0pEkATc6j" X-Provags-ID: V03:K0:rXT7K4GO8Fvf/OaF4LtrcHBvRz2IHuITdi8oj6OAm/xahYkc4+J 2h/Cdzrkc5lfPJWMwiTYvoJ/bEJ+iuZNEFr5NOpGroSKoHjJ0cJ1lDZfK7BNB16JBCRuSzW dHH3Ra34VB0xi2lOC/JdXSjgZ/FRX/npEleM8++SfrgJFqdcxtKnRc3i5UT55YLE3ybr+42 kHaE56N/PA3kbgcWfNTwA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/rpje01a06hx5L5MWLhCEMjlZBPc Subject: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:06:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hKi98Dd1AvOksFG0u5qiNx2m0pEkATc6j Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, based on the feedback at the BOF we concluded that proxies should be part of the WG investigation. What wasn't clear was when an investigation should be conducted. I am not sure how to interpret the lack of feedback. I was hoping to get feedback from folks working in the CORE working group on how they thought proxies work in combination with DTLS but no feedback was provided. I hope that Akbar and Phil provide a more detailed contribution as part of the use case/requirements discussion. I am currently inclined not to include text that states explicitly when the proxy topic will be decided. Ciao Hannes --hKi98Dd1AvOksFG0u5qiNx2m0pEkATc6j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTL2jnAAoJEGhJURNOOiAtR2EIAId+fgRaLBD9wHezI/5mWiD7 RoLMAJrJNXqzonYzkI6y7k9qDxXKRX5W44uIxpTdL6mpOox0isVcnGllnpk1kMH/ cTWQz11G70VOQ0GRUl+7v/YgJTXWqZ5Qn4N3LgJOOHBaLVXBa3d04Q8b9ytlp4id XgTAlN2ZOJAVDb6KRTnixtxciaIG1q7QeGqcghfM8Zn/vTn2bBe2o2nsJSZN6oqB 0CkpAX5hVyQ4RkehWT8epjtj1okBZedPI5vBVzsFbM9KxRgfOpFJX/og+w15nDmw rVSmn/JrbiSTlRDk8hxqKpaPxmk+ooMURhbR/3IAlU4yvEcePlPO9G3a0Sd+vvM= =YTVB -----END PGP SIGNATURE----- --hKi98Dd1AvOksFG0u5qiNx2m0pEkATc6j-- From nobody Sun Mar 23 16:06:49 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13481A7002 for ; Sun, 23 Mar 2014 16:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOzE6EepxSN4 for ; Sun, 23 Mar 2014 16:06:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7B91A6F97 for ; Sun, 23 Mar 2014 16:06:46 -0700 (PDT) Received: from [192.168.10.150] ([93.158.42.212]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LnDof-1X22B60UH7-00hJQD for ; Mon, 24 Mar 2014 00:06:45 +0100 Message-ID: <532F6902.3090309@gmx.net> Date: Mon, 24 Mar 2014 00:06:42 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ace@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Nq6jgmaEwoiGp5uAgSREiu1l2nfnnaWXf" X-Provags-ID: V03:K0:ulmuRPskdC13UK8Y3NNjWRI0Fs3vQhCsOYe2PhKz2Xiga0a1zjO AqHBpxI6nJjFye+LTh+Ch73w9LscilgSRWatXLiVF0XTdrtp2Ki/iRFYZi6RW38pIsnm6jZ kfOLs9x0GnwRL0a2MfIJhCVJM1q3sht0l3aizx9MmbnmTy8o1PN8vc4ftNz9XJAaaAVdjbk 0UM/rPy6CCFTl+F7oQP6w== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/xCQbl0gOlnawx6rX_Uwvx42I1to Subject: [Ace] Summary of the "Design Consideration Document as one milestone" Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:06:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Nq6jgmaEwoiGp5uAgSREiu1l2nfnnaWXf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I was hoping to get more feedback about adding the design consideration document as a milestone but, unfortunately, there was not a lot of suppor= t. Maybe the work is a bit too abstract or relevant parts could be included in the solution work itself. My conclusion from the discussion is that we do not need an milestone for this work. Ciao Hannes --Nq6jgmaEwoiGp5uAgSREiu1l2nfnnaWXf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTL2kCAAoJEGhJURNOOiAterMH/0z+zCswM3msYwbPomYj0H5c qI4SP7qRFk9lJ/JtFrfuor5Ouuhll+ZCqDuhsv0ZvH1QzKUpDpwDyxEWfLZaiHX4 tmIuANflHW7E1X1jBZojUvhvjhcDmVisq8K1mnCigXEV6KnuI0CFkIScgsRehlTj 6TWCmBFbuUxfWYj5dGqZqnoJ5xWy1TGYIhNs3EzyE9FtCZYcSrCwIyBB8Rx4PvgB 3bXWbpfBkONHqYzW9JjnJ8JL4QcBSloM6VSeMfgXlBWtbM1A6JhOAWrxaLo1Kk91 jnF5UNGYfbHvxoyw8F+XO2RgvdP4jTYP7RmYL0SKb+/s6GjGIxjX1ZW/ro8BDoQ= =pyiy -----END PGP SIGNATURE----- --Nq6jgmaEwoiGp5uAgSREiu1l2nfnnaWXf-- From nobody Sun Mar 23 19:00:14 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E99C1A0096 for ; Sun, 23 Mar 2014 19:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbgwqaRXn_Ek for ; Sun, 23 Mar 2014 19:00:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7C71A0095 for ; Sun, 23 Mar 2014 19:00:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3B3620049; Sun, 23 Mar 2014 23:19:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D1E0B63AB2; Sun, 23 Mar 2014 22:00:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BE2B863AA2; Sun, 23 Mar 2014 22:00:08 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <532F68E7.7000802@gmx.net> References: <532F68E7.7000802@gmx.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/B7hGHuBaGovRqoeAlZ19IkFne54 Cc: Ace@ietf.org Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 02:00:11 -0000 --=-=-= Hannes Tschofenig wrote: > based on the feedback at the BOF we concluded that proxies should be > part of the WG investigation. What wasn't clear was when an > investigation should be conducted. When you say proxies, I think you are talking about things which the end points are aware of (and may have to trust). It would include, but not be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!) Would we agree that the proxies are not transparent? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCUAwUBUy+RqIqHRg3pndX9AQKJfgP4o9ZE+69HmzMhUcA0CZlkFlJPgGOkbjvH xe8uwMhmZSeDO+wgrYv4V7vxGeI+wRJ7hIulhIyUi/qgIy3cAoY7Jjfpnm5Y2E/z 9E4NmRUh5l+2IRhNix3+LzXSZ4EWluWJFOhWVrD/lPL+GgWY6mBNjlyl9RKzeKuI m0au5vY9aw== =8X/X -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 23 22:52:25 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D101A00F4 for ; Sun, 23 Mar 2014 22:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlleBegmQ4rl for ; Sun, 23 Mar 2014 22:52:22 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B1B271A00F3 for ; Sun, 23 Mar 2014 22:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2O5qHfV019845; Mon, 24 Mar 2014 06:52:17 +0100 (CET) Received: from [192.168.3.113] (host63-173-static.89-82-b.business.telecomitalia.it [82.89.173.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 98DC5AC6; Mon, 24 Mar 2014 06:52:17 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D167) In-Reply-To: <532F68E7.7000802@gmx.net> Date: Mon, 24 Mar 2014 06:52:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <532F68E7.7000802@gmx.net> To: Hannes Tschofenig Archived-At: http://mailarchive.ietf.org/arch/msg/ace/hgNADbCWfkyAzIXpkbS7JizrRvk Cc: "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 05:52:24 -0000 > On 24.03.2014, at 00:06, Hannes Tschofenig wro= te: >=20 > the proxy topic I don't know what that is. There are proxy-like instances in the Berlin mode= l. Various kinds of Proxies with various security roles could also be insert= ed at various places. Inserting proxies with no defined security everywhere= just means that DTLS becomes less useful or has to be transported over the p= roxies. =20 Gr=C3=BC=C3=9Fe, Carsten= From nobody Mon Mar 24 01:24:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6641A0159 for ; Mon, 24 Mar 2014 01:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r_gVheiZdR8 for ; Mon, 24 Mar 2014 01:24:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3878D1A0156 for ; Mon, 24 Mar 2014 01:24:35 -0700 (PDT) Received: from [192.168.10.150] ([46.218.78.54]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LcWSI-1Wqa2Q1KxK-00jrMx; Mon, 24 Mar 2014 09:24:32 +0100 Message-ID: <532F7A90.1040302@gmx.net> Date: Mon, 24 Mar 2014 01:21:36 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> In-Reply-To: <23517.1395626408@sandelman.ca> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xxkcJM9rKStns2WvtVpiBVfqNWvk8rWn9" X-Provags-ID: V03:K0:SYZqRfVujyfsOnaKRx+g5fMhxDCOV/wkfRF2mdAxZTeGB1ckJrj eza62KYbzT188ylFOqPkbaCH+2S2fZGEYb32etqO+NFEYJVo2DzDTxPPjft080RQ2TDgOlq DjZUuvPNnjMYqqo8QHuJT7s+T6AhLzhQXNszwiuv7rXtS/Md80Yx7kSho9wVAFWdT57d9A5 uWfpbZctTvnMzL2Y0YxOw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/sZfH4oQtkuhp7ZKUZPlj-WIDjbM Cc: Ace@ietf.org Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 08:24:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xxkcJM9rKStns2WvtVpiBVfqNWvk8rWn9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, On 03/24/2014 03:00 AM, Michael Richardson wrote: >=20 > Hannes Tschofenig wrote: > > based on the feedback at the BOF we concluded that proxies should= be > > part of the WG investigation. What wasn't clear was when an > > investigation should be conducted. >=20 > When you say proxies, I think you are talking about things which the > end points are aware of (and may have to trust). It would include, but= not > be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!) During the discussions on the list I had to noticed that folks had different use cases in mind. One was about protocol translation but there are also cases that have nothing to do with protocol translation but rather with the use of CoAP itself and how some seem to have assumed how it works. >=20 > Would we agree that the proxies are not transparent? Transparency is a fuzzy term here. Is a protocol translator transparent of not and the question is to whom is it transparent? I believe I am saying that we all have not thought about the proxy topic enough to make a conclusion that could go into the charter and for that reason I am trying to encourage those who have expertise in this field to make contributions as early as possible. Ciao Hannes >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --xxkcJM9rKStns2WvtVpiBVfqNWvk8rWn9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTL3qQAAoJEGhJURNOOiAtKDUH/2R4MtwgyukWn1LaRGUGjrlK KyRoCuajyn291turcy8mf+ezIWHQISOp766q1jK7T283Q6K8/XBiC0ZS8fMCTmEq gr2PitJLlCsMToJ5Oirk213Dog11H3lZgy8og3rfFGxT6q1eZAByDxv7FFHjS2Ih hrYNJsTlIrelafk3gb4d5n20we+BiG+KXB0HF2Ci4cP/xHY+SCYp04+kYdzGyE4W OS0LXy3z9gRRnJ32ocfOzQ4TxmSJtfOl81TaqN1Dx+qnjbarzbltfN6Egg1eO7VD cEdppLvy/Rr/KxsaSGzC94WmoMXKJIv8Weo8LcpLoeoaciMWiAVe3DxYreGcMNg= =Dnxv -----END PGP SIGNATURE----- --xxkcJM9rKStns2WvtVpiBVfqNWvk8rWn9-- From nobody Mon Mar 24 01:27:42 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AC51A00E6 for ; Mon, 24 Mar 2014 01:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRjR2Z8TiCFW for ; Mon, 24 Mar 2014 01:27:38 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8E1A00D9 for ; Mon, 24 Mar 2014 01:27:38 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s2O8QD6R021109 for ; Mon, 24 Mar 2014 09:27:36 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jr6a9248c-1 for ; Mon, 24 Mar 2014 09:27:36 +0100 Received: from [192.168.0.102] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 5E63140116 for ; Mon, 24 Mar 2014 09:27:36 +0100 (CET) Message-ID: <532FEC78.3080905@sics.se> Date: Mon, 24 Mar 2014 09:27:36 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ace@ietf.org References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> In-Reply-To: <23517.1395626408@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070604070002000007020004" X-Proofpoint-Spam-Reason: safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-23_03:2014-03-21,2014-03-23,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ixo-ZB0X4GeTlJnTfPPDZnZzsWg Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 08:27:41 -0000 This is a cryptographically signed message in MIME format. --------------ms070604070002000007020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 03/24/2014 03:00 AM, Michael Richardson wrote: > > Hannes Tschofenig wrote: > > based on the feedback at the BOF we concluded that proxies shoul= d be > > part of the WG investigation. What wasn't clear was when an > > investigation should be conducted. > > When you say proxies, I think you are talking about things which the > end points are aware of (and may have to trust). It would include, but= not > be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!) > > Would we agree that the proxies are not transparent? > Yes! They break end-to-end security, if authentication is based on DTLS. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms070604070002000007020004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMjQwODI3MzZaMCMGCSqGSIb3DQEJBDEW BBTRS1o0bQ5PFT1+r+bZelCcqKM6gzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAamTLP2nOFp22tHX5x+Cnr2m/8yS7aZrt4ZnRAMy+J8Jtv8lYg0uMTZDNsIpElPwfAWOK 6Ik9CnyiFow7POO3w+tUJOSSXGurzvddeSpFYpiJEIwKpMB3zhGbSqOnmsU4p8JHbnrgjv2e cG60FvjeUEEdBHiNg1xgYsNUIzpJfoW6xOlzCiwjdfsfZk1pxF5tzXv9yfK3EvxnZlmDZIEE n9V/7H572B5nBg+6HVAswotAQDLrcsMj46vww1Ii6cc4SINRKVen/OoKvck/G2/RWP45V951 Cfpu0RRMkHdXjXGUHZLNiBrRbAWWwnF2w5g/iA2R7vjhsNWSZKXMmkzKegAAAAAAAA== --------------ms070604070002000007020004-- From nobody Mon Mar 24 01:30:45 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C4D1A00F9 for ; Mon, 24 Mar 2014 01:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dag6dLxToraU for ; Mon, 24 Mar 2014 01:30:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0127C1A00F8 for ; Mon, 24 Mar 2014 01:30:41 -0700 (PDT) Received: from [192.168.10.150] ([46.218.78.54]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LguAU-1WuzlV3kGs-00oH7M; Mon, 24 Mar 2014 09:30:28 +0100 Message-ID: <532F7BF3.7080006@gmx.net> Date: Mon, 24 Mar 2014 01:27:31 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carsten Bormann References: <532F68E7.7000802@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cha9g4QgjnLw9jWrvj0e66loaeQBdam01" X-Provags-ID: V03:K0:iz73cXJiixvDVjXcK2uuaanSsakRqnXHGFYJF9XWeeMEYQLF1IE DtVm/aaWT0C4BUq1ZHrt3Xm8pY1n89t7oXIc0dCG8J3AlTACtGYbZUV4AWsigz80vhashye 8gMZCgGsr+S1KbvO7Kaa5CSYNDlNkE4J3+6TYVPiSdHdNNm0QMO33eW/NOLwy3H0dXok50Z oH6u/YxVTEXPF24FVeA9w== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/RlUgPOjixhWNaTOPmlxTb571Y8k Cc: "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 08:30:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cha9g4QgjnLw9jWrvj0e66loaeQBdam01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, at the BOF we had suggestions to investigate the ability to have proxies for protocol translation (as documented in http://www.ietf.org/proceedings/89/minutes/minutes-89-ace). Then, following the meeting we had discussions on the list about how plain CoAP proxies fit into the DTLS security model (see http://www.ietf.org/mail-archive/web/ace/current/msg00153.html). I was hoping that you and other CORE WG persons would provide input on the latter aspect. As I mentioned in my other mail I believe we need further input from those who care about various forms of proxies as early as possible. Ciao Hannes On 03/24/2014 06:52 AM, Carsten Bormann wrote: >=20 >=20 >> On 24.03.2014, at 00:06, Hannes Tschofenig = wrote: >> >> the proxy topic >=20 > I don't know what that is. There are proxy-like instances in the Berlin= model. Various kinds of Proxies with various security roles could also b= e inserted at various places. Inserting proxies with no defined security= everywhere just means that DTLS becomes less useful or has to be transpo= rted over the proxies. =20 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --cha9g4QgjnLw9jWrvj0e66loaeQBdam01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTL3vzAAoJEGhJURNOOiAt2skH/1wVR+rwTZxPxTdyY8AcoBVo t5pSji1tgh6dOvMjsCRfykrfw2L+zvIPTqzA9p61u5dOPWYJ/ikLRTO0JZJdV6s7 lRx86AwKT4FiQ76oyX2z0Hml5+UWGn6pBP9N0e6dwRqn6Hac080SNy8Oh9JGD/aG dK2GAtFZVjh3wDqsa9DDLbYiZXlzsdvmyJo5kDSmiSrOwspcdgwUxZK1qrgAZZDV dWrdkDT36Eb7bfh2NYvQY3vW4NYMQ7QXQKMaOHea7hvp1k9UxUCM8aYgLFT1GegA iS8pLmhwHMd+nbdJdtlkDR5J0R/jCEQSDy5+gNyaUXg8QzZC/jBvEFCYDviGVyM= =DJWo -----END PGP SIGNATURE----- --cha9g4QgjnLw9jWrvj0e66loaeQBdam01-- From nobody Mon Mar 24 01:35:51 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174951A010F for ; Mon, 24 Mar 2014 01:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLgpNrs7YujH for ; Mon, 24 Mar 2014 01:35:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id C63A81A00F9 for ; Mon, 24 Mar 2014 01:35:48 -0700 (PDT) Received: from [192.168.10.150] ([46.218.78.54]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lwnem-1XByCg2iM4-016MMg for ; Mon, 24 Mar 2014 09:35:47 +0100 Message-ID: <532F7D32.5020205@gmx.net> Date: Mon, 24 Mar 2014 01:32:50 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bhuf287OAxoFDx2GBviQrFNDFQe8S83p3" X-Provags-ID: V03:K0:C7JGcRAq6jLo8oxH+f58ewW7Nesk/lPj6KIx9L9Kvu8ANl661Px itRmZxRTH4b6qrCKYvpblS6ZexY8nkuZxQ/0ALotPniEjdkHR0TcI7euiiJJQQmkY5U4B/M wEDFFkFpZVavNS0p99aIU8hR6V+8nK8uxrIaxF0zVvqOD2757sn4q8OwIkn2tWNJ6YzSyaf EWi/m8ao6a55QXYeC55Ig== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/jxnmC72iuwtMMVbnBR3Cyyvxpn0 Subject: [Ace] Summary: Documenting Use Cases and Requirements X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 08:35:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bhuf287OAxoFDx2GBviQrFNDFQe8S83p3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, Kepeng and I have been wondering what the conclusion regarding the use case/requirement discussion was. We believe that there is consensus in the group to publish the requirements and use cases as an informational RFC. We also have various persons who are willing to contribute their time to this work (as co-authors). What is not quite clear to use is whether we should use a Wiki in the interim period to allow more people to contribute their thoughts. To close this issue please let us know whether you would a) prefer to contribute text to a Wiki, or b) via the mailing list (and let the draft authors / editors incorporate the content into the document). Ciao Hannes --bhuf287OAxoFDx2GBviQrFNDFQe8S83p3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTL30yAAoJEGhJURNOOiAtApgH/jiwmrEGwCRPirfBRifjOgdQ Ivf7mqPk219KOVN65gX1QWZEdIY3wx8/vbkKnnBqwUNxFOR0p34Ru8NaLf8KEVGp erSRlpkpFCrGqXQtg4rcOZOSj5SJ5fAK86oavqa4cmfqDpqlpwI0P7EblvGAyStl lHtDxVF8orml4nFVBBhzucf0UJmn/koptX77oqQHIFPpp63L76vToXd5VYRvgUQi fdokhwNgtjNHHHPrP0Jm1dltVPtWcbQxWFl2huCX5J8EDpMil5rQEztarIPnx4au oS17gYDGasvl5aQuaDSxpiZoPX+aFKHyeR2sAbkRHyDh1Nst+H/SeyFDwvK4Nrg= =4C97 -----END PGP SIGNATURE----- --bhuf287OAxoFDx2GBviQrFNDFQe8S83p3-- From nobody Mon Mar 24 02:01:16 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3569D1A0168 for ; Mon, 24 Mar 2014 02:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkpjmwzHA4zR for ; Mon, 24 Mar 2014 02:01:13 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9CC1A0167 for ; Mon, 24 Mar 2014 02:01:13 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s2O90Tis014201 for ; Mon, 24 Mar 2014 10:01:11 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jr6a926ah-1 for ; Mon, 24 Mar 2014 10:01:11 +0100 Received: from [192.168.0.102] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id D185B40117 for ; Mon, 24 Mar 2014 10:01:11 +0100 (CET) Message-ID: <532FF457.9000906@sics.se> Date: Mon, 24 Mar 2014 10:01:11 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ace@ietf.org References: <532F7D32.5020205@gmx.net> In-Reply-To: <532F7D32.5020205@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010500040505030504010306" X-Proofpoint-Spam-Reason: safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-23_03:2014-03-21,2014-03-23,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/CS-NTpZqG3OzCbzCWJKU2FEb4-0 Subject: Re: [Ace] Summary: Documenting Use Cases and Requirements X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 09:01:15 -0000 This is a cryptographically signed message in MIME format. --------------ms010500040505030504010306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 03/24/2014 01:32 AM, Hannes Tschofenig wrote: > Hi all, > > Kepeng and I have been wondering what the conclusion regarding the use > case/requirement discussion was. > > We believe that there is consensus in the group to publish the > requirements and use cases as an informational RFC. We also have variou= s > persons who are willing to contribute their time to this work (as > co-authors). > > What is not quite clear to use is whether we should use a Wiki in the > interim period to allow more people to contribute their thoughts. > > To close this issue please let us know whether you would > a) prefer to contribute text to a Wiki, or -1 > b) via the mailing list (and let the draft authors / editors incorporat= e > the content into the document). +1 /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms010500040505030504010306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMjQwOTAxMTFaMCMGCSqGSIb3DQEJBDEW BBTeifaePs+nM4xzCIwimqrEGXXY0jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAJTjyKW+wmoM/6ZS0IPeHo9m4zm9k+8hqa/NqNfvOVcYFFoZt8Q0HJhNrsJQ9XDTLyhCm yD/Xh0ZVLvgWp/efxnSvxqmFCRuWsYiHJEr9jWeiBZILMDy3ikD4rmU6jyfaG3Nb6lu4Vz8d XPzfA5OnabDXUBH5yhwaPTPUQjLVywt0rxF4r366ynBlDr0AwVp7DvTWDvzxmOXg7IeNjSEh qo4rHo9ajM+KDgLU9kcP4LvGDhIYW1Ca3E6IcYcKGyfo5K0uom2/uCQQPSe3TVybEjk8DcY+ wJRHyG29+SfJ6p1TPvwe4q7q+A1/yDqqwUG0Q6KU4/uVFFEcJb7LjKpvfAAAAAAAAA== --------------ms010500040505030504010306-- From nobody Mon Mar 24 04:11:45 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF6F1A01CB for ; Mon, 24 Mar 2014 04:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4LP7zU9tQNG for ; Mon, 24 Mar 2014 04:11:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 15ADD1A01CD for ; Mon, 24 Mar 2014 04:11:37 -0700 (PDT) Received: from [192.168.10.151] ([46.218.78.54]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LtUHA-1XBNw22uns-010uFn; Mon, 24 Mar 2014 12:11:35 +0100 Message-ID: <533012E4.6010309@gmx.net> Date: Mon, 24 Mar 2014 12:11:32 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ludwig Seitz , ace@ietf.org References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532FEC78.3080905@sics.se> In-Reply-To: <532FEC78.3080905@sics.se> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ni2do6c6SCWF4jBitwjIHRKochCncQDIH" X-Provags-ID: V03:K0:vlUPwvsbEKGaBkDJ3sxyaDqFPcPH0nNKWvfbkzaujF75mUcyirp tJFtMnfJenR4dpdS9e6UJtaTgTt1pc0/uqnnn2UMziDFKuf8mI+EWEIxDv3uHhonyzqUgBD U9lMncOvXOM/lxypsajW9q8f5F01jxpl9MouKmn5P6Jns4/MHuh6Nc7FlG/KhWQ3GwkEN1r ICIVzTDOF884WqN4vGMog== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/v5m7m4eo_VddCF5wHbA99yrn5n0 Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:11:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ni2do6c6SCWF4jBitwjIHRKochCncQDIH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ludwig, On 03/24/2014 09:27 AM, Ludwig Seitz wrote: > On 03/24/2014 03:00 AM, Michael Richardson wrote: >> >> Hannes Tschofenig wrote: >> > based on the feedback at the BOF we concluded that proxies >> should be >> > part of the WG investigation. What wasn't clear was when an >> > investigation should be conducted. >> >> When you say proxies, I think you are talking about things which the >> end points are aware of (and may have to trust). It would include, >> but not >> be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!) >> >> Would we agree that the proxies are not transparent? >> >=20 > Yes! They break end-to-end security, if authentication is based on DTLS= =2E The question for me is whether the CORE working group had thought about the use of DTLS with CoAP proxies where the DTLS exchange intentionally terminates at the proxy. Of course, the term "end-to-end" has a different meaning there since the end in that case is the proxy rather than the final destination, such as a Web server. Maybe we will come to the conclusion that proxies are not inline with the desired security properties. More investigation will be needed but from a charter point of view I think we shouldn't add text to the charter about it; it appears to be premature and at a too detailed level.= Ciao Hannes >=20 > /Ludwig >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --ni2do6c6SCWF4jBitwjIHRKochCncQDIH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTMBLkAAoJEGhJURNOOiAthCsH/2PsdsNRlqMeHZZhC2Dtogc8 r+wtCO2jNIr0mEHIQyXQpM7AuSQHhP0fGsOEDrSKdrhJtKchPeiuS7nJjOYa8Bgq X8u9Fxnt5fltduBrp0IAVoHkxOn/8Q2s/vdh6YHJZ14ne+8GPtzbwc7RwnoC2Dnr fbM33rw1F8gjAPcoMeS5zRTXlzl7uT4dXlWX50fTxpzDP2gll3XRSuh17j887YtS m+pscT03W5jVJxiKZRUNt2ygU3muQBtknGRXyUsrkkkWVI6jqW0hnZuRPsj0w92u mK8utdtT4VY3L8+BniRLYeeKOx5rdbRjn5Wyfis16DM/zSAmFbQKAaYWKb4wUU8= =lUaL -----END PGP SIGNATURE----- --ni2do6c6SCWF4jBitwjIHRKochCncQDIH-- From nobody Mon Mar 24 05:25:55 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183501A01FB for ; Mon, 24 Mar 2014 05:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gea1T2VyW-2K for ; Mon, 24 Mar 2014 05:25:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 912111A01F0 for ; Mon, 24 Mar 2014 05:25:50 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id C86A420033; Mon, 24 Mar 2014 09:45:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9F36B63ABA; Mon, 24 Mar 2014 08:25:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6144763AB6; Mon, 24 Mar 2014 08:25:47 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <532F7A90.1040302@gmx.net> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fm4IU6YZ5be57T9Vx4lAAkp2AH0 Cc: Ace@ietf.org Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 12:25:53 -0000 --=-=-= Hannes Tschofenig wrote: >> Hannes Tschofenig wrote: >> > based on the feedback at the BOF we concluded that proxies should be >> > part of the WG investigation. What wasn't clear was when an >> > investigation should be conducted. >> >> When you say proxies, I think you are talking about things which the >> end points are aware of (and may have to trust). It would include, but not >> be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!) > During the discussions on the list I had to noticed that folks had > different use cases in mind. One was about protocol translation but > there are also cases that have nothing to do with protocol translation > but rather with the use of CoAP itself and how some seem to have assumed > how it works. >> Would we agree that the proxies are not transparent? > Transparency is a fuzzy term here. > Is a protocol translator transparent of not and the question is to whom > is it transparent? Absent security, one can build a MITM translator that turns CoAP into HTTP, maintaining what is essentially a 1:1 NAT (not NAPT). That's a transparent proxy: one which only end to end security will notice. SIP proxies are not transparent. > I believe I am saying that we all have not thought about the proxy topic > enough to make a conclusion that could go into the charter and for that > reason I am trying to encourage those who have expertise in this field > to make contributions as early as possible. We have to include 1) non-transparent proxies in the model, for the same reasons it useful for SIP. We need to define how to trust them, and what they do with the authorization tokens. It must be possible to observe the presence of the proxy for audit purposes, and I would not have to give them superuser. 2) a mechanism for what would otherwise appear to be a MITM transparent proxy to make itself known. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzAkS4qHRg3pndX9AQKc2AP9EakKsrwYCNl1JnvXMJ/gBrZqZOIM/eNW YU/t19c1uMlt8nsJIZbti+aC/3UUcMUUbouDGNz9rygfBj7x1O8qtkoK2n9K+IVV w1OYTMFYAxNj3Hdvc2wx8euG1zLs4Bq04BmI1G+7lPtrYEcfm+ETfkGVdJ51wp8J RN5ydPnp1dU= =2vir -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 05:33:27 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BCC1A01F1 for ; Mon, 24 Mar 2014 05:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eihAwJqQyDB1 for ; Mon, 24 Mar 2014 05:33:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 67A861A01EE for ; Mon, 24 Mar 2014 05:33:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 55D9720033; Mon, 24 Mar 2014 09:53:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A819763ABA; Mon, 24 Mar 2014 08:33:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9859A63AB6; Mon, 24 Mar 2014 08:33:22 -0400 (EDT) From: Michael Richardson To: Ludwig Seitz In-Reply-To: <532FF457.9000906@sics.se> References: <532F7D32.5020205@gmx.net> <532FF457.9000906@sics.se> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/f8eHjr1A2C_TT9cVLJLFiLa_Q-o Cc: ace@ietf.org Subject: Re: [Ace] Summary: Documenting Use Cases and Requirements X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 12:33:25 -0000 --=-=-= > On 03/24/2014 01:32 AM, Hannes Tschofenig wrote: >> Hi all, >> >> Kepeng and I have been wondering what the conclusion regarding the use >> case/requirement discussion was. >> >> We believe that there is consensus in the group to publish the >> requirements and use cases as an informational RFC. We also have various >> persons who are willing to contribute their time to this work (as >> co-authors). But that the milestones not show it as a pre-requiste (critical path) towards solutions. >> >> What is not quite clear to use is whether we should use a Wiki in the >> interim period to allow more people to contribute their thoughts. >> >> To close this issue please let us know whether you would >> a) prefer to contribute text to a Wiki, or Ludwig Seitz wrote: > -1 -2 >> b) via the mailing list (and let the draft authors / editors incorporate >> the content into the document). > +1 +2 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzAmEoqHRg3pndX9AQLABgP9GCCvGUG00+DRfrJ00gyTstcitBc0b7zu UgyY/xRaqc8cD1oxEaUIH0/7o/kgjVIhkrT2t/6Jn+GEoyRzSXgK181kyinBSTSG dtyiEL/qUkRy32xwhEBVkujjNIHLkxHIozFZ30RkJENFbnhrj7QV40pAThNAE5q9 DJWX5hInF6I= =rElK -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 08:46:26 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08ED1A0259 for ; Mon, 24 Mar 2014 08:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtEjpjFend8B for ; Mon, 24 Mar 2014 08:46:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id AC3031A022B for ; Mon, 24 Mar 2014 08:46:22 -0700 (PDT) Received: from [192.168.10.152] ([46.218.78.54]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3S2C-1XIykN3XHs-00r41r; Mon, 24 Mar 2014 16:46:20 +0100 Message-ID: <53305348.2020105@gmx.net> Date: Mon, 24 Mar 2014 16:46:16 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Richardson References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> In-Reply-To: <22120.1395663947@sandelman.ca> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pAV8JMVNtBuA6Mtr8V9lu0GjgajASTTvT" X-Provags-ID: V03:K0:ZFVXt4yanhA3JulCCWROo1VU8VDDZgfjggVC2U/nr4yg1CvyZ3W Ns/CePMtU2BG9Vs+gKI7+Ii3aGN7YnhRoGhX4tm2N6wSMIecN6/+JyfQ9WCOjtusZ14wmlw nuui7aoT9I6Yp2wMqMGJQZ7vDyt5d6FUZtAKwggCtiRNYtuueHX/tm11dJubuGs3JowSK5g TNy2wZgTNA8y92Ojbmyfg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/29vGnw1BwVk53Hq4fDqlS7kmemw Cc: Ace@ietf.org Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:46:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pAV8JMVNtBuA6Mtr8V9lu0GjgajASTTvT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, I agree that someone should look at this and I am curious who would be doing that. Maybe the CORE working group would be a good place since they are dealing with proxies in general already (e.g., mirror server, sleeping proxy). Maybe it is best done in this group (since there is this security focus).= What is your take? Would you want to work on this topic? Ciao Hannes On 03/24/2014 01:25 PM, Michael Richardson wrote: >=20 > Hannes Tschofenig wrote: > >> Hannes Tschofenig wrote: > >> > based on the feedback at the BOF we concluded that proxies sho= uld be > >> > part of the WG investigation. What wasn't clear was when an > >> > investigation should be conducted. > >> > >> When you say proxies, I think you are talking about things which= the > >> end points are aware of (and may have to trust). It would inclu= de, but not > >> be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!) >=20 > > During the discussions on the list I had to noticed that folks ha= d > > different use cases in mind. One was about protocol translation b= ut > > there are also cases that have nothing to do with protocol transl= ation > > but rather with the use of CoAP itself and how some seem to have = assumed > > how it works. >=20 > >> Would we agree that the proxies are not transparent? >=20 > > Transparency is a fuzzy term here. >=20 > > Is a protocol translator transparent of not and the question is t= o whom > > is it transparent? >=20 > Absent security, one can build a MITM translator that turns CoAP into H= TTP, > maintaining what is essentially a 1:1 NAT (not NAPT). That's a transp= arent > proxy: one which only end to end security will notice. >=20 > SIP proxies are not transparent. >=20 > > I believe I am saying that we all have not thought about the prox= y topic > > enough to make a conclusion that could go into the charter and fo= r that > > reason I am trying to encourage those who have expertise in this = field > > to make contributions as early as possible. >=20 > We have to include > 1) non-transparent proxies in the model, for the same reasons it usef= ul > for SIP. We need to define how to trust them, and what they do wi= th > the authorization tokens. It must be possible to observe the pres= ence > of the proxy for audit purposes, and I would not have to give them= > superuser. >=20 > 2) a mechanism for what would otherwise appear to be a MITM transpare= nt > proxy to make itself known. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 --pAV8JMVNtBuA6Mtr8V9lu0GjgajASTTvT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTMFNJAAoJEGhJURNOOiAt56sH/1j6ZYdYGvj6Ihs/etc3/XZa JGhV1qHhsp5lH9xrzimyFQweaXNfou1qYTEABkfydCFBrI6+kQGAH+gJs2608PkG D/bjhvPUlmJ7++n4GW4ZKEJTJ3WwiOJj2qEOl7CIkCo7pgco6lyOR7ivXEEOmN1o yHw1x5PeKHSmh93jesl5tOSf5E8vqee2rt7cqTu8foSKqrIkFEAjwdjp17lV2m69 qUOJuI6zirtU8EiLJbXMmcSw2dyZAObqofYoBi3bI4cdYMejJqLfUiPEbeqZ+rTT B+Y3gbGP3JIDx2Ajfa1w8J6kJU0guZedPAmiavtHqFOiQGo6R9Fo5GU6eUeYzCM= =VyKi -----END PGP SIGNATURE----- --pAV8JMVNtBuA6Mtr8V9lu0GjgajASTTvT-- From nobody Mon Mar 24 10:47:10 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94241A0251 for ; Mon, 24 Mar 2014 10:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHvdVJmc0n6s for ; Mon, 24 Mar 2014 10:47:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id ABE6D1A026F for ; Mon, 24 Mar 2014 10:47:05 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9459920049; Mon, 24 Mar 2014 15:06:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5622863ABA; Mon, 24 Mar 2014 13:47:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 47B8463AA2; Mon, 24 Mar 2014 13:47:03 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <53305348.2020105@gmx.net> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/TVJP6QuYxGvmZaZn_cW8-V5evbU Cc: Ace@ietf.org Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 17:47:07 -0000 --=-=-= Hannes Tschofenig wrote: > I agree that someone should look at this and I am curious who would be > doing that. > Maybe the CORE working group would be a good place since they are > dealing with proxies in general already (e.g., mirror server, sleeping > proxy). > Maybe it is best done in this group (since there is this security focus). > What is your take? Would you want to work on this topic? I believe that it must be done in ACE, because, when providing any kind of auhorization token, it may be necessary to provide pieces of it to the proxy as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzBvl4qHRg3pndX9AQJphgP/Y7PLuGv/O9W61JaZkzJiZag1SonLFC11 ZZUBHChVbuLam+0rAgBX8vn/uOMwRSmFAFUSW8le67QHBBUqzcgovWixa1U2cco+ SONn2W3MIGpF0rRQhJnIlXcdkRprIxXZCQ1msMqDRn+/w9Yn419S90J9i7E1qnoi XtfSX3pkNc4= =2d9b -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 11:40:27 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7881A028E for ; Mon, 24 Mar 2014 11:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoG8-UR4q9L4 for ; Mon, 24 Mar 2014 11:40:22 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan17.extendcp.co.uk [79.170.45.29]) by ietfa.amsl.com (Postfix) with ESMTP id 869311A0128 for ; Mon, 24 Mar 2014 11:40:22 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WS9nH-0007oE-IV; Mon, 24 Mar 2014 18:40:19 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WS9nH-0003vw-AR; Mon, 24 Mar 2014 18:40:19 +0000 Received: from host86-156-209-214.range86-156.btcentralplus.com ([86.156.209.214] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WS9nF-0002nx-HB; Mon, 24 Mar 2014 18:40:17 +0000 Message-ID: <53307C3B.6060903@gridmerge.com> Date: Mon, 24 Mar 2014 18:40:59 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Richardson , Ludwig Seitz References: <532F7D32.5020205@gmx.net> <532FF457.9000906@sics.se> <24128.1395664402@sandelman.ca> In-Reply-To: <24128.1395664402@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070901010501000101030404" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/RZxotMhJHAbTIUYe0FmMTim_Adg Cc: ace@ietf.org Subject: Re: [Ace] Summary: Documenting Use Cases and Requirements X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 18:40:25 -0000 This is a cryptographically signed message in MIME format. --------------ms070901010501000101030404 Content-Type: multipart/alternative; boundary="------------020901010906040502030609" This is a multi-part message in MIME format. --------------020901010906040502030609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I tend to agree - if an RFC is going to be produced and there are=20 appointed editors, the use of a Wiki doesn't really seem to offer much=20 benefit. Also agree with the point about it not being a gating item. Robert On 24/03/2014 12:33 PM, Michael Richardson wrote: > > On 03/24/2014 01:32 AM, Hannes Tschofenig wrote: > >> Hi all, > >> > >> Kepeng and I have been wondering what the conclusion regarding = the use > >> case/requirement discussion was. > >> > >> We believe that there is consensus in the group to publish the > >> requirements and use cases as an informational RFC. We also hav= e various > >> persons who are willing to contribute their time to this work (= as > >> co-authors). > > But that the milestones not show it as a pre-requiste (critical path) t= owards > solutions. > > >> > >> What is not quite clear to use is whether we should use a Wiki = in the > >> interim period to allow more people to contribute their thought= s. > >> > >> To close this issue please let us know whether you would > >> a) prefer to contribute text to a Wiki, or > > Ludwig Seitz wrote: > > -1 > > -2 > > >> b) via the mailing list (and let the draft authors / editors in= corporate > >> the content into the document). > > > +1 > > +2 > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------020901010906040502030609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I tend to agree - if an RFC is going to be produced and there are appointed editors, the use of a Wiki doesn't really seem to offer much benefit. Also agree with the point about it not being a gating item.

Robert

On 24/03/2014 12:33 PM, Michael Richardson wrote:
= 
    > On 03/24/2014 01:32 AM, Hannes Tschofenig wrote:
    >> Hi all,
    >>
    >> Kepeng and I have been wondering what the conclusion regardi=
ng the use
    >> case/requirement discussion was.
    >>
    >> We believe that there is consensus in the group to publish t=
he
    >> requirements and use cases as an informational RFC. We also =
have various
    >> persons who are willing to contribute their time to this wor=
k (as
    >> co-authors).

But that the milestones not show it as a pre-requiste (critical path) tow=
ards
solutions.

    >>
    >> What is not quite clear to use is whether we should use a Wi=
ki in the
    >> interim period to allow more people to contribute their thou=
ghts.
    >>
    >> To close this issue please let us know whether you would
    >> a) prefer to contribute text to a Wiki, or

Ludwig Seitz <ludwig@sics.se> wrote:
    > -1

-2

    >> b) via the mailing list (and let the draft authors / editors=
 incorporate
    >> the content into the document).

    > +1

+2

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software =
Works
 -=3D IPv6 IoT consulting =3D-






_______________________________________________
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace

--------------020901010906040502030609-- --------------ms070901010501000101030404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMjQxODQwNTlaMCMGCSqGSIb3DQEJBDEWBBQgnaJCEYazVYa3TSHZtfD6OtFZ7zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAJytZSeGQY/JqkqtIE9Z9euIzRVdJxLhwOAQOVeVm4xwDbU5 Kvv9eRptaOTbWWwRT6iTQ9PYyirFWmX3Gs9pqdgtc88o3nRfPFySu8CyMCDAd2cBnaO+wp+a 5kpj48SkBruhIMedSdF2yh6FVh05HdSVsy6CiZ7b0lYOERJHEql2TXzXIStpPqzzlVVOBp9p pJHfE0kW1qobRNdsXgD8fUFIs6/1ntkyemY3c5BbqcLz2YqrqIwmjT86NQIlqiXvu01kIs12 2gVt8DicytcKR6Zf1URb/f2ygucyWqQbQGYgetso3NI92USPl9uPuVskwHTJ37Rgpj8ImbGN nipXOMkAAAAAAAA= --------------ms070901010501000101030404-- From nobody Mon Mar 24 12:50:55 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584741A02D7 for ; Mon, 24 Mar 2014 12:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br_VdXYcT_BG for ; Mon, 24 Mar 2014 12:50:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 649861A02D2 for ; Mon, 24 Mar 2014 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2OJolGl014007 for ; Mon, 24 Mar 2014 20:50:48 +0100 (CET) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B938E1A4 for ; Mon, 24 Mar 2014 20:50:47 +0100 (CET) Received: by mail-ve0-f171.google.com with SMTP id cz12so6294140veb.16 for ; Mon, 24 Mar 2014 12:50:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=8o5UCVVu0GOFAwTJZ31ixygZ1xjm4LXTVN90zACuY9A=; b=LndgfvpyNkVcLtK+WsGIbCSAQAXGpQ7puFsJq8mhaN6oSj3yw6HRxHc8g6ZZ9u2vHz O3Wh9phXJ8hrdwaGl7tInpywrNBxpMlYCYKGJQnpr1zCFnLRSijh134qM0KNtrGr8kkF hbpcON6I953nWUZ7NfI0k7pnSAmhp/Ye+NF3/Kt+RkcR3/tHc7x6Jh+bd8xtGybrfmJt cikcYuaL91MFGzasfwQHzHBG9w7WSEi6ix4DCHF6/29RuHkbEKZKUyrS9VuPkfLNa6SZ SdsmZXQC/5hvNPoTcZIqypQrXG/ZfDwkJkuUjQKtj3CtiihBeXEpVDZB+tNfqu6TPpxI Rmng== X-Received: by 10.220.159.4 with SMTP id h4mr41093023vcx.1.1395690646390; Mon, 24 Mar 2014 12:50:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.242 with HTTP; Mon, 24 Mar 2014 12:50:06 -0700 (PDT) In-Reply-To: <26153.1395683223@sandelman.ca> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> From: Klaus Hartke Date: Mon, 24 Mar 2014 20:50:06 +0100 Message-ID: To: Ace@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/uQuFrJV25HbkKtzu5ZTeLP-3P3Y Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:50:53 -0000 CoAP provides two (syntactically different) ways for a client (or intermediary in the role of a client) to perform a request: (I'm using representation retrieval as example WOLOG.) A.) the client requests a remote endpoint to return a representation of a resource located _in that endpoint's namespace_. B.) the client requests a remote endpoint to return a representation of a resource located _in another endpoint's namespace_. In both cases, it's generally up to the remote endpoint how it obtains the representation of the target resource, as long as the result *is* a representation of the target resource. For example, in A., the remote endpoint can serve a local file (the endpoint is then typically called a "server"), return the output of a CGI script ("CGI gateway"), obtain the representation from an HTTP server ("cross-protocol proxy"), or obtain the representation from another CoAP remote endpoint ("reverse proxy"). In B., the remote endpoint is generally expected to obtain the representation by requesting it from the endpoint specified in the request URI ("forward proxy"). In both cases, the client has no way to verify that the obtained result is indeed a representation of the target resource. It must trust the remote endpoint that it returns the correct representation. DTLS just secures the transmission of the representation from the remote endpoint to the client. (AFAIK, HTTP works exactly the same way.) So, I would say that - ACE should consider forward proxies, reverse proxies and potentially cross-protocol proxies such that one of these can obtain a representation of a resource that a client is authorized to access on behalf of that client; and - ACE should not consider remote endpoints that cannot be trusted to correctly return a representation of a target resource (as this concerns the general security of CoAP which should be addressed in CoRE). Klaus From nobody Mon Mar 24 14:41:21 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C3D1A02F4 for ; Mon, 24 Mar 2014 14:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXXAhZvRk0Et for ; Mon, 24 Mar 2014 14:41:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 831AA1A02F3 for ; Mon, 24 Mar 2014 14:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2OLfEPZ013962 for ; Mon, 24 Mar 2014 22:41:14 +0100 (CET) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 866851ED for ; Mon, 24 Mar 2014 22:41:14 +0100 (CET) Received: by mail-vc0-f182.google.com with SMTP id ks9so6493882vcb.41 for ; Mon, 24 Mar 2014 14:41:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TamGEkirySVkbhiymLxkNBjqwxksMVXev9XHl8ZgXZo=; b=dnpvqprxAZPcA7/zvamVwtLru1OSkWa6JYptXQFDPbHcHOzhrViKy4bjQfQqsslZap 5jsLAEjdknawgcZl9heDqadEMfL9JE/x0JjpMcBzWLyASf14lfOrndHSEB+bEVibTOUB 7Z/CBvd8VyiLoEMgAe/hbBj/teJhGvo7+WnkgreAdUN2VW3Wzwd+3DIIkqdSW4zIuwlU bZGxSg0sD7FAzz4GXDX/ym26jCLVaMjZy+Oo0CKQrnQKafNmB5hY7Mo6Y//X0fzk+2Al UXPHAveqKC4V08DYhglieRaqdiEFBXQRtAq1tUKhRp/cJctkMMAwBdgkD2UVkR1j2zjU AttQ== MIME-Version: 1.0 X-Received: by 10.221.4.66 with SMTP id ob2mr2553623vcb.28.1395697273216; Mon, 24 Mar 2014 14:41:13 -0700 (PDT) Received: by 10.52.89.242 with HTTP; Mon, 24 Mar 2014 14:41:13 -0700 (PDT) In-Reply-To: References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> Date: Mon, 24 Mar 2014 22:41:13 +0100 Message-ID: From: Klaus Hartke To: "Ace@ietf.org" Content-Type: multipart/alternative; boundary=089e0122a9242f250004f56118f5 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/dotIxMawuTCIzRZi2gzcDmW8vUQ Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 21:41:20 -0000 --089e0122a9242f250004f56118f5 Content-Type: text/plain; charset=ISO-8859-1 Klaus Hartke wrote: > (AFAIK, HTTP works exactly the same way.) > I forgot that HTTP has tunnels [1]. CoAP doesn't have tunnels. Klaus [1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#page-10 --089e0122a9242f250004f56118f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Klaus Hartke <hartke@tzi.org> w= rote:
(AFAIK, HTTP works exactly the same= way.)

I forgot that HTTP has tunnels [1]. CoAP d= oesn't have tunnels.

Klaus

--089e0122a9242f250004f56118f5-- From nobody Mon Mar 24 22:52:09 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD1A1A0364 for ; Mon, 24 Mar 2014 22:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYFE7WCkbxGd for ; Mon, 24 Mar 2014 22:52:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0541A0369 for ; Mon, 24 Mar 2014 22:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2P5q2HD007590 for ; Tue, 25 Mar 2014 06:52:02 +0100 (CET) Received: from [5.169.244.145] (unknown [5.169.244.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8E04424D; Tue, 25 Mar 2014 06:52:02 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-8BF6F188-82D7-4C9F-9CC1-CC039BE12AF8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D167) In-Reply-To: Date: Tue, 25 Mar 2014 06:52:01 +0100 Content-Transfer-Encoding: 7bit Message-Id: <7C26D4A5-9D50-4699-8F8E-CB673E14DB74@tzi.org> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> To: Klaus Hartke Archived-At: http://mailarchive.ietf.org/arch/msg/ace/jHBSuyqT7BZ1VisaD3II2Q1yDXw Cc: "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 05:52:07 -0000 --Apple-Mail-8BF6F188-82D7-4C9F-9CC1-CC039BE12AF8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ... But it would not be hard to add them if there is a point. https://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-A.6 shows a s= tateful way.=20 Or http://tools.ietf.org/html/draft-schmertmann-dice-codtls-00 could be exte= nded to also carry data.=20 For coap-to-coap, we didn't add these as so far nobody saw a point. Maybe th= ere is one for cross-proxying. But, as Hannes said, we need to understand th= e use cases first. Gr=C3=BC=C3=9Fe, Carsten=20 > On 24.03.2014, at 22:41, Klaus Hartke wrote: >=20 > CoAP doesn't have tunnels. --Apple-Mail-8BF6F188-82D7-4C9F-9CC1-CC039BE12AF8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
... But it would not be hard to add th= em if there is a point.

Or http://tools.ietf.org/html/draft-schmertmann-dice-codtls= -00 could be extended to also carry data. 

For coap-to-coap, we didn't add these as so far nobody saw a point. Ma= ybe there is one for cross-proxying. But, as Hannes said, we need to underst= and the use cases first.

Gr=C3=BC=C3=9Fe, Carsten&n= bsp;

On 24.03.2014, at 22:41, Klaus Hartke <hartke@tzi.org> wrote:

CoAP doesn't have tunnels.
= --Apple-Mail-8BF6F188-82D7-4C9F-9CC1-CC039BE12AF8-- From nobody Tue Mar 25 01:47:56 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4121A038D for ; Tue, 25 Mar 2014 01:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Fbu1X2ZKffG for ; Tue, 25 Mar 2014 01:47:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 456B61A00F4 for ; Tue, 25 Mar 2014 01:47:52 -0700 (PDT) Received: from [192.168.10.154] ([46.218.78.54]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Meg8W-1Whj770NKa-00OG0q; Tue, 25 Mar 2014 09:47:41 +0100 Message-ID: <533142AA.4040108@gmx.net> Date: Tue, 25 Mar 2014 09:47:38 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Klaus Hartke , Ace@ietf.org References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5bjVFAeUdUi09jSrg1MB9ooQknuTrXBPi" X-Provags-ID: V03:K0:G2gnLEATBa5A4etd1oaRFlIbAAPWhdNuu8YVdqXS1lWKezS0AkO lSr+XW5856QxwTS70fmp7nTUrO+jOS2Vk+WvNJ+YP7c6ctQyIwj7T9qo7wymeX04WdI6M1p ZJtyQ/nOXm/nFqULzcd3G86RqoZpUgG1VUbqdRPE6E/CqZRS/CrhV3eOSkRPkakdB9G7hhQ YpDRLMLBxcrpMoWafDepQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/6BvwJWDZu-hyKcyX8CYxKtLSz1Y Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 08:47:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5bjVFAeUdUi09jSrg1MB9ooQknuTrXBPi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Klaus, thanks for the description. Since I am not sure I understood it correctly I have a couple of basic questions. On 03/24/2014 08:50 PM, Klaus Hartke wrote: > CoAP provides two (syntactically different) ways for a client (or > intermediary in the role of a client) to perform a request: > (I'm using representation retrieval as example WOLOG.) >=20 > A.) the client requests a remote endpoint to return a representation > of a resource located _in that endpoint's namespace_. >=20 > B.) the client requests a remote endpoint to return a representation > of a resource located _in another endpoint's namespace_. The client device will start with a specific FQDN and will start a DTLS handshake with that server. Where does the "requests a remote endpoint to return ...." come into the play? >=20 > In both cases, it's generally up to the remote endpoint how it obtains > the representation of the target resource, as long as the result *is* > a representation of the target resource. > For example, in A., the remote endpoint can serve a local file (the > endpoint is then typically called a "server"), return the output of a > CGI script ("CGI gateway"), obtain the representation from an HTTP > server ("cross-protocol proxy"), or obtain the representation from > another CoAP remote endpoint ("reverse proxy"). In B., the remote > endpoint is generally expected to obtain the representation by > requesting it from the endpoint specified in the request URI ("forward > proxy"). >=20 > In both cases, the client has no way to verify that the obtained > result is indeed a representation of the target resource. It must > trust the remote endpoint that it returns the correct representation. > DTLS just secures the transmission of the representation from the > remote endpoint to the client. >=20 > (AFAIK, HTTP works exactly the same way.) In the HTTPS case the story is as follows: * The client contacts the server behind a https://www.ietf.org (after doing a DNS look-up) using TLS. * It gets the cert from the server. * The client compares the content of the cert with what it had initially requested to ensure it talks to the right server. The TLS will prevent any proxy along the path to cache the data (since it is encrypted). So, I am not sure how this compares to CoAP based on your description. Ciao Hannes >=20 > So, I would say that >=20 > - ACE should consider forward proxies, reverse proxies and potentially > cross-protocol proxies such that one of these can obtain a > representation of a resource that a client is authorized to access on > behalf of that client; and >=20 > - ACE should not consider remote endpoints that cannot be trusted to > correctly return a representation of a target resource (as this > concerns the general security of CoAP which should be addressed in > CoRE). >=20 > Klaus >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --5bjVFAeUdUi09jSrg1MB9ooQknuTrXBPi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTMUKrAAoJEGhJURNOOiAtlYwH/R3cTxsLv1ReONahm85Mev/m 4c7y1G5qDzzdUE3XVhxd0Czz3mdqqHZbuUl0G26YaFppz8dxnuAaGOZWjEfjymVk NCVSTRWNTYLCsDjK/tOCWB5bsEEyshlHV29CSmdsNqAdhgWHBMZepP2pkSmbX4sl owVAtzaZkgDNs1nJhOaFbuQkuVSw9xwPVdHHgG6D0MHuPxxFbwgI9OQ0W5iiJbga 6vQsI8zb1JU2hs2ZiyyatelS78xEV3LEiPhRrK9g56qMjMN25XZYiiTyIg/FAX+A wVordUhx0fOLtYeE7DtrE5erD3qQt91RKCZSnmArsPAB4ooWkeWJ2O8Bleo5z78= =e5nh -----END PGP SIGNATURE----- --5bjVFAeUdUi09jSrg1MB9ooQknuTrXBPi-- From nobody Tue Mar 25 07:49:03 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA21A014B for ; Tue, 25 Mar 2014 07:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvyD_uU706rS for ; Tue, 25 Mar 2014 07:48:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E431A1A0133 for ; Tue, 25 Mar 2014 07:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2PEmor9020209 for ; Tue, 25 Mar 2014 15:48:50 +0100 (CET) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A31ED6EF for ; Tue, 25 Mar 2014 15:48:49 +0100 (CET) Received: by mail-pd0-f169.google.com with SMTP id fp1so535598pdb.14 for ; Tue, 25 Mar 2014 07:48:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=WdO2D/sbMu0uBNyOPyehScqODpynfAMlZge0wrSprMM=; b=B/LUPJis4jNI3gs6t0e3U0bq944tsakXCPvemoXs1RsneKZFwVfyy7Mo7d/7nPALfb e4tFxSat7utDnVaUp/Rlpw2WZiSxn3/yoGdUR5MxJMvoSz9fKvGx20h5wISuTvM/EhqR Hw+duimFASQ5fn9ykuXGAwBOHe8UZ+qtWQVJiT+QRfgHG5ifLDC9XQplKwBzZUqIFDxl eRQjhVipX8V+ikBVJXs/oF7f36osSx10mn3dHNES9QzZqFewerJznfP6oYyOvGrVY1s2 hZebug9kG3PzB8eQo/rZ4UMLtZ7ngc2HwOyNHdNoU39kax3oQWoY148OiRAFYrig7ix/ xiow== X-Received: by 10.69.31.171 with SMTP id kn11mr80204867pbd.47.1395758927625; Tue, 25 Mar 2014 07:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.54.66 with HTTP; Tue, 25 Mar 2014 07:48:07 -0700 (PDT) In-Reply-To: <533142AA.4040108@gmx.net> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> From: Klaus Hartke Date: Tue, 25 Mar 2014 15:48:07 +0100 Message-ID: To: "Ace@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/brR7gL9JTtRuZMSzcTlCtcZhvPE Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:48:56 -0000 Hi Hannes, here are a few examples. In each example, the client wants to obtain a representation of {coaps,https}://example.org/path/to/resource. All examples work for both CoAP and HTTP, except for the last which only works for HTTP. Example 1: Client---Origin Server[example.org] 1. The client resolves and establishes a secure connection to example.org 2. The client requests a representation of the resource /path/to/resource by sending a GET request message 3. The origin server satisfies the request by serving a local file to the client Example 2: Client---Reverse Proxy[example.org]---Origin Server[example.net] 1. The client resolves and establishes a secure connection to example.org 2. The client requests a representation of the resource /path/to/resource 3. The reverse proxy chooses to satisfy the request by obtaining the representation of {coaps,https}://example.net/some/other/resource a. The reverse proxy resolves and establishes a secure connection to example.net b. The reverse proxy requests a representation of the resource /some/other/resource c. The origin server satisfies the request by serving a local file to the reverse proxy 4. The reverse proxies serves the representation to the client Example 3: Client---Forward Proxy[proxy.example]---Origin Server[example.org] 1. The client resolves and establishes a secure connection to proxy.example 2. The client requests a representation of the resource {coaps,https}://example.org/path/to/resource 3. The forward proxy satisfies the request by obtaining the representation of {coaps,https}://example.org/path/to/resource a. The forward proxy resolves and establishes a secure connection to example.org b. The forward proxy requests a representation of the resource /path/to/resource c. The origin server satisfies the request by serving a local file to the forward proxy 4. The forward proxy serves the representation to the client Example 4: Client---Tunnel[tunnel.example]---Origin Server[example.org] 1. The client resolves and establishes an unsecured connection to tunnel.example 2. The client requests the tunnel to establish an unsecured connection to example.org and to act as a blind relay between the two connections 3. The tunnel satisfies the request by resolving and establishing an unsecured connection to example.org 4. The client establishes a secure connection to the origin server through the tunnel 5. The client requests a representation of the resource /path/to/resource 6. The origin server satisfies the request by serving a local file to the client Does that answer your questions? Klaus On 25 March 2014 09:47, Hannes Tschofenig wrote: > Hi Klaus, > > thanks for the description. Since I am not sure I understood it > correctly I have a couple of basic questions. > > On 03/24/2014 08:50 PM, Klaus Hartke wrote: >> CoAP provides two (syntactically different) ways for a client (or >> intermediary in the role of a client) to perform a request: >> (I'm using representation retrieval as example WOLOG.) >> >> A.) the client requests a remote endpoint to return a representation >> of a resource located _in that endpoint's namespace_. >> >> B.) the client requests a remote endpoint to return a representation >> of a resource located _in another endpoint's namespace_. > > The client device will start with a specific FQDN and will start a DTLS > handshake with that server. Where does the "requests a remote endpoint > to return ...." come into the play? > > > >> >> In both cases, it's generally up to the remote endpoint how it obtains >> the representation of the target resource, as long as the result *is* >> a representation of the target resource. >> For example, in A., the remote endpoint can serve a local file (the >> endpoint is then typically called a "server"), return the output of a >> CGI script ("CGI gateway"), obtain the representation from an HTTP >> server ("cross-protocol proxy"), or obtain the representation from >> another CoAP remote endpoint ("reverse proxy"). In B., the remote >> endpoint is generally expected to obtain the representation by >> requesting it from the endpoint specified in the request URI ("forward >> proxy"). >> >> In both cases, the client has no way to verify that the obtained >> result is indeed a representation of the target resource. It must >> trust the remote endpoint that it returns the correct representation. >> DTLS just secures the transmission of the representation from the >> remote endpoint to the client. >> >> (AFAIK, HTTP works exactly the same way.) > > In the HTTPS case the story is as follows: > > * The client contacts the server behind a https://www.ietf.org (after > doing a DNS look-up) using TLS. > > * It gets the cert from the server. > > * The client compares the content of the cert with what it had initially > requested to ensure it talks to the right server. > > The TLS will prevent any proxy along the path to cache the data (since > it is encrypted). > > So, I am not sure how this compares to CoAP based on your description. > > Ciao > Hannes > > >> >> So, I would say that >> >> - ACE should consider forward proxies, reverse proxies and potentially >> cross-protocol proxies such that one of these can obtain a >> representation of a resource that a client is authorized to access on >> behalf of that client; and >> >> - ACE should not consider remote endpoints that cannot be trusted to >> correctly return a representation of a target resource (as this >> concerns the general security of CoAP which should be addressed in >> CoRE). >> >> Klaus From nobody Tue Mar 25 13:12:11 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483221A00E6 for ; Tue, 25 Mar 2014 13:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCHrXhnJSpmL for ; Tue, 25 Mar 2014 13:11:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2B01A002A for ; Tue, 25 Mar 2014 13:11:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3123E20090 for ; Tue, 25 Mar 2014 17:31:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EB78D63ABA; Tue, 25 Mar 2014 16:11:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D602863AA2 for ; Tue, 25 Mar 2014 16:11:44 -0400 (EDT) From: Michael Richardson To: "Ace\@ietf.org" In-Reply-To: References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/A7WpD8NgFzTuSmOjAkmRD0kHzZM Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 20:11:52 -0000 --=-=-= I'm going to keep just the step two, because it's where the differences are. Klaus Hartke wrote: > 2. The client requests a representation of the resource > /path/to/resource by sending a GET request message > 2. The client requests a representation of the resource > /path/to/resource > 2. The client requests a representation of the resource > {coaps,https}://example.org/path/to/resource > 2. The client requests the tunnel to establish an unsecured connection > to example.org and to act as a blind relay between the two > connections There is a fifth situation which we try never to talk about: Example 5: Client---TransparentProxy[proxy.example]--Origin Server[example.org] 1. client opens a connection to example.org. TCP connection is intercepted (think NAPT, not perpass) by proxy.example. 2. client requests a representation of the resource /path/to/resource 3. proxy.example, connects to real example.org (by IP, which it observed in the TCP getsockname()), requests resource, returns it to client. This is not a blind relay tunnel. This is how hundreds of firewalls that do virus scanning whether as a bump in the stack, bump in the cord, or network device work (for good or bad!) The relevant situation that I understand, and which I think might want to support is: Example 6: Client---HTTP/CoAPProxy[proxy.example]--Origin Server[example.org] 1. client opens a connection to example.org. TCP/HTTPS connection is intercepted (think NAPT, not perpass) by proxy.example. 2. client requests a representation of the resource /path/to/resource 3. proxy.example, connects to real example.org by CoAP/DTLS (by IP, which it observed in the TCP getsockname()), requests resource, returns it to client, possibly caching the result. Note that if assume the real address of example.org is not the same as the address that the client saw, (which given that v6 has many more addresses to play with...) then this is really closer to example 2. It just might be that the reverse proxy has been given an algorithm to map blahblah::1234 -> hahaha::1234, rather than having every single one of them preconfigured. I want to be able to do this securely such that the this man-in-the-middle is clearly authorized to be in the middle, and with an audit trail that becomes visible to both client and origin servers. It's also clear to me that the authorization on the left probably has to play nicely with OAuth2. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzHi/oqHRg3pndX9AQLn4wQAqjYanPQUcHe4iBGYDNh/TaPYz+UCZZOD IlUnxB1zmSEyedf5EKIWWjHL87bcjpmH//oltSZ6euUh0Z/UBMo3ONnhDISpr63s KzDiTRyObez1SPTipAVXP+yvw7OKRphCM8BgzYjYbQ1LmrZYFO60X26Co9SO6UFM aoIy9DoguVI= =FH5Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 26 19:47:41 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F851A004A for ; Wed, 26 Mar 2014 19:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRQFHy7JxFiC for ; Wed, 26 Mar 2014 19:47:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 99B981A005F for ; Wed, 26 Mar 2014 19:47:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEZ26453; Thu, 27 Mar 2014 02:47:29 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 02:46:53 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 02:47:28 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 27 Mar 2014 10:47:22 +0800 From: Likepeng To: Hannes Tschofenig , Michael Richardson Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyGaZCy7gapW0iSUYgVT5QsOJru9ZoA///keQCABUQOIA== Date: Thu, 27 Mar 2014 02:47:22 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0A1A2@SZXEMA501-MBS.china.huawei.com> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> In-Reply-To: <532F7A90.1040302@gmx.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/hVW72bEcOQywLu6kBfipvozMzMo Cc: "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 02:47:39 -0000 PiBJIGJlbGlldmUgSSBhbSBzYXlpbmcgdGhhdCB3ZSBhbGwgaGF2ZSBub3QgdGhvdWdodCBhYm91 dCB0aGUgcHJveHkgdG9waWMNCj4gZW5vdWdoIHRvIG1ha2UgYSBjb25jbHVzaW9uIHRoYXQgY291 bGQgZ28gaW50byB0aGUgY2hhcnRlciBhbmQgZm9yIHRoYXQNCj4gcmVhc29uIEkgYW0gdHJ5aW5n IHRvIGVuY291cmFnZSB0aG9zZSB3aG8gaGF2ZSBleHBlcnRpc2UgaW4gdGhpcyBmaWVsZCB0byBt YWtlDQo+IGNvbnRyaWJ1dGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUuDQoNCisxLg0KDQpJIHBy b3Bvc2UgdGhhdCB3ZSBwb3N0cG9uZSB0aGUgcHJveHkgdG9waWMgdG8gdGhlIG5leHQgcGhhc2Uu IA0KDQpDdXJyZW50bHkgd2UgZG9uoa90IHJlbGF0ZWQgZHJhZnRzIGFuZCBJIGNhbid0IHNlZSBj bGVhciBkaXJlY3Rpb24gYWJvdXQgdGhpcyB0b3BpYy4NCg0KVGhhbmtzLA0KDQpLaW5kIFJlZ2Fy ZHMNCktlcGVuZw0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEFjZSBbbWFpbHRv OmFjZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEhhbm5lcyBUc2Nob2ZlbmlnDQo+ILeiy83Ksbzk OiAyMDE0xOoz1MIyNMjVIDg6MjINCj4gytW8/sjLOiBNaWNoYWVsIFJpY2hhcmRzb24NCj4gs63L zTogQWNlQGlldGYub3JnDQo+INb3zOI6IFJlOiBbQWNlXSBTdW1tYXJ5IG9mIHRoZSBQcm94eSBE aXNjdXNzaW9uDQo+IA0KPiBIaSBNaWNoYWVsLA0KPiANCj4gT24gMDMvMjQvMjAxNCAwMzowMCBB TSwgTWljaGFlbCBSaWNoYXJkc29uIHdyb3RlOg0KPiA+DQo+ID4gSGFubmVzIFRzY2hvZmVuaWcg PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPiA+ICAgICA+IGJhc2VkIG9uIHRo ZSBmZWVkYmFjayBhdCB0aGUgQk9GIHdlIGNvbmNsdWRlZCB0aGF0IHByb3hpZXMgc2hvdWxkDQo+ IGJlDQo+ID4gICAgID4gcGFydCBvZiB0aGUgV0cgaW52ZXN0aWdhdGlvbi4gV2hhdCB3YXNuJ3Qg Y2xlYXIgd2FzIHdoZW4gYW4NCj4gPiAgICAgPiBpbnZlc3RpZ2F0aW9uIHNob3VsZCBiZSBjb25k dWN0ZWQuDQo+ID4NCj4gPiBXaGVuIHlvdSBzYXkgcHJveGllcywgSSB0aGluayB5b3UgYXJlIHRh bGtpbmcgYWJvdXQgdGhpbmdzIHdoaWNoIHRoZQ0KPiA+IGVuZCBwb2ludHMgYXJlIGF3YXJlIG9m IChhbmQgbWF5IGhhdmUgdG8gdHJ1c3QpLiAgSXQgd291bGQgaW5jbHVkZSwNCj4gPiBidXQgbm90 IGJlIGxpbWl0ZWQgdG8sIENvQVAvSFRUUCB0cmFuc2xhdG9ycy4gKFdlbGwuIENvQVAtRFRMUy9I VFRQUyEpDQo+IA0KPiBEdXJpbmcgdGhlIGRpc2N1c3Npb25zIG9uIHRoZSBsaXN0IEkgaGFkIHRv IG5vdGljZWQgdGhhdCBmb2xrcyBoYWQgZGlmZmVyZW50IHVzZQ0KPiBjYXNlcyBpbiBtaW5kLiBP bmUgd2FzIGFib3V0IHByb3RvY29sIHRyYW5zbGF0aW9uIGJ1dCB0aGVyZSBhcmUgYWxzbyBjYXNl cw0KPiB0aGF0IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIHByb3RvY29sIHRyYW5zbGF0aW9uIGJ1 dCByYXRoZXIgd2l0aCB0aGUgdXNlIG9mDQo+IENvQVAgaXRzZWxmIGFuZCBob3cgc29tZSBzZWVt IHRvIGhhdmUgYXNzdW1lZCBob3cgaXQgd29ya3MuDQo+IA0KPiA+DQo+ID4gV291bGQgd2UgYWdy ZWUgdGhhdCB0aGUgcHJveGllcyBhcmUgbm90IHRyYW5zcGFyZW50Pw0KPiANCj4gVHJhbnNwYXJl bmN5IGlzIGEgZnV6enkgdGVybSBoZXJlLg0KPiANCj4gSXMgYSBwcm90b2NvbCB0cmFuc2xhdG9y IHRyYW5zcGFyZW50IG9mIG5vdCBhbmQgdGhlIHF1ZXN0aW9uIGlzIHRvIHdob20gaXMgaXQNCj4g dHJhbnNwYXJlbnQ/DQo+IA0KPiBJIGJlbGlldmUgSSBhbSBzYXlpbmcgdGhhdCB3ZSBhbGwgaGF2 ZSBub3QgdGhvdWdodCBhYm91dCB0aGUgcHJveHkgdG9waWMNCj4gZW5vdWdoIHRvIG1ha2UgYSBj b25jbHVzaW9uIHRoYXQgY291bGQgZ28gaW50byB0aGUgY2hhcnRlciBhbmQgZm9yIHRoYXQNCj4g cmVhc29uIEkgYW0gdHJ5aW5nIHRvIGVuY291cmFnZSB0aG9zZSB3aG8gaGF2ZSBleHBlcnRpc2Ug aW4gdGhpcyBmaWVsZCB0byBtYWtlDQo+IGNvbnRyaWJ1dGlvbnMgYXMgZWFybHkgYXMgcG9zc2li bGUuDQo+IA0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCj4gDQo+ID4NCj4gPiAtLQ0KPiA+IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQo+ID4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IEFjZSBtYWlsaW5nIGxpc3QNCj4gPiBBY2VAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiA+DQoNCg== From nobody Wed Mar 26 19:48:57 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF3F1A005A for ; Wed, 26 Mar 2014 19:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms8ZEdJFe1-Y for ; Wed, 26 Mar 2014 19:48:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D05CA1A004A for ; Wed, 26 Mar 2014 19:48:47 -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.7-GA FastPath queued) with ESMTP id BCL95607; Thu, 27 Mar 2014 02:48:45 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 02:48:09 +0000 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 02:48:44 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Thu, 27 Mar 2014 10:48:40 +0800 From: Likepeng To: "ace@ietf.org" Thread-Topic: ACE Charter Proposal v0.7 Thread-Index: Ac9JZw1fJW9TnG0KQGOhXKQRBIbbaA== Date: Thu, 27 Mar 2014 02:48:38 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0A1AF@SZXEMA501-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.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B0A1AFSZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/LKWAilSK8nQumGMYoX8H0rcR2IA Cc: Hannes Tschofenig Subject: [Ace] ACE Charter Proposal v0.7 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 02:48:55 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B0A1AFSZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Based on the recent discussions in the mailing list, Hannes and I have prov= ided the ACE charter proposal v0.7: http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# There is no change to the descriptive text. We mainly change the task list and add milestones. Do you think the charter is ready to go? Please indicate your opinion, whether you like it or not, and also your com= ments/suggestions. Thanks, Kind Regards Kepeng & Hannes Draft Charter V0.7 - Authentication and Authorization for Constrained Envir= onment (ACE) The IETF has recently developed protocols for use in environments where net= work nodes are limited in CPU, memory, and power. It was observed that Inte= rnet protocols can be applied to these constrained environments, often only= requiring minor tweaking and profiling. In other cases, new protocols have= been defined to address the specific requirements of constrained devices a= nd networks. An example of such a protocol is the Constrained Application P= rotocol (CoAP). As in other environments, authentication and authorization question also ar= ise in environments with constrained nodes and networks. For example, a doo= r lock has to authorize the person seeking access using a "digital key". Wh= ere are the authorization decisions stored? How does the digital key commun= icate with the lock? Does the lock interact with an authorization server to= obtain authorization information? How can access be granted to other perso= ns temporarily? How can access be revoked? These types of questions have be= en answered by existing protocols for use cases outside the constrained env= ironment. But in constrained environment, additional requirements pose chal= lenges for the use of various security protocols. In particular, the need f= or a dynamic and fine grained access control mechanism whereby clients and/= or resource servers suffer from constraints arises. The IETF has a long history in developing three party authentication and au= thorization protocols for distributed environments. Examples include Kerber= os, the Public Key Infrastructure (PKI), the Authentication, Authorization,= and Accounting (AAA) infrastructure, and the Web Authorization Protocol (O= Auth). All these protocols enjoy widespread deployment on the Internet. Alt= hough they all aim to solve a similar goal, at an abstract level, they offe= r quite different functions and utilize different message exchanges. These = differences are motivated by the main deployment use cases they were design= ed for. Requirements derived from use cases indicate the suitability of already exi= sting work, such as OAuth, as a solution for constrained environments. Thes= e protocols were, however, not optimized for constrained environments. Addi= tional requirements that need to be taken into account are the lack of a su= itable user-interface for obtaining the consent of the user and the inabili= ty of embedded devices to contact an authorization server in real-time with= every access request due to intermittent connectivity, etc. This working group therefore aims for a standardized solution for authentic= ation and authorization to enable authorized access to resources in constra= ined environments. As a starting point, the working group will assume that = access to resources offered by a resource server by a client devices takes = place using CoAP and is protected by DTLS. Both resource server and client = may be resource constraint. This access will be mediated by an authorizatio= n server, which does not suffer from the same resource limitations. Existing authentication and authorization protocols are used and re-applied= for use with constrained devices, where applicable. This requires relevant= specifications to be reviewed for suitability, selecting a subset of them,= restricting the options within each of the specifications. Some functional= ities may, however, not be available in existing protocols and for those ca= ses new functionality has to be standardized. Thus, existing work can be le= veraged and the group benefits from available security analysis, implementa= tion, and deployment experience. Moreover, a standardized solution for fede= rated authentication and authorization will help to stimulate the deploymen= t of IoT devices offering increased security. Once progress in identifying suitable candidate solutions has been made the= working group will verify whether the same mechanism are also applicable b= eyond the use of CoAP and DTLS, which are the two main protocols the group = will focus on for access to resources. In particular, the ability to use th= e developed solution over HTTP and TLS will be investigated. Furthermore, t= o guarantee smooth transition the integration with existing deployment will= be studied. This particularly concerns the use of protocol translation pro= xies. To be successful this working group requires expertise in security, privacy= , and a good understanding of usability in the constrained environment spac= e. This work does not make the assumption that the party offering applicati= on layer services is always the same party offering network access services= . The working group has the following tasks: 1) Use cases and requirements 2) Identification of authentication and authorization mechanisms suitable f= or resource access in constrained environments. Milestones: Jul 2014 Submit "Use cases and Requirements" as WG item. Dec 2014 Submit "Authentication and Authorization Solution" as WG item. Jul 2015 Submit "Use cases and Requirements" document to IESG for publicati= on as informational RFC. Jul 2016 Submit "Authentication and Authorization Solution" specification t= o IESG for publication as a Proposed Standard. --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B0A1AFSZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Based on the recent discussions= in the mailing list, Hannes and I have provided the ACE charter proposal v= 0.7:

http://tools.ietf.org/wg/core/trac/wiki/A= CE_charter#

 

There is no change to the descr= iptive text.

 

We mainly change the task list = and add milestones.

 

Do you think the charter is rea= dy to go?

 

Please indicate your opinion, w= hether you like it or not, and also your comments/suggestions.

 

Thanks,

 

Kind Regards<= /p>

Kepeng & Hannes<= /span>

 

Draf= t Charter V0.7 - Authentication and Authorization for Constrained Environme= nt (ACE)

The IETF has recently develop= ed protocols for use in environments where network nodes are limited in CPU= , memory, and power. It was observed that Internet protocols can be applied to these constrained environments, often only requiring min= or tweaking and profiling. In other cases, new protocols have been defined = to address the specific requirements of constrained devices and networks. A= n example of such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, aut= hentication and authorization question also arise in environments with cons= trained nodes and networks. For example, a door lock has to authorize the person seeking access using a "digital key". Wh= ere are the authorization decisions stored? How does the digital key commun= icate with the lock? Does the lock interact with an authorization server to= obtain authorization information? How can access be granted to other persons temporarily? How can access be revoked?= These types of questions have been answered by existing protocols for use = cases outside the constrained environment. But in constrained environment, = additional requirements pose challenges for the use of various security protocols. In particular, the need for a d= ynamic and fine grained access control mechanism whereby clients and/or res= ource servers suffer from constraints arises.

The IETF has a long history i= n developing three party authentication and authorization protocols for dis= tributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization, and Accountin= g (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All the= se protocols enjoy widespread deployment on the Internet. Although they all= aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize differ= ent message exchanges. These differences are motivated by the main deployme= nt use cases they were designed for.

Requirements derived from use= cases indicate the suitability of already existing work, such as OAuth, as= a solution for constrained environments. These protocols were, however, not optimized for constrained environments. Additional requ= irements that need to be taken into account are the lack of a suitable user= -interface for obtaining the consent of the user and the inability of embed= ded devices to contact an authorization server in real-time with every access request due to intermittent connecti= vity, etc.

This working group therefore = aims for a standardized solution for authentication and authorization to en= able authorized access to resources in constrained environments. As a starting point, the working group will assume that access to resource= s offered by a resource server by a client devices takes place using CoAP a= nd is protected by DTLS. Both resource server and client may be resource co= nstraint. This access will be mediated by an authorization server, which does not suffer from the same resource l= imitations.

Existing authentication and a= uthorization protocols are used and re-applied for use with constrained dev= ices, where applicable. This requires relevant specifications to be reviewed for suitability, selecting a subset of them, restricting th= e options within each of the specifications. Some functionalities may, howe= ver, not be available in existing protocols and for those cases new functio= nality has to be standardized. Thus, existing work can be leveraged and the group benefits from available secur= ity analysis, implementation, and deployment experience. Moreover, a standa= rdized solution for federated authentication and authorization will help to= stimulate the deployment of IoT devices offering increased security.

Once progress in identifying = suitable candidate solutions has been made the working group will verify wh= ether the same mechanism are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focu= s on for access to resources. In particular, the ability to use the develop= ed solution over HTTP and TLS will be investigated. Furthermore, to guarant= ee smooth transition the integration with existing deployment will be studied. This particularly concerns the u= se of protocol translation proxies.

To be successful this working= group requires expertise in security, privacy, and a good understanding of= usability in the constrained environment space. This work does not make the assumption that the party offering application layer ser= vices is always the same party offering network access services.

The = working group has the following tasks:

1) U= se cases and requirements

2) I= dentification of authentication and authorization mechanisms suitable for r= esource access in constrained environments.

Mile= stones:

Jul = 2014 Submit “Use cases and Requirements” as WG item.

Dec = 2014 Submit “Authentication and Authorization Solution” as WG i= tem.

Jul = 2015 Submit “Use cases and Requirements” document to IESG for p= ublication as informational RFC.

Jul = 2016 Submit “Authentication and Authorization Solution” specifi= cation to IESG for publication as a Proposed Standard.

 

 

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B0A1AFSZXEMA501MBSchi_-- From nobody Thu Mar 27 07:02:21 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A97D1A06F6 for ; Thu, 27 Mar 2014 07:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9VfuXVyQrC5 for ; Thu, 27 Mar 2014 07:02:10 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id CCC021A06F5 for ; Thu, 27 Mar 2014 07:02:08 -0700 (PDT) X-AuditID: c1b4fb31-b7f888e000000826-f5-53342f5ddd57 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id A5.3D.02086.D5F24335; Thu, 27 Mar 2014 15:02:06 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.80]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Thu, 27 Mar 2014 15:02:04 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Klaus Hartke , "Ace@ietf.org" Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyElZezb277v0yV5TaQjbw7iZrvavMA///keQCAAMpVgIAAOAQAgAAhv4CAACJhAIAA2T4AgABkt4CAAyiPgA== Date: Thu, 27 Mar 2014 14:02:04 +0000 Message-ID: References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+JvjW6cvkmwwZPJ3Bbfv/UwW2yb/IrJ gcljyZKfTB7TFmUGMEVx2aSk5mSWpRbp2yVwZcyarlkw367iw3fFBsbVRl2MnBwSAiYSD5/u Z4KwxSQu3FvPBmILCZxglPi6U6KLkQvIXswosaD3GiNIgk3AVeLAg3dgDSICDhKzjjwAs4UF jCR2Tupj7WLkAIobSzz6xQdRkiWx++4XZhCbRUBV4tbfTWDzeQXMJdY+bmSHmP+aSWLf5uMs IAlOgUCJ9lW9YDMZgQ76fmoNmM0sIC5x68l8qEMFJJbsOc8MYYtKvHz8jxXEFhXQk7j3aC4L RFxJYsX2S4wQvXoSN6ZOYYOwrSUebb4BFdeWWLbwNTPEQYISJ2c+YZnAKD4LybpZSNpnIWmf haR9FpL2BYysqxgli1OLk3LTjQz1ctNzS/RSizKTi4vz8/SKUzcxAiPu4JbfhjsYJ16zP8Qo zcGiJM7LML0zSEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjwJ2m9UyxMrstL8jfCZ/qeXWa fMJPswcuWgVS4dOLHymkZBQ+3R2mu4wxdD/vqrdPnF/sT+5c8aHj9J4dE89V77glL733e9HN skXz3nvpeL4pvnBLL5bnmvr3sEdv1bY92PR10lVlv+yTlyWWBs06b+fsfGbDwoxHmlc22XPp 7rvf0OQbyGB6S4mlOCPRUIu5qDgRAKWyYNKGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Rb1q-_7on-xG8yP-2Af6SiTeLXw Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:02:15 -0000 Hi Klaus Thanks for these explicit examples. I believe example 3 - the forward proxy - is different from the others with respect to end-to-end security between client and requested resource. I think that has an impact on the solution so we should explicitly consider these examples in the work. See comments inline. =20 On 25/03/14 15:48, "Klaus Hartke" wrote: >Hi Hannes, > >here are a few examples. In each example, the client wants to obtain a >representation of {coaps,https}://example.org/path/to/resource. All >examples work for both CoAP and HTTP, except for the last which only >works for HTTP. > >Example 1: Client---Origin Server[example.org] > >1. The client resolves and establishes a secure connection to example.org >2. The client requests a representation of the resource > /path/to/resource by sending a GET request message >3. The origin server satisfies the request by serving a local file to the >client The resource host (origin server) and the client mutually authenticates and protect the request/response using the secure connection. > >Example 2: Client---Reverse Proxy[example.org]---Origin >Server[example.net] > >1. The client resolves and establishes a secure connection to example.org >2. The client requests a representation of the resource /path/to/resource >3. The reverse proxy chooses to satisfy the request by obtaining the > representation of {coaps,https}://example.net/some/other/resource > a. The reverse proxy resolves and establishes a secure connection > to example.net > b. The reverse proxy requests a representation of the resource > /some/other/resource > c. The origin server satisfies the request by serving a local file > to the reverse proxy >4. The reverse proxies serves the representation to the client In this case, the requested resource, from the point of view of the client, is hosted by the reverse proxy, between which there can be mutual authentication and secure connection. Where the reverse proxy gets a representation from is out of scope of the client. > >Example 3: Client---Forward Proxy[proxy.example]---Origin >Server[example.org] > >1. The client resolves and establishes a secure connection to >proxy.example >2. The client requests a representation of the resource > {coaps,https}://example.org/path/to/resource >3. The forward proxy satisfies the request by obtaining the > representation of {coaps,https}://example.org/path/to/resource > a. The forward proxy resolves and establishes a secure connection > to example.org > b. The forward proxy requests a representation of the resource > /path/to/resource > c. The origin server satisfies the request by serving a local file > to the forward proxy >4. The forward proxy serves the representation to the client In this case, the forward proxy and client mutually authenticates and establish secure connection, as does forward proxy and resource host (origin server). With the mechanisms described in this example, the resource host does not authenticate the client, so some additional security is needed for the origin server to enforce an access control decision or evaluate an access control policy which is bound to a particular client (or role of client). There are of course solutions to this problem, but the important thing at this stage is that forward proxies has an impact on the solution. If we want to support forward proxies, eventually, then we should not postpone this to a later phase, because there is a good chance that will require a completely different solution. I therefore propose that we include support for the mentioned proxies in the assumptions. > >Example 4: Client---Tunnel[tunnel.example]---Origin Server[example.org] > >1. The client resolves and establishes an unsecured connection to >tunnel.example >2. The client requests the tunnel to establish an unsecured connection > to example.org and to act as a blind relay between the two connections >3. The tunnel satisfies the request by resolving and establishing an > unsecured connection to example.org >4. The client establishes a secure connection to the origin server > through the tunnel >5. The client requests a representation of the resource /path/to/resource >6. The origin server satisfies the request by serving a local file to the >client In this case client and resource host mutually authenticates and establishes the end-to-end secure connection in step 4. Similar to examples 1 and 2. G=F6ran > >Does that answer your questions? > >Klaus > > >On 25 March 2014 09:47, Hannes Tschofenig >wrote: >> Hi Klaus, >> >> thanks for the description. Since I am not sure I understood it >> correctly I have a couple of basic questions. >> >> On 03/24/2014 08:50 PM, Klaus Hartke wrote: >>> CoAP provides two (syntactically different) ways for a client (or >>> intermediary in the role of a client) to perform a request: >>> (I'm using representation retrieval as example WOLOG.) >>> >>> A.) the client requests a remote endpoint to return a representation >>> of a resource located _in that endpoint's namespace_. >>> >>> B.) the client requests a remote endpoint to return a representation >>> of a resource located _in another endpoint's namespace_. >> >> The client device will start with a specific FQDN and will start a DTLS >> handshake with that server. Where does the "requests a remote endpoint >> to return ...." come into the play? >> >> >> >>> >>> In both cases, it's generally up to the remote endpoint how it obtains >>> the representation of the target resource, as long as the result *is* >>> a representation of the target resource. >>> For example, in A., the remote endpoint can serve a local file (the >>> endpoint is then typically called a "server"), return the output of a >>> CGI script ("CGI gateway"), obtain the representation from an HTTP >>> server ("cross-protocol proxy"), or obtain the representation from >>> another CoAP remote endpoint ("reverse proxy"). In B., the remote >>> endpoint is generally expected to obtain the representation by >>> requesting it from the endpoint specified in the request URI ("forward >>> proxy"). >>> >>> In both cases, the client has no way to verify that the obtained >>> result is indeed a representation of the target resource. It must >>> trust the remote endpoint that it returns the correct representation. >>> DTLS just secures the transmission of the representation from the >>> remote endpoint to the client. >>> >>> (AFAIK, HTTP works exactly the same way.) >> >> In the HTTPS case the story is as follows: >> >> * The client contacts the server behind a https://www.ietf.org (after >> doing a DNS look-up) using TLS. >> >> * It gets the cert from the server. >> >> * The client compares the content of the cert with what it had initially >> requested to ensure it talks to the right server. >> >> The TLS will prevent any proxy along the path to cache the data (since >> it is encrypted). >> >> So, I am not sure how this compares to CoAP based on your description. >> >> Ciao >> Hannes >> >> >>> >>> So, I would say that >>> >>> - ACE should consider forward proxies, reverse proxies and potentially >>> cross-protocol proxies such that one of these can obtain a >>> representation of a resource that a client is authorized to access on >>> behalf of that client; and >>> >>> - ACE should not consider remote endpoints that cannot be trusted to >>> correctly return a representation of a target resource (as this >>> concerns the general security of CoAP which should be addressed in >>> CoRE). >>> >>> Klaus > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Thu Mar 27 09:01:16 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F109E1A067E for ; Thu, 27 Mar 2014 09:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reJuHNZ_-bSE for ; Thu, 27 Mar 2014 09:01:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5BB1A0186 for ; Thu, 27 Mar 2014 09:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2RG19jN018563 for ; Thu, 27 Mar 2014 17:01:09 +0100 (CET) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B0B8C4BE for ; Thu, 27 Mar 2014 17:01:09 +0100 (CET) Received: by mail-vc0-f177.google.com with SMTP id if17so4406821vcb.36 for ; Thu, 27 Mar 2014 09:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=2/Ehguk27BFCftLL8Nav187dDmssp7ilYztu6V1Mm1c=; b=Ku0l9JyPpJevw5kekLKDAhAt/D+cyl8/4bT466aq0qrzgZVylEp6Ljxx783OMI8NkJ arZktFdXDqjTsVRbi68gMtlp5y4AI0Qt+rZ4GI2/tNiQjR4qQbFEixP23vQn2RqgQfSV QERmm9BvlspdGUI0VWlWZWUXdH0fJnw9WsHeVCs8q3ivWJ6MvJKuO8UKpnG67BKnrco7 GyASn/qFH3l5kIHzEDhVoec9BG6+/+IzA+GKqjeMGYi4/BLflLcXVdtRC5Gj5xMyl+o6 UpEnO5chBhSS27C6v+6vkMfwrzqhViK5DIuAoHg37dIkVrd8OhuXFJ0N5vjeK1XN1m4j GxXQ== X-Received: by 10.58.185.145 with SMTP id fc17mr2174130vec.14.1395936068468; Thu, 27 Mar 2014 09:01:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.242 with HTTP; Thu, 27 Mar 2014 09:00:28 -0700 (PDT) In-Reply-To: References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> From: Klaus Hartke Date: Thu, 27 Mar 2014 17:00:28 +0100 Message-ID: To: "Ace@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ace/FhaqKxYdEqAPlQ6U4FgzyM2tsQQ Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:01:16 -0000 G=F6ran Selander wrote: >>Example 1: Client---Origin Server[example.org] >> >>1. The client resolves and establishes a secure connection to example.org >>2. The client requests a representation of the resource >> /path/to/resource by sending a GET request message >>3. The origin server satisfies the request by serving a local file to the >>client > > The resource host (origin server) and the client mutually authenticates > and protect the request/response using the secure connection. And this is probably the most basic solution to authorized resource access: The origin server can determine for each request if the authenticated client is authorized to perform the requested action on the target resource or not. The important thing to note here is that the origin server is actually performing three tasks: (1.) authenticating of the client, (2.) having knowledge of which actions the _authenticated_ client is authorized to perform on which resources, and (3.) performing the action requested by an _authorized_ client on a resourc= e. If the origin server is too constrained to perform all these tasks, the idea is to off-load some of them (1. and 2.) to a less constrained third party. Then there must be a standard way for the client to (A.) securely discover the third party, (B.) perform steps to first become an authenticated client and then an authorized client, and finally (C.) to make a request as an authorized (but not necessarily authenticated) client. >>Example 2: Client---Reverse Proxy[example.org]---Origin >>Server[example.net] >> >>1. The client resolves and establishes a secure connection to example.org >>2. The client requests a representation of the resource /path/to/resource >>3. The reverse proxy chooses to satisfy the request by obtaining the >> representation of {coaps,https}://example.net/some/other/resource >> a. The reverse proxy resolves and establishes a secure connection >> to example.net >> b. The reverse proxy requests a representation of the resource >> /some/other/resource >> c. The origin server satisfies the request by serving a local file >> to the reverse proxy >>4. The reverse proxies serves the representation to the client > > In this case, the requested resource, from the point of view of the > client, is hosted by the reverse proxy, between which there can be mutual > authentication and secure connection. Where the reverse proxy gets a > representation from is out of scope of the client. It may be the origin server [example.net], though, which has the knowledge of which actions the client (which authenticated to the reverse proxy [example.org]) is authorized to perform on which resources. The reverse proxy could merely act as a simple cache in front of the origin server. So there must be (D.) a standard way for the reverse proxy to make requests to the origin server on behalf of an authorized client. >>Example 3: Client---Forward Proxy[proxy.example]---Origin >>Server[example.org] >> >>1. The client resolves and establishes a secure connection to >>proxy.example >>2. The client requests a representation of the resource >> {coaps,https}://example.org/path/to/resource >>3. The forward proxy satisfies the request by obtaining the >> representation of {coaps,https}://example.org/path/to/resource >> a. The forward proxy resolves and establishes a secure connection >> to example.org >> b. The forward proxy requests a representation of the resource >> /path/to/resource >> c. The origin server satisfies the request by serving a local file >> to the forward proxy >>4. The forward proxy serves the representation to the client > > In this case, the forward proxy and client mutually authenticates and > establish secure connection, as does forward proxy and resource host > (origin server). It is noteworthy here that the client can only request the forward proxy to make its request to the origin server securely (by specifying the "coaps" scheme). It has no influence on acceptable cipher suits, certificate roots, etc. The client has to trust the forward proxy that it secures the connection to the origin server in a way that is acceptable to the client. > With the mechanisms described in this example, the > resource host does not authenticate the client, so some additional > security is needed for the origin server to enforce an access control > decision or evaluate an access control policy which is bound to a > particular client (or role of client). So there must be (E.) a standard way for the forward proxy to make requests to the origin server on behalf of an authorized client. Klaus From nobody Thu Mar 27 23:52:52 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C301A07F6 for ; Thu, 27 Mar 2014 23:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5yHd6i4sX1I for ; Thu, 27 Mar 2014 23:52:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 101581A0208 for ; Thu, 27 Mar 2014 23:52:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCM79076; Fri, 28 Mar 2014 06:52:44 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 06:52:12 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 06:52:41 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Fri, 28 Mar 2014 14:52:36 +0800 From: Likepeng To: Klaus Hartke , "Ace@ietf.org" Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyGaZCy7gapW0iSUYgVT5QsOJru9ZoA///keQCAAMpVgIAAOAQAgAAhv4CAACJhAIAA2T4AgABkuICAAxfMAIAAIRQAgAF8wTA= Date: Fri, 28 Mar 2014 06:52:36 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B017@SZXEMA501-MBS.china.huawei.com> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/YNpSJfBD4cZYoP7h2ttDz4yjC6k Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 06:52:51 -0000 PiBUaGVuIHRoZXJlIG11c3QgYmUgYSBzdGFuZGFyZCB3YXkgZm9yIHRoZSBjbGllbnQgdG8NCj4o QS4pIHNlY3VyZWx5IGRpc2NvdmVyIHRoZSB0aGlyZCBwYXJ0eSwgDQo+KEIuKSBwZXJmb3JtIHN0 ZXBzIHRvIGZpcnN0IGJlY29tZSBhbiBhdXRoZW50aWNhdGVkIGNsaWVudCBhbmQgdGhlbiBhbiBh dXRob3JpemVkIGNsaWVudCwgDQo+KEMuKSB0byBtYWtlIGEgcmVxdWVzdCBhcyBhbiBhdXRob3Jp emVkIChidXQgbm90IG5lY2Vzc2FyaWx5IGF1dGhlbnRpY2F0ZWQpIGNsaWVudC4NCg0KVGhlc2Ug dGhyZWUgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSBhbHJlYWR5IHRoZXJlLCBldmVuIHdpdGhvdXQg cHJveHkuDQoNCj4gU28gdGhlcmUgbXVzdCBiZSAoRC4pIGEgc3RhbmRhcmQgd2F5IGZvciB0aGUg cmV2ZXJzZSBwcm94eSB0byBtYWtlIHJlcXVlc3RzIHRvIHRoZSBvcmlnaW4gc2VydmVyIG9uIGJl aGFsZiBvZiBhbiBhdXRob3JpemVkIGNsaWVudC4NCj4gU28gdGhlcmUgbXVzdCBiZSAoRS4pIGEg c3RhbmRhcmQgd2F5IGZvciB0aGUgZm9yd2FyZCBwcm94eSB0byBtYWtlIHJlcXVlc3RzIHRvIHRo ZSBvcmlnaW4gc2VydmVyIG9uIGJlaGFsZiBvZiBhbiBhdXRob3JpemVkIGNsaWVudC4NCg0KSW4g bXkgdW5kZXJzdGFuZGluZywgdGhlc2UgdHdvIHJlcXVpcmVtZW50cyBzaG91bGQgbm90IGltcGFj dCBvdXIgYmFzaWMgc29sdXRpb24gKG5vIHByb3h5IGludm9sdmVkKS4gDQoNCldlIGNhbiBkZWZp bmUgb3VyIGJhc2ljIHNvbHV0aW9uIChubyBwcm94eSBpbnZvbHZlZCkgaW4gdGhlIGZpcnN0IHN0 YWdlLCBhbmQgZGVmaW5lIGV4dGVuZGVkIHNvbHV0aW9uICh3aXRoIHByb3h5IGludm9sdmVkKSBp biB0aGUgc2Vjb25kIHN0YWdlLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQo+IC0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIEtsYXVzIEhhcnRrZQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTTlubQz5pyIMjjm l6UgMDowMA0KPiDmlLbku7bkuro6IEFjZUBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbQWNlXSBT dW1tYXJ5IG9mIHRoZSBQcm94eSBEaXNjdXNzaW9uDQo+IA0KPiBHw7ZyYW4gU2VsYW5kZXIgd3Jv dGU6DQo+ID4+RXhhbXBsZSAxOiBDbGllbnQtLS1PcmlnaW4gU2VydmVyW2V4YW1wbGUub3JnXQ0K PiA+Pg0KPiA+PjEuIFRoZSBjbGllbnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJl IGNvbm5lY3Rpb24gdG8NCj4gPj5leGFtcGxlLm9yZyAyLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEg cmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlDQo+ID4+ICAgIC9wYXRoL3RvL3Jlc291cmNl IGJ5IHNlbmRpbmcgYSBHRVQgcmVxdWVzdCBtZXNzYWdlIDMuIFRoZSBvcmlnaW4NCj4gPj5zZXJ2 ZXIgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlIHRvIHRoZSBj bGllbnQNCj4gPg0KPiA+IFRoZSByZXNvdXJjZSBob3N0IChvcmlnaW4gc2VydmVyKSBhbmQgdGhl IGNsaWVudCBtdXR1YWxseQ0KPiA+IGF1dGhlbnRpY2F0ZXMgYW5kIHByb3RlY3QgdGhlIHJlcXVl c3QvcmVzcG9uc2UgdXNpbmcgdGhlIHNlY3VyZQ0KPiBjb25uZWN0aW9uLg0KPiANCj4gQW5kIHRo aXMgaXMgcHJvYmFibHkgdGhlIG1vc3QgYmFzaWMgc29sdXRpb24gdG8gYXV0aG9yaXplZCByZXNv dXJjZQ0KPiBhY2Nlc3M6IFRoZSBvcmlnaW4gc2VydmVyIGNhbiBkZXRlcm1pbmUgZm9yIGVhY2gg cmVxdWVzdCBpZiB0aGUgYXV0aGVudGljYXRlZA0KPiBjbGllbnQgaXMgYXV0aG9yaXplZCB0byBw ZXJmb3JtIHRoZSByZXF1ZXN0ZWQgYWN0aW9uIG9uIHRoZSB0YXJnZXQgcmVzb3VyY2Ugb3INCj4g bm90Lg0KPiANCj4gVGhlIGltcG9ydGFudCB0aGluZyB0byBub3RlIGhlcmUgaXMgdGhhdCB0aGUg b3JpZ2luIHNlcnZlciBpcyBhY3R1YWxseQ0KPiBwZXJmb3JtaW5nIHRocmVlIHRhc2tzOg0KPiAN Cj4gKDEuKSBhdXRoZW50aWNhdGluZyBvZiB0aGUgY2xpZW50LA0KPiAoMi4pIGhhdmluZyBrbm93 bGVkZ2Ugb2Ygd2hpY2ggYWN0aW9ucyB0aGUgX2F1dGhlbnRpY2F0ZWRfIGNsaWVudCBpcw0KPiBh dXRob3JpemVkIHRvIHBlcmZvcm0gb24gd2hpY2ggcmVzb3VyY2VzLCBhbmQNCj4gKDMuKSBwZXJm b3JtaW5nIHRoZSBhY3Rpb24gcmVxdWVzdGVkIGJ5IGFuIF9hdXRob3JpemVkXyBjbGllbnQgb24g YSByZXNvdXJjZS4NCj4gDQo+IElmIHRoZSBvcmlnaW4gc2VydmVyIGlzIHRvbyBjb25zdHJhaW5l ZCB0byBwZXJmb3JtIGFsbCB0aGVzZSB0YXNrcywgdGhlIGlkZWEgaXMgdG8NCj4gb2ZmLWxvYWQg c29tZSBvZiB0aGVtICgxLiBhbmQgMi4pIHRvIGEgbGVzcyBjb25zdHJhaW5lZCB0aGlyZCBwYXJ0 eS4NCj4gDQo+IFRoZW4gdGhlcmUgbXVzdCBiZSBhIHN0YW5kYXJkIHdheSBmb3IgdGhlIGNsaWVu dCB0byAoQS4pIHNlY3VyZWx5IGRpc2NvdmVyIHRoZQ0KPiB0aGlyZCBwYXJ0eSwgKEIuKSBwZXJm b3JtIHN0ZXBzIHRvIGZpcnN0IGJlY29tZSBhbiBhdXRoZW50aWNhdGVkIGNsaWVudCBhbmQNCj4g dGhlbiBhbiBhdXRob3JpemVkIGNsaWVudCwgYW5kIGZpbmFsbHkgKEMuKSB0byBtYWtlIGEgcmVx dWVzdCBhcyBhbiBhdXRob3JpemVkDQo+IChidXQgbm90IG5lY2Vzc2FyaWx5IGF1dGhlbnRpY2F0 ZWQpIGNsaWVudC4NCj4gDQo+ID4+RXhhbXBsZSAyOiBDbGllbnQtLS1SZXZlcnNlIFByb3h5W2V4 YW1wbGUub3JnXS0tLU9yaWdpbg0KPiA+PlNlcnZlcltleGFtcGxlLm5ldF0NCj4gPj4NCj4gPj4x LiBUaGUgY2xpZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25uZWN0aW9u IHRvDQo+ID4+ZXhhbXBsZS5vcmcgMi4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlcHJlc2VudGF0 aW9uIG9mIHRoZSByZXNvdXJjZQ0KPiA+Pi9wYXRoL3RvL3Jlc291cmNlIDMuIFRoZSByZXZlcnNl IHByb3h5IGNob29zZXMgdG8gc2F0aXNmeSB0aGUgcmVxdWVzdCBieQ0KPiBvYnRhaW5pbmcgdGhl DQo+ID4+ICAgIHJlcHJlc2VudGF0aW9uIG9mIHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm5ldC9z b21lL290aGVyL3Jlc291cmNlDQo+ID4+ICAgIGEuIFRoZSByZXZlcnNlIHByb3h5IHJlc29sdmVz IGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25uZWN0aW9uDQo+ID4+ICAgICAgICB0byBleGFt cGxlLm5ldA0KPiA+PiAgICBiLiBUaGUgcmV2ZXJzZSBwcm94eSByZXF1ZXN0cyBhIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSByZXNvdXJjZQ0KPiA+PiAgICAgICAgL3NvbWUvb3RoZXIvcmVzb3VyY2UN Cj4gPj4gICAgYy4gVGhlIG9yaWdpbiBzZXJ2ZXIgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNl cnZpbmcgYSBsb2NhbCBmaWxlDQo+ID4+ICAgICAgICB0byB0aGUgcmV2ZXJzZSBwcm94eQ0KPiA+ PjQuIFRoZSByZXZlcnNlIHByb3hpZXMgc2VydmVzIHRoZSByZXByZXNlbnRhdGlvbiB0byB0aGUg Y2xpZW50DQo+ID4NCj4gPiBJbiB0aGlzIGNhc2UsIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UsIGZy b20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlDQo+ID4gY2xpZW50LCBpcyBob3N0ZWQgYnkgdGhl IHJldmVyc2UgcHJveHksIGJldHdlZW4gd2hpY2ggdGhlcmUgY2FuIGJlDQo+ID4gbXV0dWFsIGF1 dGhlbnRpY2F0aW9uIGFuZCBzZWN1cmUgY29ubmVjdGlvbi4gV2hlcmUgdGhlIHJldmVyc2UgcHJv eHkNCj4gPiBnZXRzIGEgcmVwcmVzZW50YXRpb24gZnJvbSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhl IGNsaWVudC4NCj4gDQo+IEl0IG1heSBiZSB0aGUgb3JpZ2luIHNlcnZlciBbZXhhbXBsZS5uZXRd LCB0aG91Z2gsIHdoaWNoIGhhcyB0aGUga25vd2xlZGdlIG9mDQo+IHdoaWNoIGFjdGlvbnMgdGhl IGNsaWVudCAod2hpY2ggYXV0aGVudGljYXRlZCB0byB0aGUgcmV2ZXJzZSBwcm94eQ0KPiBbZXhh bXBsZS5vcmddKSBpcyBhdXRob3JpemVkIHRvIHBlcmZvcm0gb24gd2hpY2ggcmVzb3VyY2VzLiBU aGUgcmV2ZXJzZSBwcm94eQ0KPiBjb3VsZCBtZXJlbHkgYWN0IGFzIGEgc2ltcGxlIGNhY2hlIGlu IGZyb250IG9mIHRoZSBvcmlnaW4gc2VydmVyLg0KPiANCj4gU28gdGhlcmUgbXVzdCBiZSAoRC4p IGEgc3RhbmRhcmQgd2F5IGZvciB0aGUgcmV2ZXJzZSBwcm94eSB0byBtYWtlIHJlcXVlc3RzIHRv DQo+IHRoZSBvcmlnaW4gc2VydmVyIG9uIGJlaGFsZiBvZiBhbiBhdXRob3JpemVkIGNsaWVudC4N Cj4gDQo+ID4+RXhhbXBsZSAzOiBDbGllbnQtLS1Gb3J3YXJkIFByb3h5W3Byb3h5LmV4YW1wbGVd LS0tT3JpZ2luDQo+ID4+U2VydmVyW2V4YW1wbGUub3JnXQ0KPiA+Pg0KPiA+PjEuIFRoZSBjbGll bnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24gdG8NCj4gPj5w cm94eS5leGFtcGxlIDIuIFRoZSBjbGllbnQgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0 aGUgcmVzb3VyY2UNCj4gPj4gICAge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUub3JnL3BhdGgvdG8v cmVzb3VyY2UNCj4gPj4zLiBUaGUgZm9yd2FyZCBwcm94eSBzYXRpc2ZpZXMgdGhlIHJlcXVlc3Qg Ynkgb2J0YWluaW5nIHRoZQ0KPiA+PiAgICByZXByZXNlbnRhdGlvbiBvZiB7Y29hcHMsaHR0cHN9 Oi8vZXhhbXBsZS5vcmcvcGF0aC90by9yZXNvdXJjZQ0KPiA+PiAgICBhLiBUaGUgZm9yd2FyZCBw cm94eSByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbg0KPiA+PiAg ICAgICAgdG8gZXhhbXBsZS5vcmcNCj4gPj4gICAgYi4gVGhlIGZvcndhcmQgcHJveHkgcmVxdWVz dHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzb3VyY2UNCj4gPj4gICAgICAgIC9wYXRoL3Rv L3Jlc291cmNlDQo+ID4+ICAgIGMuIFRoZSBvcmlnaW4gc2VydmVyIHNhdGlzZmllcyB0aGUgcmVx dWVzdCBieSBzZXJ2aW5nIGEgbG9jYWwgZmlsZQ0KPiA+PiAgICAgICAgdG8gdGhlIGZvcndhcmQg cHJveHkNCj4gPj40LiBUaGUgZm9yd2FyZCBwcm94eSBzZXJ2ZXMgdGhlIHJlcHJlc2VudGF0aW9u IHRvIHRoZSBjbGllbnQNCj4gPg0KPiA+IEluIHRoaXMgY2FzZSwgdGhlIGZvcndhcmQgcHJveHkg YW5kIGNsaWVudCBtdXR1YWxseSBhdXRoZW50aWNhdGVzIGFuZA0KPiA+IGVzdGFibGlzaCBzZWN1 cmUgY29ubmVjdGlvbiwgYXMgZG9lcyBmb3J3YXJkIHByb3h5IGFuZCByZXNvdXJjZSBob3N0DQo+ ID4gKG9yaWdpbiBzZXJ2ZXIpLg0KPiANCj4gSXQgaXMgbm90ZXdvcnRoeSBoZXJlIHRoYXQgdGhl IGNsaWVudCBjYW4gb25seSByZXF1ZXN0IHRoZSBmb3J3YXJkIHByb3h5IHRvDQo+IG1ha2UgaXRz IHJlcXVlc3QgdG8gdGhlIG9yaWdpbiBzZXJ2ZXIgc2VjdXJlbHkgKGJ5IHNwZWNpZnlpbmcgdGhl ICJjb2FwcyINCj4gc2NoZW1lKS4gSXQgaGFzIG5vIGluZmx1ZW5jZSBvbiBhY2NlcHRhYmxlIGNp cGhlciBzdWl0cywgY2VydGlmaWNhdGUgcm9vdHMsIGV0Yy4NCj4gVGhlIGNsaWVudCBoYXMgdG8g dHJ1c3QgdGhlIGZvcndhcmQgcHJveHkgdGhhdCBpdCBzZWN1cmVzIHRoZSBjb25uZWN0aW9uIHRv IHRoZQ0KPiBvcmlnaW4gc2VydmVyIGluIGEgd2F5IHRoYXQgaXMgYWNjZXB0YWJsZSB0byB0aGUg Y2xpZW50Lg0KPiANCj4gPiBXaXRoIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGlzIGV4 YW1wbGUsIHRoZSByZXNvdXJjZSBob3N0IGRvZXMNCj4gPiBub3QgYXV0aGVudGljYXRlIHRoZSBj bGllbnQsIHNvIHNvbWUgYWRkaXRpb25hbCBzZWN1cml0eSBpcyBuZWVkZWQgZm9yDQo+ID4gdGhl IG9yaWdpbiBzZXJ2ZXIgdG8gZW5mb3JjZSBhbiBhY2Nlc3MgY29udHJvbCBkZWNpc2lvbiBvciBl dmFsdWF0ZSBhbg0KPiA+IGFjY2VzcyBjb250cm9sIHBvbGljeSB3aGljaCBpcyBib3VuZCB0byBh IHBhcnRpY3VsYXIgY2xpZW50IChvciByb2xlDQo+ID4gb2YgY2xpZW50KS4NCj4gDQo+IFNvIHRo ZXJlIG11c3QgYmUgKEUuKSBhIHN0YW5kYXJkIHdheSBmb3IgdGhlIGZvcndhcmQgcHJveHkgdG8g bWFrZSByZXF1ZXN0cw0KPiB0byB0aGUgb3JpZ2luIHNlcnZlciBvbiBiZWhhbGYgb2YgYW4gYXV0 aG9yaXplZCBjbGllbnQuDQo+IA0KPiBLbGF1cw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQWNlIG1haWxpbmcgbGlzdA0KPiBBY2VAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== From nobody Fri Mar 28 00:30:10 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC15A1A01DD for ; Fri, 28 Mar 2014 00:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKykDux8qs9w for ; Fri, 28 Mar 2014 00:30:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9551A0120 for ; Fri, 28 Mar 2014 00:30:05 -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.7-GA FastPath queued) with ESMTP id BCM81734; Fri, 28 Mar 2014 07:30:01 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 07:28:54 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 07:29:32 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Fri, 28 Mar 2014 15:29:28 +0800 From: Likepeng To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Klaus Hartke" , "Ace@ietf.org" Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyGaZCy7gapW0iSUYgVT5QsOJru9ZoA///keQCAAMpVgIAAOAQAgAAhv4CAACJhAIAA2T4AgABkuICAAxfMAIABnVig Date: Fri, 28 Mar 2014 07:29:27 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B049@SZXEMA501-MBS.china.huawei.com> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3SrgvtmzQL0k1RUDhLNAkYg5qr4 Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 07:30:10 -0000 PiBUaGVyZSBhcmUgb2YgY291cnNlIHNvbHV0aW9ucyB0byB0aGlzIHByb2JsZW0sIGJ1dCB0aGUg aW1wb3J0YW50IHRoaW5nIGF0IHRoaXMNCj4gc3RhZ2UgaXMgdGhhdCBmb3J3YXJkIHByb3hpZXMg aGFzIGFuIGltcGFjdCBvbiB0aGUgc29sdXRpb24uIElmIHdlIHdhbnQgdG8NCj4gc3VwcG9ydCBm b3J3YXJkIHByb3hpZXMsIGV2ZW50dWFsbHksIHRoZW4gd2Ugc2hvdWxkIG5vdCBwb3N0cG9uZSB0 aGlzIHRvIGENCj4gbGF0ZXIgcGhhc2UsIGJlY2F1c2UgdGhlcmUgaXMgYSBnb29kIGNoYW5jZSB0 aGF0IHdpbGwgcmVxdWlyZSBhIGNvbXBsZXRlbHkNCj4gZGlmZmVyZW50IHNvbHV0aW9uLiBJIHRo ZXJlZm9yZSBwcm9wb3NlIHRoYXQgd2UgaW5jbHVkZSBzdXBwb3J0IGZvciB0aGUNCj4gbWVudGlv bmVkIHByb3hpZXMgaW4gdGhlIGFzc3VtcHRpb25zLg0KDQpJIGFncmVlIHRoYXQgd2Ugc2hvdWxk IGNvbnNpZGVyIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBwcm94eSBzdXBwb3J0IHdoZW4gd2Ug ZGVzaWduIG91ciBzb2x1dGlvbi4gDQoNCkJ1dCBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBkZXNp Z24gb3VyIHNvbHV0aW9uIHN0ZXAgYnkgc3RlcCwgaW4gZGlmZmVyZW50IHBoYXNlcy4NCg0KTXkg d29ycnkgaXMsIHByb3h5IGlzIHF1aXRlIGNvbXBsZXggdG8gc3VwcG9ydCwgdGhpcyBtYXkgZGVs YXkgb3VyIHByb2dyZXNzIHRvIGZpbmlzaCBvdXIgYmFzaWMgc29sdXRpb24uDQoNCkFsc28gd2Ug ZG9u4oCZdCBoYXZlIGRyYWZ0cyBhdmFpbGFibGUgeWV0LCBJIGFtIG5vdCBzdXJlIHdobyBjYW4g bGVhZCB0aGlzIHdvcmssIGFuZCBob3cgbG9uZyBpdCB3aWxsIHRha2UuDQoNCktpbmQgUmVnYXJk cw0KS2VwZW5nDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IEFjZSBb bWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggRz9yYW4gU2VsYW5kZXINCj4g5Y+R 6YCB5pe26Ze0OiAyMDE05bm0M+aciDI35pelIDIyOjAyDQo+IOaUtuS7tuS6ujogS2xhdXMgSGFy dGtlOyBBY2VAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW0FjZV0gU3VtbWFyeSBvZiB0aGUgUHJv eHkgRGlzY3Vzc2lvbg0KPiANCj4gSGkgS2xhdXMNCj4gDQo+IFRoYW5rcyBmb3IgdGhlc2UgZXhw bGljaXQgZXhhbXBsZXMuIEkgYmVsaWV2ZSBleGFtcGxlIDMgLSB0aGUgZm9yd2FyZCBwcm94eSAt IGlzDQo+IGRpZmZlcmVudCBmcm9tIHRoZSBvdGhlcnMgd2l0aCByZXNwZWN0IHRvIGVuZC10by1l bmQgc2VjdXJpdHkgYmV0d2VlbiBjbGllbnQNCj4gYW5kIHJlcXVlc3RlZCByZXNvdXJjZS4gSSB0 aGluayB0aGF0IGhhcyBhbiBpbXBhY3Qgb24gdGhlIHNvbHV0aW9uIHNvIHdlDQo+IHNob3VsZCBl eHBsaWNpdGx5IGNvbnNpZGVyIHRoZXNlIGV4YW1wbGVzIGluIHRoZSB3b3JrLiBTZWUgY29tbWVu dHMgaW5saW5lLg0KPiANCj4gDQo+IE9uIDI1LzAzLzE0IDE1OjQ4LCAiS2xhdXMgSGFydGtlIiA8 aGFydGtlQHR6aS5vcmc+IHdyb3RlOg0KPiANCj4gPkhpIEhhbm5lcywNCj4gPg0KPiA+aGVyZSBh cmUgYSBmZXcgZXhhbXBsZXMuIEluIGVhY2ggZXhhbXBsZSwgdGhlIGNsaWVudCB3YW50cyB0byBv YnRhaW4gYQ0KPiA+cmVwcmVzZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUub3Jn L3BhdGgvdG8vcmVzb3VyY2UuIEFsbA0KPiA+ZXhhbXBsZXMgd29yayBmb3IgYm90aCBDb0FQIGFu ZCBIVFRQLCBleGNlcHQgZm9yIHRoZSBsYXN0IHdoaWNoIG9ubHkNCj4gPndvcmtzIGZvciBIVFRQ Lg0KPiA+DQo+ID5FeGFtcGxlIDE6IENsaWVudC0tLU9yaWdpbiBTZXJ2ZXJbZXhhbXBsZS5vcmdd DQo+ID4NCj4gPjEuIFRoZSBjbGllbnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJl IGNvbm5lY3Rpb24gdG8NCj4gPmV4YW1wbGUub3JnIDIuIFRoZSBjbGllbnQgcmVxdWVzdHMgYSBy ZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzb3VyY2UNCj4gPiAgICAvcGF0aC90by9yZXNvdXJjZSBi eSBzZW5kaW5nIGEgR0VUIHJlcXVlc3QgbWVzc2FnZSAzLiBUaGUgb3JpZ2luDQo+ID5zZXJ2ZXIg c2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlIHRvIHRoZSBjbGll bnQNCj4gDQo+IFRoZSByZXNvdXJjZSBob3N0IChvcmlnaW4gc2VydmVyKSBhbmQgdGhlIGNsaWVu dCBtdXR1YWxseSBhdXRoZW50aWNhdGVzIGFuZA0KPiBwcm90ZWN0IHRoZSByZXF1ZXN0L3Jlc3Bv bnNlIHVzaW5nIHRoZSBzZWN1cmUgY29ubmVjdGlvbi4NCj4gDQo+ID4NCj4gPkV4YW1wbGUgMjog Q2xpZW50LS0tUmV2ZXJzZSBQcm94eVtleGFtcGxlLm9yZ10tLS1PcmlnaW4NCj4gPlNlcnZlcltl eGFtcGxlLm5ldF0NCj4gPg0KPiA+MS4gVGhlIGNsaWVudCByZXNvbHZlcyBhbmQgZXN0YWJsaXNo ZXMgYSBzZWN1cmUgY29ubmVjdGlvbiB0bw0KPiA+ZXhhbXBsZS5vcmcgMi4gVGhlIGNsaWVudCBy ZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJjZQ0KPiA+L3BhdGgvdG8vcmVz b3VyY2UgMy4gVGhlIHJldmVyc2UgcHJveHkgY2hvb3NlcyB0byBzYXRpc2Z5IHRoZSByZXF1ZXN0 IGJ5DQo+IG9idGFpbmluZyB0aGUNCj4gPiAgICByZXByZXNlbnRhdGlvbiBvZiB7Y29hcHMsaHR0 cHN9Oi8vZXhhbXBsZS5uZXQvc29tZS9vdGhlci9yZXNvdXJjZQ0KPiA+ICAgIGEuIFRoZSByZXZl cnNlIHByb3h5IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25uZWN0aW9uDQo+ ID4gICAgICAgIHRvIGV4YW1wbGUubmV0DQo+ID4gICAgYi4gVGhlIHJldmVyc2UgcHJveHkgcmVx dWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzb3VyY2UNCj4gPiAgICAgICAgL3NvbWUv b3RoZXIvcmVzb3VyY2UNCj4gPiAgICBjLiBUaGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhl IHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2FsIGZpbGUNCj4gPiAgICAgICAgdG8gdGhlIHJldmVy c2UgcHJveHkNCj4gPjQuIFRoZSByZXZlcnNlIHByb3hpZXMgc2VydmVzIHRoZSByZXByZXNlbnRh dGlvbiB0byB0aGUgY2xpZW50DQo+IA0KPiBJbiB0aGlzIGNhc2UsIHRoZSByZXF1ZXN0ZWQgcmVz b3VyY2UsIGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIGNsaWVudCwgaXMNCj4gaG9zdGVk IGJ5IHRoZSByZXZlcnNlIHByb3h5LCBiZXR3ZWVuIHdoaWNoIHRoZXJlIGNhbiBiZSBtdXR1YWwN Cj4gYXV0aGVudGljYXRpb24gYW5kIHNlY3VyZSBjb25uZWN0aW9uLiBXaGVyZSB0aGUgcmV2ZXJz ZSBwcm94eSBnZXRzIGENCj4gcmVwcmVzZW50YXRpb24gZnJvbSBpcyBvdXQgb2Ygc2NvcGUgb2Yg dGhlIGNsaWVudC4NCj4gDQo+IA0KPiA+DQo+ID5FeGFtcGxlIDM6IENsaWVudC0tLUZvcndhcmQg UHJveHlbcHJveHkuZXhhbXBsZV0tLS1PcmlnaW4NCj4gPlNlcnZlcltleGFtcGxlLm9yZ10NCj4g Pg0KPiA+MS4gVGhlIGNsaWVudCByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29u bmVjdGlvbiB0bw0KPiA+cHJveHkuZXhhbXBsZSAyLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVw cmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlDQo+ID4gICAge2NvYXBzLGh0dHBzfTovL2V4YW1w bGUub3JnL3BhdGgvdG8vcmVzb3VyY2UNCj4gPjMuIFRoZSBmb3J3YXJkIHByb3h5IHNhdGlzZmll cyB0aGUgcmVxdWVzdCBieSBvYnRhaW5pbmcgdGhlDQo+ID4gICAgcmVwcmVzZW50YXRpb24gb2Yg e2NvYXBzLGh0dHBzfTovL2V4YW1wbGUub3JnL3BhdGgvdG8vcmVzb3VyY2UNCj4gPiAgICBhLiBU aGUgZm9yd2FyZCBwcm94eSByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVj dGlvbg0KPiA+ICAgICAgICB0byBleGFtcGxlLm9yZw0KPiA+ICAgIGIuIFRoZSBmb3J3YXJkIHBy b3h5IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlDQo+ID4gICAgICAg IC9wYXRoL3RvL3Jlc291cmNlDQo+ID4gICAgYy4gVGhlIG9yaWdpbiBzZXJ2ZXIgc2F0aXNmaWVz IHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlDQo+ID4gICAgICAgIHRvIHRoZSBm b3J3YXJkIHByb3h5DQo+ID40LiBUaGUgZm9yd2FyZCBwcm94eSBzZXJ2ZXMgdGhlIHJlcHJlc2Vu dGF0aW9uIHRvIHRoZSBjbGllbnQNCj4gDQo+IEluIHRoaXMgY2FzZSwgdGhlIGZvcndhcmQgcHJv eHkgYW5kIGNsaWVudCBtdXR1YWxseSBhdXRoZW50aWNhdGVzIGFuZCBlc3RhYmxpc2gNCj4gc2Vj dXJlIGNvbm5lY3Rpb24sIGFzIGRvZXMgZm9yd2FyZCBwcm94eSBhbmQgcmVzb3VyY2UgaG9zdCAo b3JpZ2luIHNlcnZlcikuDQo+IFdpdGggdGhlIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoaXMg ZXhhbXBsZSwgdGhlIHJlc291cmNlIGhvc3QgZG9lcyBub3QNCj4gYXV0aGVudGljYXRlIHRoZSBj bGllbnQsIHNvIHNvbWUgYWRkaXRpb25hbCBzZWN1cml0eSBpcyBuZWVkZWQgZm9yIHRoZSBvcmln aW4NCj4gc2VydmVyIHRvIGVuZm9yY2UgYW4gYWNjZXNzIGNvbnRyb2wgZGVjaXNpb24gb3IgZXZh bHVhdGUgYW4gYWNjZXNzIGNvbnRyb2wNCj4gcG9saWN5IHdoaWNoIGlzIGJvdW5kIHRvIGEgcGFy dGljdWxhciBjbGllbnQgKG9yIHJvbGUgb2YgY2xpZW50KS4NCj4gDQo+IFRoZXJlIGFyZSBvZiBj b3Vyc2Ugc29sdXRpb25zIHRvIHRoaXMgcHJvYmxlbSwgYnV0IHRoZSBpbXBvcnRhbnQgdGhpbmcg YXQgdGhpcw0KPiBzdGFnZSBpcyB0aGF0IGZvcndhcmQgcHJveGllcyBoYXMgYW4gaW1wYWN0IG9u IHRoZSBzb2x1dGlvbi4gSWYgd2Ugd2FudCB0bw0KPiBzdXBwb3J0IGZvcndhcmQgcHJveGllcywg ZXZlbnR1YWxseSwgdGhlbiB3ZSBzaG91bGQgbm90IHBvc3Rwb25lIHRoaXMgdG8gYQ0KPiBsYXRl ciBwaGFzZSwgYmVjYXVzZSB0aGVyZSBpcyBhIGdvb2QgY2hhbmNlIHRoYXQgd2lsbCByZXF1aXJl IGEgY29tcGxldGVseQ0KPiBkaWZmZXJlbnQgc29sdXRpb24uIEkgdGhlcmVmb3JlIHByb3Bvc2Ug dGhhdCB3ZSBpbmNsdWRlIHN1cHBvcnQgZm9yIHRoZQ0KPiBtZW50aW9uZWQgcHJveGllcyBpbiB0 aGUgYXNzdW1wdGlvbnMuDQo+IA0KPiANCj4gPg0KPiA+RXhhbXBsZSA0OiBDbGllbnQtLS1UdW5u ZWxbdHVubmVsLmV4YW1wbGVdLS0tT3JpZ2luIFNlcnZlcltleGFtcGxlLm9yZ10NCj4gPg0KPiA+ MS4gVGhlIGNsaWVudCByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYW4gdW5zZWN1cmVkIGNvbm5l Y3Rpb24gdG8NCj4gPnR1bm5lbC5leGFtcGxlIDIuIFRoZSBjbGllbnQgcmVxdWVzdHMgdGhlIHR1 bm5lbCB0byBlc3RhYmxpc2ggYW4NCj4gPnVuc2VjdXJlZCBjb25uZWN0aW9uDQo+ID4gICAgdG8g ZXhhbXBsZS5vcmcgYW5kIHRvIGFjdCBhcyBhIGJsaW5kIHJlbGF5IGJldHdlZW4gdGhlIHR3bw0K PiA+Y29ubmVjdGlvbnMgMy4gVGhlIHR1bm5lbCBzYXRpc2ZpZXMgdGhlIHJlcXVlc3QgYnkgcmVz b2x2aW5nIGFuZCBlc3RhYmxpc2hpbmcNCj4gYW4NCj4gPiAgICB1bnNlY3VyZWQgY29ubmVjdGlv biB0byBleGFtcGxlLm9yZyA0LiBUaGUgY2xpZW50IGVzdGFibGlzaGVzIGENCj4gPnNlY3VyZSBj b25uZWN0aW9uIHRvIHRoZSBvcmlnaW4gc2VydmVyDQo+ID4gICAgdGhyb3VnaCB0aGUgdHVubmVs DQo+ID41LiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291 cmNlDQo+ID4vcGF0aC90by9yZXNvdXJjZSA2LiBUaGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMg dGhlIHJlcXVlc3QgYnkgc2VydmluZw0KPiA+YSBsb2NhbCBmaWxlIHRvIHRoZSBjbGllbnQNCj4g DQo+IEluIHRoaXMgY2FzZSBjbGllbnQgYW5kIHJlc291cmNlIGhvc3QgbXV0dWFsbHkgYXV0aGVu dGljYXRlcyBhbmQgZXN0YWJsaXNoZXMNCj4gdGhlIGVuZC10by1lbmQgc2VjdXJlIGNvbm5lY3Rp b24gaW4gc3RlcCA0LiBTaW1pbGFyIHRvIGV4YW1wbGVzIDEgYW5kIDIuDQo+IA0KPiANCj4gR8O2 cmFuDQo+IA0KPiANCj4gPg0KPiA+RG9lcyB0aGF0IGFuc3dlciB5b3VyIHF1ZXN0aW9ucz8NCj4g Pg0KPiA+S2xhdXMNCj4gPg0KPiA+DQo+ID5PbiAyNSBNYXJjaCAyMDE0IDA5OjQ3LCBIYW5uZXMg VHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCj4gPndyb3RlOg0KPiA+PiBI aSBLbGF1cywNCj4gPj4NCj4gPj4gdGhhbmtzIGZvciB0aGUgZGVzY3JpcHRpb24uIFNpbmNlIEkg YW0gbm90IHN1cmUgSSB1bmRlcnN0b29kIGl0DQo+ID4+IGNvcnJlY3RseSBJIGhhdmUgYSBjb3Vw bGUgb2YgYmFzaWMgcXVlc3Rpb25zLg0KPiA+Pg0KPiA+PiBPbiAwMy8yNC8yMDE0IDA4OjUwIFBN LCBLbGF1cyBIYXJ0a2Ugd3JvdGU6DQo+ID4+PiBDb0FQIHByb3ZpZGVzIHR3byAoc3ludGFjdGlj YWxseSBkaWZmZXJlbnQpIHdheXMgZm9yIGEgY2xpZW50IChvcg0KPiA+Pj4gaW50ZXJtZWRpYXJ5 IGluIHRoZSByb2xlIG9mIGEgY2xpZW50KSB0byBwZXJmb3JtIGEgcmVxdWVzdDoNCj4gPj4+IChJ J20gdXNpbmcgcmVwcmVzZW50YXRpb24gcmV0cmlldmFsIGFzIGV4YW1wbGUgV09MT0cuKQ0KPiA+ Pj4NCj4gPj4+IEEuKSB0aGUgY2xpZW50IHJlcXVlc3RzIGEgcmVtb3RlIGVuZHBvaW50IHRvIHJl dHVybiBhIHJlcHJlc2VudGF0aW9uDQo+ID4+PiBvZiBhIHJlc291cmNlIGxvY2F0ZWQgX2luIHRo YXQgZW5kcG9pbnQncyBuYW1lc3BhY2VfLg0KPiA+Pj4NCj4gPj4+IEIuKSB0aGUgY2xpZW50IHJl cXVlc3RzIGEgcmVtb3RlIGVuZHBvaW50IHRvIHJldHVybiBhIHJlcHJlc2VudGF0aW9uDQo+ID4+ PiBvZiBhIHJlc291cmNlIGxvY2F0ZWQgX2luIGFub3RoZXIgZW5kcG9pbnQncyBuYW1lc3BhY2Vf Lg0KPiA+Pg0KPiA+PiBUaGUgY2xpZW50IGRldmljZSB3aWxsIHN0YXJ0IHdpdGggYSBzcGVjaWZp YyBGUUROIGFuZCB3aWxsIHN0YXJ0IGENCj4gPj4gRFRMUyBoYW5kc2hha2Ugd2l0aCB0aGF0IHNl cnZlci4gV2hlcmUgZG9lcyB0aGUgInJlcXVlc3RzIGEgcmVtb3RlDQo+ID4+IGVuZHBvaW50IHRv IHJldHVybiAuLi4uIiBjb21lIGludG8gdGhlIHBsYXk/DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ Pg0KPiA+Pj4gSW4gYm90aCBjYXNlcywgaXQncyBnZW5lcmFsbHkgdXAgdG8gdGhlIHJlbW90ZSBl bmRwb2ludCBob3cgaXQNCj4gPj4+IG9idGFpbnMgdGhlIHJlcHJlc2VudGF0aW9uIG9mIHRoZSB0 YXJnZXQgcmVzb3VyY2UsIGFzIGxvbmcgYXMgdGhlDQo+ID4+PiByZXN1bHQgKmlzKiBhIHJlcHJl c2VudGF0aW9uIG9mIHRoZSB0YXJnZXQgcmVzb3VyY2UuDQo+ID4+PiBGb3IgZXhhbXBsZSwgaW4g QS4sIHRoZSByZW1vdGUgZW5kcG9pbnQgY2FuIHNlcnZlIGEgbG9jYWwgZmlsZSAodGhlDQo+ID4+ PiBlbmRwb2ludCBpcyB0aGVuIHR5cGljYWxseSBjYWxsZWQgYSAic2VydmVyIiksIHJldHVybiB0 aGUgb3V0cHV0IG9mDQo+ID4+PiBhIENHSSBzY3JpcHQgKCJDR0kgZ2F0ZXdheSIpLCBvYnRhaW4g dGhlIHJlcHJlc2VudGF0aW9uIGZyb20gYW4gSFRUUA0KPiA+Pj4gc2VydmVyICgiY3Jvc3MtcHJv dG9jb2wgcHJveHkiKSwgb3Igb2J0YWluIHRoZSByZXByZXNlbnRhdGlvbiBmcm9tDQo+ID4+PiBh bm90aGVyIENvQVAgcmVtb3RlIGVuZHBvaW50ICgicmV2ZXJzZSBwcm94eSIpLiBJbiBCLiwgdGhl IHJlbW90ZQ0KPiA+Pj4gZW5kcG9pbnQgaXMgZ2VuZXJhbGx5IGV4cGVjdGVkIHRvIG9idGFpbiB0 aGUgcmVwcmVzZW50YXRpb24gYnkNCj4gPj4+IHJlcXVlc3RpbmcgaXQgZnJvbSB0aGUgZW5kcG9p bnQgc3BlY2lmaWVkIGluIHRoZSByZXF1ZXN0IFVSSQ0KPiA+Pj4gKCJmb3J3YXJkIHByb3h5Iiku DQo+ID4+Pg0KPiA+Pj4gSW4gYm90aCBjYXNlcywgdGhlIGNsaWVudCBoYXMgbm8gd2F5IHRvIHZl cmlmeSB0aGF0IHRoZSBvYnRhaW5lZA0KPiA+Pj4gcmVzdWx0IGlzIGluZGVlZCBhIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSB0YXJnZXQgcmVzb3VyY2UuIEl0IG11c3QNCj4gPj4+IHRydXN0IHRoZSBy ZW1vdGUgZW5kcG9pbnQgdGhhdCBpdCByZXR1cm5zIHRoZSBjb3JyZWN0IHJlcHJlc2VudGF0aW9u Lg0KPiA+Pj4gRFRMUyBqdXN0IHNlY3VyZXMgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgcmVwcmVz ZW50YXRpb24gZnJvbSB0aGUNCj4gPj4+IHJlbW90ZSBlbmRwb2ludCB0byB0aGUgY2xpZW50Lg0K PiA+Pj4NCj4gPj4+IChBRkFJSywgSFRUUCB3b3JrcyBleGFjdGx5IHRoZSBzYW1lIHdheS4pDQo+ ID4+DQo+ID4+IEluIHRoZSBIVFRQUyBjYXNlIHRoZSBzdG9yeSBpcyBhcyBmb2xsb3dzOg0KPiA+ Pg0KPiA+PiAqIFRoZSBjbGllbnQgY29udGFjdHMgdGhlIHNlcnZlciBiZWhpbmQgYSBodHRwczov L3d3dy5pZXRmLm9yZyAoYWZ0ZXINCj4gPj4gZG9pbmcgYSBETlMgbG9vay11cCkgdXNpbmcgVExT Lg0KPiA+Pg0KPiA+PiAqIEl0IGdldHMgdGhlIGNlcnQgZnJvbSB0aGUgc2VydmVyLg0KPiA+Pg0K PiA+PiAqIFRoZSBjbGllbnQgY29tcGFyZXMgdGhlIGNvbnRlbnQgb2YgdGhlIGNlcnQgd2l0aCB3 aGF0IGl0IGhhZA0KPiA+PiBpbml0aWFsbHkgcmVxdWVzdGVkIHRvIGVuc3VyZSBpdCB0YWxrcyB0 byB0aGUgcmlnaHQgc2VydmVyLg0KPiA+Pg0KPiA+PiBUaGUgVExTIHdpbGwgcHJldmVudCBhbnkg cHJveHkgYWxvbmcgdGhlIHBhdGggdG8gY2FjaGUgdGhlIGRhdGENCj4gPj4gKHNpbmNlIGl0IGlz IGVuY3J5cHRlZCkuDQo+ID4+DQo+ID4+IFNvLCBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIGNvbXBh cmVzIHRvIENvQVAgYmFzZWQgb24geW91ciBkZXNjcmlwdGlvbi4NCj4gPj4NCj4gPj4gQ2lhbw0K PiA+PiBIYW5uZXMNCj4gPj4NCj4gPj4NCj4gPj4+DQo+ID4+PiBTbywgSSB3b3VsZCBzYXkgdGhh dA0KPiA+Pj4NCj4gPj4+IC0gQUNFIHNob3VsZCBjb25zaWRlciBmb3J3YXJkIHByb3hpZXMsIHJl dmVyc2UgcHJveGllcyBhbmQNCj4gPj4+IHBvdGVudGlhbGx5IGNyb3NzLXByb3RvY29sIHByb3hp ZXMgc3VjaCB0aGF0IG9uZSBvZiB0aGVzZSBjYW4gb2J0YWluDQo+ID4+PiBhIHJlcHJlc2VudGF0 aW9uIG9mIGEgcmVzb3VyY2UgdGhhdCBhIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIGFjY2Vzcw0K PiA+Pj4gb24gYmVoYWxmIG9mIHRoYXQgY2xpZW50OyBhbmQNCj4gPj4+DQo+ID4+PiAtIEFDRSBz aG91bGQgbm90IGNvbnNpZGVyIHJlbW90ZSBlbmRwb2ludHMgdGhhdCBjYW5ub3QgYmUgdHJ1c3Rl ZCB0bw0KPiA+Pj4gY29ycmVjdGx5IHJldHVybiBhIHJlcHJlc2VudGF0aW9uIG9mIGEgdGFyZ2V0 IHJlc291cmNlIChhcyB0aGlzDQo+ID4+PiBjb25jZXJucyB0aGUgZ2VuZXJhbCBzZWN1cml0eSBv ZiBDb0FQIHdoaWNoIHNob3VsZCBiZSBhZGRyZXNzZWQgaW4NCj4gPj4+IENvUkUpLg0KPiA+Pj4N Cj4gPj4+IEtsYXVzDQo+ID4NCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID5BY2UgbWFpbGluZyBsaXN0DQo+ID5BY2VAaWV0Zi5vcmcNCj4gPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBY2UgbWFpbGluZyBsaXN0 DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FjZQ0K From nobody Fri Mar 28 01:29:45 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039831A01F0 for ; Fri, 28 Mar 2014 01:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuqNgXD0kaC0 for ; Fri, 28 Mar 2014 01:29:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 780091A02A3 for ; Fri, 28 Mar 2014 01:29:38 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-17-533532ef34f1 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1A.5D.23809.FE235335; Fri, 28 Mar 2014 09:29:35 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.80]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Fri, 28 Mar 2014 09:29:34 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Likepeng , Klaus Hartke , "Ace@ietf.org" Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyElZezb277v0yV5TaQjbw7iZrvavMA///keQCAAMpVgIAAOAQAgAAhv4CAACJhAIAA2T4AgABkt4CAAyiPgIAAEFIAgAD5QgCAACvagA== Date: Fri, 28 Mar 2014 08:29:34 +0000 Message-ID: References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B017@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B017@SZXEMA501-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <8041BF8BBF6F574A808F78318E7AB9A0@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje57I9Ngg+3fTCy+f+thttg2+RWT xZ7DTcwOzB4tR96yeixZ8pPJY9qizADmKC6blNSczLLUIn27BK6MltWL2At+eVcsufGUqYGx wauLkZNDQsBEYv2tRcwQtpjEhXvr2boYuTiEBA4xSsw7MoUdwlnMKLFv4jkmkCo2AReJBw2P wGwRgSSJRX8msoPYwgJGEjsn9bF2MXIAxY0lHv3igyipk9iy4zsjiM0ioCpxaEYTmM0rYC6x /fc9sDFCAmtYJP6d8AGxOQXCJBpXPGMBsRmBDvp+ag1YDbOAuMStJ/OZIA4VkFiy5zzU0aIS Lx//YwWxRQX0JO49mssCEVeSaFzyBOwcZgFNifW79CHGWEuc3/GfEcJWlJjS/ZAd4hxBiZMz n7BMYBSfhWTbLITuWUi6ZyHpnoWkewEj6ypG9tzEzJz0cqNNjMAIO7jlt+oOxjvnRA4xSnOw KInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkf2Tr7xDosnmjMSVm5M5fD0PL9S8 lvWurtGAN/Tla3mRAD+7smuLUpf90+qrSZGLeFjo9XDBpK+Ls8xnx5REcwrtjbC0e296Uvv+ qf9G04I2tD6pTKz/VnmP/1vJ9tubOc5zhxpu6ips05dTinW51+siesSj7/xqm3fn3eeJ7Muv vbHxCr+7EktxRqKhFnNRcSIAa6CyD34CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/B84SwNPB6ap4_S5HYKx2tyMM24s Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 08:29:42 -0000 SGkgS2VwZW5nDQoNCk9uIDI4LzAzLzE0IDA3OjUyLCAiTGlrZXBlbmciIDxsaWtlcGVuZ0BodWF3 ZWkuY29tPiB3cm90ZToNCg0KPj4gVGhlbiB0aGVyZSBtdXN0IGJlIGEgc3RhbmRhcmQgd2F5IGZv ciB0aGUgY2xpZW50IHRvDQo+PihBLikgc2VjdXJlbHkgZGlzY292ZXIgdGhlIHRoaXJkIHBhcnR5 LA0KPj4oQi4pIHBlcmZvcm0gc3RlcHMgdG8gZmlyc3QgYmVjb21lIGFuIGF1dGhlbnRpY2F0ZWQg Y2xpZW50IGFuZCB0aGVuIGFuDQo+PmF1dGhvcml6ZWQgY2xpZW50LA0KPj4oQy4pIHRvIG1ha2Ug YSByZXF1ZXN0IGFzIGFuIGF1dGhvcml6ZWQgKGJ1dCBub3QgbmVjZXNzYXJpbHkNCj4+YXV0aGVu dGljYXRlZCkgY2xpZW50Lg0KPg0KPlRoZXNlIHRocmVlIHJlcXVpcmVtZW50cyBzaG91bGQgYmUg YWxyZWFkeSB0aGVyZSwgZXZlbiB3aXRob3V0IHByb3h5Lg0KPg0KPj4gU28gdGhlcmUgbXVzdCBi ZSAoRC4pIGEgc3RhbmRhcmQgd2F5IGZvciB0aGUgcmV2ZXJzZSBwcm94eSB0byBtYWtlDQo+PnJl cXVlc3RzIHRvIHRoZSBvcmlnaW4gc2VydmVyIG9uIGJlaGFsZiBvZiBhbiBhdXRob3JpemVkIGNs aWVudC4NCj4+IFNvIHRoZXJlIG11c3QgYmUgKEUuKSBhIHN0YW5kYXJkIHdheSBmb3IgdGhlIGZv cndhcmQgcHJveHkgdG8gbWFrZQ0KPj5yZXF1ZXN0cyB0byB0aGUgb3JpZ2luIHNlcnZlciBvbiBi ZWhhbGYgb2YgYW4gYXV0aG9yaXplZCBjbGllbnQuDQo+DQo+SW4gbXkgdW5kZXJzdGFuZGluZywg dGhlc2UgdHdvIHJlcXVpcmVtZW50cyBzaG91bGQgbm90IGltcGFjdCBvdXIgYmFzaWMNCj5zb2x1 dGlvbiAobm8gcHJveHkgaW52b2x2ZWQpLg0KDQpJ4oCZbSBhZnJhaWQgdGhleSBkby4gTWF5YmUg bW9yZSBjbGVhciBpZiB5b3UgZm9ybXVsYXRlIHRoZSByZXF1aXJlbWVudCBhcw0KIml0IHNob3Vs ZCBiZSBwb3NzaWJsZSBmb3IgdGhlIG9yaWdpbiBzZXJ2ZXIgdG8gYXV0aG9yaXNlIGEgY2xpZW50 IGJlaGluZA0KYSBmb3J3YXJkIHByb3h54oCdIGV0Yy4NCg0KTm90ZSB0aGF0IGFsc28gaW4gRENB RiAod2hhdCBDYXJzdGVuIGNhbGwg4oCcdGhlIEJlcmxpbiBtb2RlbOKAnSkgdGhlDQpBdXRoZW50 aWNhdGlvbiBNYW5hZ2VyIGlzIGFub3RoZXIgaW50ZXJtZWRpYXJ5IHJlcXVlc3RpbmcgYWNjZXNz IG9uIGJlaGFsZg0Kb2YgYSBjbGllbnQuDQoNCg0KPg0KPldlIGNhbiBkZWZpbmUgb3VyIGJhc2lj IHNvbHV0aW9uIChubyBwcm94eSBpbnZvbHZlZCkgaW4gdGhlIGZpcnN0IHN0YWdlLA0KPmFuZCBk ZWZpbmUgZXh0ZW5kZWQgc29sdXRpb24gKHdpdGggcHJveHkgaW52b2x2ZWQpIGluIHRoZSBzZWNv bmQgc3RhZ2UuDQoNCkNvbnNpZGVyaW5nIHRoYXQgdGhlIGV4dGVuZGVkIHNvbHV0aW9uIG1heSBi ZSBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IEkNCnRoaW5rIGl0IHdvdWxkIGJlIHVud2lzZSB0byBk aXNyZWdhcmQgdGhlc2UgY2FzZXMgaW4gYSBmaXJzdCBzdGFnZS4NCg0KDQpHw7ZyYW4NCg0KPg0K PktpbmQgUmVnYXJkcw0KPktlcGVuZw0KPg0KPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4g 5Y+R5Lu25Lq6OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEtsYXVz IEhhcnRrZQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0M+aciDI45pelIDA6MDANCj4+IOaUtuS7 tuS6ujogQWNlQGlldGYub3JnDQo+PiDkuLvpopg6IFJlOiBbQWNlXSBTdW1tYXJ5IG9mIHRoZSBQ cm94eSBEaXNjdXNzaW9uDQo+PiANCj4+IEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+ID4+RXhh bXBsZSAxOiBDbGllbnQtLS1PcmlnaW4gU2VydmVyW2V4YW1wbGUub3JnXQ0KPj4gPj4NCj4+ID4+ MS4gVGhlIGNsaWVudCByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlv biB0bw0KPj4gPj5leGFtcGxlLm9yZyAyLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50 YXRpb24gb2YgdGhlIHJlc291cmNlDQo+PiA+PiAgICAvcGF0aC90by9yZXNvdXJjZSBieSBzZW5k aW5nIGEgR0VUIHJlcXVlc3QgbWVzc2FnZSAzLiBUaGUgb3JpZ2luDQo+PiA+PnNlcnZlciBzYXRp c2ZpZXMgdGhlIHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2FsIGZpbGUgdG8gdGhlIGNsaWVudA0K Pj4gPg0KPj4gPiBUaGUgcmVzb3VyY2UgaG9zdCAob3JpZ2luIHNlcnZlcikgYW5kIHRoZSBjbGll bnQgbXV0dWFsbHkNCj4+ID4gYXV0aGVudGljYXRlcyBhbmQgcHJvdGVjdCB0aGUgcmVxdWVzdC9y ZXNwb25zZSB1c2luZyB0aGUgc2VjdXJlDQo+PiBjb25uZWN0aW9uLg0KPj4gDQo+PiBBbmQgdGhp cyBpcyBwcm9iYWJseSB0aGUgbW9zdCBiYXNpYyBzb2x1dGlvbiB0byBhdXRob3JpemVkIHJlc291 cmNlDQo+PiBhY2Nlc3M6IFRoZSBvcmlnaW4gc2VydmVyIGNhbiBkZXRlcm1pbmUgZm9yIGVhY2gg cmVxdWVzdCBpZiB0aGUNCj4+YXV0aGVudGljYXRlZA0KPj4gY2xpZW50IGlzIGF1dGhvcml6ZWQg dG8gcGVyZm9ybSB0aGUgcmVxdWVzdGVkIGFjdGlvbiBvbiB0aGUgdGFyZ2V0DQo+PnJlc291cmNl IG9yDQo+PiBub3QuDQo+PiANCj4+IFRoZSBpbXBvcnRhbnQgdGhpbmcgdG8gbm90ZSBoZXJlIGlz IHRoYXQgdGhlIG9yaWdpbiBzZXJ2ZXIgaXMgYWN0dWFsbHkNCj4+IHBlcmZvcm1pbmcgdGhyZWUg dGFza3M6DQo+PiANCj4+ICgxLikgYXV0aGVudGljYXRpbmcgb2YgdGhlIGNsaWVudCwNCj4+ICgy LikgaGF2aW5nIGtub3dsZWRnZSBvZiB3aGljaCBhY3Rpb25zIHRoZSBfYXV0aGVudGljYXRlZF8g Y2xpZW50IGlzDQo+PiBhdXRob3JpemVkIHRvIHBlcmZvcm0gb24gd2hpY2ggcmVzb3VyY2VzLCBh bmQNCj4+ICgzLikgcGVyZm9ybWluZyB0aGUgYWN0aW9uIHJlcXVlc3RlZCBieSBhbiBfYXV0aG9y aXplZF8gY2xpZW50IG9uIGENCj4+cmVzb3VyY2UuDQo+PiANCj4+IElmIHRoZSBvcmlnaW4gc2Vy dmVyIGlzIHRvbyBjb25zdHJhaW5lZCB0byBwZXJmb3JtIGFsbCB0aGVzZSB0YXNrcywgdGhlDQo+ PmlkZWEgaXMgdG8NCj4+IG9mZi1sb2FkIHNvbWUgb2YgdGhlbSAoMS4gYW5kIDIuKSB0byBhIGxl c3MgY29uc3RyYWluZWQgdGhpcmQgcGFydHkuDQo+PiANCj4+IFRoZW4gdGhlcmUgbXVzdCBiZSBh IHN0YW5kYXJkIHdheSBmb3IgdGhlIGNsaWVudCB0byAoQS4pIHNlY3VyZWx5DQo+PmRpc2NvdmVy IHRoZQ0KPj4gdGhpcmQgcGFydHksIChCLikgcGVyZm9ybSBzdGVwcyB0byBmaXJzdCBiZWNvbWUg YW4gYXV0aGVudGljYXRlZCBjbGllbnQNCj4+YW5kDQo+PiB0aGVuIGFuIGF1dGhvcml6ZWQgY2xp ZW50LCBhbmQgZmluYWxseSAoQy4pIHRvIG1ha2UgYSByZXF1ZXN0IGFzIGFuDQo+PmF1dGhvcml6 ZWQNCj4+IChidXQgbm90IG5lY2Vzc2FyaWx5IGF1dGhlbnRpY2F0ZWQpIGNsaWVudC4NCj4+IA0K Pj4gPj5FeGFtcGxlIDI6IENsaWVudC0tLVJldmVyc2UgUHJveHlbZXhhbXBsZS5vcmddLS0tT3Jp Z2luDQo+PiA+PlNlcnZlcltleGFtcGxlLm5ldF0NCj4+ID4+DQo+PiA+PjEuIFRoZSBjbGllbnQg cmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24gdG8NCj4+ID4+ZXhh bXBsZS5vcmcgMi4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBy ZXNvdXJjZQ0KPj4gPj4vcGF0aC90by9yZXNvdXJjZSAzLiBUaGUgcmV2ZXJzZSBwcm94eSBjaG9v c2VzIHRvIHNhdGlzZnkgdGhlIHJlcXVlc3QNCj4+YnkNCj4+IG9idGFpbmluZyB0aGUNCj4+ID4+ ICAgIHJlcHJlc2VudGF0aW9uIG9mIHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm5ldC9zb21lL290 aGVyL3Jlc291cmNlDQo+PiA+PiAgICBhLiBUaGUgcmV2ZXJzZSBwcm94eSByZXNvbHZlcyBhbmQg ZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbg0KPj4gPj4gICAgICAgIHRvIGV4YW1wbGUu bmV0DQo+PiA+PiAgICBiLiBUaGUgcmV2ZXJzZSBwcm94eSByZXF1ZXN0cyBhIHJlcHJlc2VudGF0 aW9uIG9mIHRoZSByZXNvdXJjZQ0KPj4gPj4gICAgICAgIC9zb21lL290aGVyL3Jlc291cmNlDQo+ PiA+PiAgICBjLiBUaGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhlIHJlcXVlc3QgYnkgc2Vy dmluZyBhIGxvY2FsIGZpbGUNCj4+ID4+ICAgICAgICB0byB0aGUgcmV2ZXJzZSBwcm94eQ0KPj4g Pj40LiBUaGUgcmV2ZXJzZSBwcm94aWVzIHNlcnZlcyB0aGUgcmVwcmVzZW50YXRpb24gdG8gdGhl IGNsaWVudA0KPj4gPg0KPj4gPiBJbiB0aGlzIGNhc2UsIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2Us IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlDQo+PiA+IGNsaWVudCwgaXMgaG9zdGVkIGJ5 IHRoZSByZXZlcnNlIHByb3h5LCBiZXR3ZWVuIHdoaWNoIHRoZXJlIGNhbiBiZQ0KPj4gPiBtdXR1 YWwgYXV0aGVudGljYXRpb24gYW5kIHNlY3VyZSBjb25uZWN0aW9uLiBXaGVyZSB0aGUgcmV2ZXJz ZSBwcm94eQ0KPj4gPiBnZXRzIGEgcmVwcmVzZW50YXRpb24gZnJvbSBpcyBvdXQgb2Ygc2NvcGUg b2YgdGhlIGNsaWVudC4NCj4+IA0KPj4gSXQgbWF5IGJlIHRoZSBvcmlnaW4gc2VydmVyIFtleGFt cGxlLm5ldF0sIHRob3VnaCwgd2hpY2ggaGFzIHRoZQ0KPj5rbm93bGVkZ2Ugb2YNCj4+IHdoaWNo IGFjdGlvbnMgdGhlIGNsaWVudCAod2hpY2ggYXV0aGVudGljYXRlZCB0byB0aGUgcmV2ZXJzZSBw cm94eQ0KPj4gW2V4YW1wbGUub3JnXSkgaXMgYXV0aG9yaXplZCB0byBwZXJmb3JtIG9uIHdoaWNo IHJlc291cmNlcy4gVGhlIHJldmVyc2UNCj4+cHJveHkNCj4+IGNvdWxkIG1lcmVseSBhY3QgYXMg YSBzaW1wbGUgY2FjaGUgaW4gZnJvbnQgb2YgdGhlIG9yaWdpbiBzZXJ2ZXIuDQo+PiANCj4+IFNv IHRoZXJlIG11c3QgYmUgKEQuKSBhIHN0YW5kYXJkIHdheSBmb3IgdGhlIHJldmVyc2UgcHJveHkg dG8gbWFrZQ0KPj5yZXF1ZXN0cyB0bw0KPj4gdGhlIG9yaWdpbiBzZXJ2ZXIgb24gYmVoYWxmIG9m IGFuIGF1dGhvcml6ZWQgY2xpZW50Lg0KPj4gDQo+PiA+PkV4YW1wbGUgMzogQ2xpZW50LS0tRm9y d2FyZCBQcm94eVtwcm94eS5leGFtcGxlXS0tLU9yaWdpbg0KPj4gPj5TZXJ2ZXJbZXhhbXBsZS5v cmddDQo+PiA+Pg0KPj4gPj4xLiBUaGUgY2xpZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBh IHNlY3VyZSBjb25uZWN0aW9uIHRvDQo+PiA+PnByb3h5LmV4YW1wbGUgMi4gVGhlIGNsaWVudCBy ZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJjZQ0KPj4gPj4gICAge2NvYXBz LGh0dHBzfTovL2V4YW1wbGUub3JnL3BhdGgvdG8vcmVzb3VyY2UNCj4+ID4+My4gVGhlIGZvcndh cmQgcHJveHkgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUNCj4+ID4+ICAg IHJlcHJlc2VudGF0aW9uIG9mIHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm9yZy9wYXRoL3RvL3Jl c291cmNlDQo+PiA+PiAgICBhLiBUaGUgZm9yd2FyZCBwcm94eSByZXNvbHZlcyBhbmQgZXN0YWJs aXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbg0KPj4gPj4gICAgICAgIHRvIGV4YW1wbGUub3JnDQo+ PiA+PiAgICBiLiBUaGUgZm9yd2FyZCBwcm94eSByZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9m IHRoZSByZXNvdXJjZQ0KPj4gPj4gICAgICAgIC9wYXRoL3RvL3Jlc291cmNlDQo+PiA+PiAgICBj LiBUaGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhlIHJlcXVlc3QgYnkgc2VydmluZyBhIGxv Y2FsIGZpbGUNCj4+ID4+ICAgICAgICB0byB0aGUgZm9yd2FyZCBwcm94eQ0KPj4gPj40LiBUaGUg Zm9yd2FyZCBwcm94eSBzZXJ2ZXMgdGhlIHJlcHJlc2VudGF0aW9uIHRvIHRoZSBjbGllbnQNCj4+ ID4NCj4+ID4gSW4gdGhpcyBjYXNlLCB0aGUgZm9yd2FyZCBwcm94eSBhbmQgY2xpZW50IG11dHVh bGx5IGF1dGhlbnRpY2F0ZXMgYW5kDQo+PiA+IGVzdGFibGlzaCBzZWN1cmUgY29ubmVjdGlvbiwg YXMgZG9lcyBmb3J3YXJkIHByb3h5IGFuZCByZXNvdXJjZSBob3N0DQo+PiA+IChvcmlnaW4gc2Vy dmVyKS4NCj4+IA0KPj4gSXQgaXMgbm90ZXdvcnRoeSBoZXJlIHRoYXQgdGhlIGNsaWVudCBjYW4g b25seSByZXF1ZXN0IHRoZSBmb3J3YXJkDQo+PnByb3h5IHRvDQo+PiBtYWtlIGl0cyByZXF1ZXN0 IHRvIHRoZSBvcmlnaW4gc2VydmVyIHNlY3VyZWx5IChieSBzcGVjaWZ5aW5nIHRoZQ0KPj4iY29h cHMiDQo+PiBzY2hlbWUpLiBJdCBoYXMgbm8gaW5mbHVlbmNlIG9uIGFjY2VwdGFibGUgY2lwaGVy IHN1aXRzLCBjZXJ0aWZpY2F0ZQ0KPj5yb290cywgZXRjLg0KPj4gVGhlIGNsaWVudCBoYXMgdG8g dHJ1c3QgdGhlIGZvcndhcmQgcHJveHkgdGhhdCBpdCBzZWN1cmVzIHRoZQ0KPj5jb25uZWN0aW9u IHRvIHRoZQ0KPj4gb3JpZ2luIHNlcnZlciBpbiBhIHdheSB0aGF0IGlzIGFjY2VwdGFibGUgdG8g dGhlIGNsaWVudC4NCj4+IA0KPj4gPiBXaXRoIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0 aGlzIGV4YW1wbGUsIHRoZSByZXNvdXJjZSBob3N0IGRvZXMNCj4+ID4gbm90IGF1dGhlbnRpY2F0 ZSB0aGUgY2xpZW50LCBzbyBzb21lIGFkZGl0aW9uYWwgc2VjdXJpdHkgaXMgbmVlZGVkIGZvcg0K Pj4gPiB0aGUgb3JpZ2luIHNlcnZlciB0byBlbmZvcmNlIGFuIGFjY2VzcyBjb250cm9sIGRlY2lz aW9uIG9yIGV2YWx1YXRlIGFuDQo+PiA+IGFjY2VzcyBjb250cm9sIHBvbGljeSB3aGljaCBpcyBi b3VuZCB0byBhIHBhcnRpY3VsYXIgY2xpZW50IChvciByb2xlDQo+PiA+IG9mIGNsaWVudCkuDQo+ PiANCj4+IFNvIHRoZXJlIG11c3QgYmUgKEUuKSBhIHN0YW5kYXJkIHdheSBmb3IgdGhlIGZvcndh cmQgcHJveHkgdG8gbWFrZQ0KPj5yZXF1ZXN0cw0KPj4gdG8gdGhlIG9yaWdpbiBzZXJ2ZXIgb24g YmVoYWxmIG9mIGFuIGF1dGhvcml6ZWQgY2xpZW50Lg0KPj4gDQo+PiBLbGF1cw0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQWNlIG1h aWxpbmcgbGlzdA0KPj4gQWNlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FjZQ0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+QWNlIG1haWxpbmcgbGlzdA0KPkFjZUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg== From nobody Fri Mar 28 01:32:26 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A891A0489 for ; Fri, 28 Mar 2014 01:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRGO4mXzyg9z for ; Fri, 28 Mar 2014 01:32:20 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2AA1A01F0 for ; Fri, 28 Mar 2014 01:32:19 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-45-53353390903e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 53.B1.04853.09335335; Fri, 28 Mar 2014 09:32:17 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.80]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Fri, 28 Mar 2014 09:32:16 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Likepeng , Klaus Hartke , "Ace@ietf.org" Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyElZezb277v0yV5TaQjbw7iZrvavMA///keQCAAMpVgIAAOAQAgAAhv4CAACJhAIAA2T4AgABkt4CAAyiPgIABE+CAgAAiT4A= Date: Fri, 28 Mar 2014 08:32:16 +0000 Message-ID: References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B049@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B049@SZXEMA501-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <5563FD023779494EB275627500FBCD9C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvje5EY9Nggz2PmC2+f+thttg2+RWT xZ7DTcwOzB4tR96yeixZ8pPJY9qizADmKC6blNSczLLUIn27BK6Mw/cusRQsKqhY9u8SYwPj htwuRg4OCQETiTcLhLoYOYFMMYkL99azdTFycQgJnGCU+Dl1JiuEs5hRYmZ7JyNIFZuAi8SD hkdMILaIQJLEoj8T2UFsYQEjiZ2T+lhBhooIGEs8+sUHYZZJrH6QC1LBIqAqsWNRAxuIzStg LvHj1Rx2iPFPmSX2f97NApLgFAiTWL5zKtgqRqCDvp9aA7aKWUBc4taT+UwQhwpILNlznhnC FpV4+fgfK4gtKqAnce/RXBaIuJJE45InYOcwC2hKrN+lDzHGWuLc3FlQIxUlpnQ/ZIe4R1Di 5MwnLBMYxWch2TYLoXsWku5ZSLpnIelewMi6ilGyOLW4ODfdyEAvNz23RC+1KDO5uDg/T684 dRMjMAYPbvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCu sGY5mpjiVbX7a0nI7oNXLctq+z2PnpA16Q5+lfj0YffS2pPLrhg1cPpu2jdxNt+rmiPLYp4/ 6rgf3CDssVVJzOrMLkEdn9/dGi/iq5kZ7JniDeN333qxKVbmX0zIlIXnEqLC5v/M82t4GcZQ 9UWWuU5R4w83y9vNbtxG0cclpXZuTf3EfEuJpTgj0VCLuag4EQACcZMmjwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/dkRQh8SlsR4BtfHNHAdJr9vr9DE Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 08:32:23 -0000 DQoNCk9uIDI4LzAzLzE0IDA4OjI5LCAiTGlrZXBlbmciIDxsaWtlcGVuZ0BodWF3ZWkuY29tPiB3 cm90ZToNCg0KPj4gVGhlcmUgYXJlIG9mIGNvdXJzZSBzb2x1dGlvbnMgdG8gdGhpcyBwcm9ibGVt LCBidXQgdGhlIGltcG9ydGFudCB0aGluZw0KPj5hdCB0aGlzDQo+PiBzdGFnZSBpcyB0aGF0IGZv cndhcmQgcHJveGllcyBoYXMgYW4gaW1wYWN0IG9uIHRoZSBzb2x1dGlvbi4gSWYgd2Ugd2FudA0K Pj50bw0KPj4gc3VwcG9ydCBmb3J3YXJkIHByb3hpZXMsIGV2ZW50dWFsbHksIHRoZW4gd2Ugc2hv dWxkIG5vdCBwb3N0cG9uZSB0aGlzDQo+PnRvIGENCj4+IGxhdGVyIHBoYXNlLCBiZWNhdXNlIHRo ZXJlIGlzIGEgZ29vZCBjaGFuY2UgdGhhdCB3aWxsIHJlcXVpcmUgYQ0KPj5jb21wbGV0ZWx5DQo+ PiBkaWZmZXJlbnQgc29sdXRpb24uIEkgdGhlcmVmb3JlIHByb3Bvc2UgdGhhdCB3ZSBpbmNsdWRl IHN1cHBvcnQgZm9yIHRoZQ0KPj4gbWVudGlvbmVkIHByb3hpZXMgaW4gdGhlIGFzc3VtcHRpb25z Lg0KPg0KPkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgdGhlIHJlcXVpcmVtZW50cyBm b3IgdGhlIHByb3h5IHN1cHBvcnQNCj53aGVuIHdlIGRlc2lnbiBvdXIgc29sdXRpb24uDQo+DQo+ QnV0IEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGRlc2lnbiBvdXIgc29sdXRpb24gc3RlcCBieSBz dGVwLCBpbg0KPmRpZmZlcmVudCBwaGFzZXMuDQo+DQo+TXkgd29ycnkgaXMsIHByb3h5IGlzIHF1 aXRlIGNvbXBsZXggdG8gc3VwcG9ydCwgdGhpcyBtYXkgZGVsYXkgb3VyDQo+cHJvZ3Jlc3MgdG8g ZmluaXNoIG91ciBiYXNpYyBzb2x1dGlvbi4NCj4NCj5BbHNvIHdlIGRvbuKAmXQgaGF2ZSBkcmFm dHMgYXZhaWxhYmxlIHlldCwgSSBhbSBub3Qgc3VyZSB3aG8gY2FuIGxlYWQgdGhpcw0KPndvcmss IGFuZCBob3cgbG9uZyBpdCB3aWxsIHRha2UuDQoNCkkgdGhpbmsgdGhlIG1haWwgZXhjaGFuZ2Ug aXMgYSBnb29kIHN0YXJ0IGZvciBhIHByb2JsZW0gc3RhdGVtZW50IGFuZA0KdGVudGF0aXZlIHJl cXVpcmVtZW50cyAoYWx0aG91Z2ggSSBkb27igJl0IGV4YWN0bHkgYWdyZWUgd2l0aCB0aGUgY3Vy cmVudA0KZm9ybXVsYXRpb24pLiBKdWRnaW5nIGJ5IHRoZSBlbnRodXNpYXNtIG9mIHZvbHVudGVl cnMgcG9wcGluZyB1cCBJIGRvbuKAmXQNCnRoaW5rIGl0IHdpbGwgYmUgZGlmZmljdWx0IHRvIGZp bmQgYSBkcml2ZXIgZm9yIHRoaXMgd29yayA7LSkNCg0KSnVzdCBhcyBhIG5vdGUgZnJvbSBhIGJl Z2lubmVyOiBJdCBpcyBhIGJpdCBwdXp6bGluZyB0byBtZSwgdGhhdCBvbiB0aGUNCm9uZSBoYW5k IHNpZGUgaGF2aW5nIGEgZHJhZnQgKGFzIGluIHRoZSBleGFtcGxlIG9mIHRoZSB1c2UgY2FzZSBh bmQNCnJlcXVpcmVtZW50cykgaXMgYSBwcm9ibGVtIGFuZCBub3QgaGF2aW5nIGEgZHJhZnQgKGFz IGluIHRoZSBjdXJyZW50DQpleGFtcGxlKSBpcyBhbHNvIGEgcHJvYmxlbSA6LSkNCg0KDQpHw7Zy YW4NCg0KDQo+DQo+S2luZCBSZWdhcmRzDQo+S2VwZW5nDQo+DQo+PiAtLS0tLemCruS7tuWOn+S7 ti0tLS0tDQo+PiDlj5Hku7bkuro6IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDk u6PooaggRz9yYW4gU2VsYW5kZXINCj4+IOWPkemAgeaXtumXtDogMjAxNOW5tDPmnIgyN+aXpSAy MjowMg0KPj4g5pS25Lu25Lq6OiBLbGF1cyBIYXJ0a2U7IEFjZUBpZXRmLm9yZw0KPj4g5Li76aKY OiBSZTogW0FjZV0gU3VtbWFyeSBvZiB0aGUgUHJveHkgRGlzY3Vzc2lvbg0KPj4gDQo+PiBIaSBL bGF1cw0KPj4gDQo+PiBUaGFua3MgZm9yIHRoZXNlIGV4cGxpY2l0IGV4YW1wbGVzLiBJIGJlbGll dmUgZXhhbXBsZSAzIC0gdGhlIGZvcndhcmQNCj4+cHJveHkgLSBpcw0KPj4gZGlmZmVyZW50IGZy b20gdGhlIG90aGVycyB3aXRoIHJlc3BlY3QgdG8gZW5kLXRvLWVuZCBzZWN1cml0eSBiZXR3ZWVu DQo+PmNsaWVudA0KPj4gYW5kIHJlcXVlc3RlZCByZXNvdXJjZS4gSSB0aGluayB0aGF0IGhhcyBh biBpbXBhY3Qgb24gdGhlIHNvbHV0aW9uIHNvIHdlDQo+PiBzaG91bGQgZXhwbGljaXRseSBjb25z aWRlciB0aGVzZSBleGFtcGxlcyBpbiB0aGUgd29yay4gU2VlIGNvbW1lbnRzDQo+PmlubGluZS4N Cj4+IA0KPj4gDQo+PiBPbiAyNS8wMy8xNCAxNTo0OCwgIktsYXVzIEhhcnRrZSIgPGhhcnRrZUB0 emkub3JnPiB3cm90ZToNCj4+IA0KPj4gPkhpIEhhbm5lcywNCj4+ID4NCj4+ID5oZXJlIGFyZSBh IGZldyBleGFtcGxlcy4gSW4gZWFjaCBleGFtcGxlLCB0aGUgY2xpZW50IHdhbnRzIHRvIG9idGFp biBhDQo+PiA+cmVwcmVzZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUub3JnL3Bh dGgvdG8vcmVzb3VyY2UuIEFsbA0KPj4gPmV4YW1wbGVzIHdvcmsgZm9yIGJvdGggQ29BUCBhbmQg SFRUUCwgZXhjZXB0IGZvciB0aGUgbGFzdCB3aGljaCBvbmx5DQo+PiA+d29ya3MgZm9yIEhUVFAu DQo+PiA+DQo+PiA+RXhhbXBsZSAxOiBDbGllbnQtLS1PcmlnaW4gU2VydmVyW2V4YW1wbGUub3Jn XQ0KPj4gPg0KPj4gPjEuIFRoZSBjbGllbnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2Vj dXJlIGNvbm5lY3Rpb24gdG8NCj4+ID5leGFtcGxlLm9yZyAyLiBUaGUgY2xpZW50IHJlcXVlc3Rz IGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlDQo+PiA+ICAgIC9wYXRoL3RvL3Jlc291 cmNlIGJ5IHNlbmRpbmcgYSBHRVQgcmVxdWVzdCBtZXNzYWdlIDMuIFRoZSBvcmlnaW4NCj4+ID5z ZXJ2ZXIgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlIHRvIHRo ZSBjbGllbnQNCj4+IA0KPj4gVGhlIHJlc291cmNlIGhvc3QgKG9yaWdpbiBzZXJ2ZXIpIGFuZCB0 aGUgY2xpZW50IG11dHVhbGx5IGF1dGhlbnRpY2F0ZXMNCj4+YW5kDQo+PiBwcm90ZWN0IHRoZSBy ZXF1ZXN0L3Jlc3BvbnNlIHVzaW5nIHRoZSBzZWN1cmUgY29ubmVjdGlvbi4NCj4+IA0KPj4gPg0K Pj4gPkV4YW1wbGUgMjogQ2xpZW50LS0tUmV2ZXJzZSBQcm94eVtleGFtcGxlLm9yZ10tLS1Pcmln aW4NCj4+ID5TZXJ2ZXJbZXhhbXBsZS5uZXRdDQo+PiA+DQo+PiA+MS4gVGhlIGNsaWVudCByZXNv bHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbiB0bw0KPj4gPmV4YW1wbGUu b3JnIDIuIFRoZSBjbGllbnQgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzb3Vy Y2UNCj4+ID4vcGF0aC90by9yZXNvdXJjZSAzLiBUaGUgcmV2ZXJzZSBwcm94eSBjaG9vc2VzIHRv IHNhdGlzZnkgdGhlIHJlcXVlc3QNCj4+YnkNCj4+IG9idGFpbmluZyB0aGUNCj4+ID4gICAgcmVw cmVzZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVz b3VyY2UNCj4+ID4gICAgYS4gVGhlIHJldmVyc2UgcHJveHkgcmVzb2x2ZXMgYW5kIGVzdGFibGlz aGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24NCj4+ID4gICAgICAgIHRvIGV4YW1wbGUubmV0DQo+PiA+ ICAgIGIuIFRoZSByZXZlcnNlIHByb3h5IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhl IHJlc291cmNlDQo+PiA+ICAgICAgICAvc29tZS9vdGhlci9yZXNvdXJjZQ0KPj4gPiAgICBjLiBU aGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhlIHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2Fs IGZpbGUNCj4+ID4gICAgICAgIHRvIHRoZSByZXZlcnNlIHByb3h5DQo+PiA+NC4gVGhlIHJldmVy c2UgcHJveGllcyBzZXJ2ZXMgdGhlIHJlcHJlc2VudGF0aW9uIHRvIHRoZSBjbGllbnQNCj4+IA0K Pj4gSW4gdGhpcyBjYXNlLCB0aGUgcmVxdWVzdGVkIHJlc291cmNlLCBmcm9tIHRoZSBwb2ludCBv ZiB2aWV3IG9mIHRoZQ0KPj5jbGllbnQsIGlzDQo+PiBob3N0ZWQgYnkgdGhlIHJldmVyc2UgcHJv eHksIGJldHdlZW4gd2hpY2ggdGhlcmUgY2FuIGJlIG11dHVhbA0KPj4gYXV0aGVudGljYXRpb24g YW5kIHNlY3VyZSBjb25uZWN0aW9uLiBXaGVyZSB0aGUgcmV2ZXJzZSBwcm94eSBnZXRzIGENCj4+ IHJlcHJlc2VudGF0aW9uIGZyb20gaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBjbGllbnQuDQo+PiAN Cj4+IA0KPj4gPg0KPj4gPkV4YW1wbGUgMzogQ2xpZW50LS0tRm9yd2FyZCBQcm94eVtwcm94eS5l eGFtcGxlXS0tLU9yaWdpbg0KPj4gPlNlcnZlcltleGFtcGxlLm9yZ10NCj4+ID4NCj4+ID4xLiBU aGUgY2xpZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25uZWN0aW9uIHRv DQo+PiA+cHJveHkuZXhhbXBsZSAyLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRp b24gb2YgdGhlIHJlc291cmNlDQo+PiA+ICAgIHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm9yZy9w YXRoL3RvL3Jlc291cmNlDQo+PiA+My4gVGhlIGZvcndhcmQgcHJveHkgc2F0aXNmaWVzIHRoZSBy ZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUNCj4+ID4gICAgcmVwcmVzZW50YXRpb24gb2Yge2NvYXBz LGh0dHBzfTovL2V4YW1wbGUub3JnL3BhdGgvdG8vcmVzb3VyY2UNCj4+ID4gICAgYS4gVGhlIGZv cndhcmQgcHJveHkgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24N Cj4+ID4gICAgICAgIHRvIGV4YW1wbGUub3JnDQo+PiA+ICAgIGIuIFRoZSBmb3J3YXJkIHByb3h5 IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlDQo+PiA+ICAgICAgICAv cGF0aC90by9yZXNvdXJjZQ0KPj4gPiAgICBjLiBUaGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMg dGhlIHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2FsIGZpbGUNCj4+ID4gICAgICAgIHRvIHRoZSBm b3J3YXJkIHByb3h5DQo+PiA+NC4gVGhlIGZvcndhcmQgcHJveHkgc2VydmVzIHRoZSByZXByZXNl bnRhdGlvbiB0byB0aGUgY2xpZW50DQo+PiANCj4+IEluIHRoaXMgY2FzZSwgdGhlIGZvcndhcmQg cHJveHkgYW5kIGNsaWVudCBtdXR1YWxseSBhdXRoZW50aWNhdGVzIGFuZA0KPj5lc3RhYmxpc2gN Cj4+IHNlY3VyZSBjb25uZWN0aW9uLCBhcyBkb2VzIGZvcndhcmQgcHJveHkgYW5kIHJlc291cmNl IGhvc3QgKG9yaWdpbg0KPj5zZXJ2ZXIpLg0KPj4gV2l0aCB0aGUgbWVjaGFuaXNtcyBkZXNjcmli ZWQgaW4gdGhpcyBleGFtcGxlLCB0aGUgcmVzb3VyY2UgaG9zdCBkb2VzDQo+Pm5vdA0KPj4gYXV0 aGVudGljYXRlIHRoZSBjbGllbnQsIHNvIHNvbWUgYWRkaXRpb25hbCBzZWN1cml0eSBpcyBuZWVk ZWQgZm9yIHRoZQ0KPj5vcmlnaW4NCj4+IHNlcnZlciB0byBlbmZvcmNlIGFuIGFjY2VzcyBjb250 cm9sIGRlY2lzaW9uIG9yIGV2YWx1YXRlIGFuIGFjY2Vzcw0KPj5jb250cm9sDQo+PiBwb2xpY3kg d2hpY2ggaXMgYm91bmQgdG8gYSBwYXJ0aWN1bGFyIGNsaWVudCAob3Igcm9sZSBvZiBjbGllbnQp Lg0KPj4gDQo+PiBUaGVyZSBhcmUgb2YgY291cnNlIHNvbHV0aW9ucyB0byB0aGlzIHByb2JsZW0s IGJ1dCB0aGUgaW1wb3J0YW50IHRoaW5nDQo+PmF0IHRoaXMNCj4+IHN0YWdlIGlzIHRoYXQgZm9y d2FyZCBwcm94aWVzIGhhcyBhbiBpbXBhY3Qgb24gdGhlIHNvbHV0aW9uLiBJZiB3ZSB3YW50DQo+ PnRvDQo+PiBzdXBwb3J0IGZvcndhcmQgcHJveGllcywgZXZlbnR1YWxseSwgdGhlbiB3ZSBzaG91 bGQgbm90IHBvc3Rwb25lIHRoaXMNCj4+dG8gYQ0KPj4gbGF0ZXIgcGhhc2UsIGJlY2F1c2UgdGhl cmUgaXMgYSBnb29kIGNoYW5jZSB0aGF0IHdpbGwgcmVxdWlyZSBhDQo+PmNvbXBsZXRlbHkNCj4+ IGRpZmZlcmVudCBzb2x1dGlvbi4gSSB0aGVyZWZvcmUgcHJvcG9zZSB0aGF0IHdlIGluY2x1ZGUg c3VwcG9ydCBmb3IgdGhlDQo+PiBtZW50aW9uZWQgcHJveGllcyBpbiB0aGUgYXNzdW1wdGlvbnMu DQo+PiANCj4+IA0KPj4gPg0KPj4gPkV4YW1wbGUgNDogQ2xpZW50LS0tVHVubmVsW3R1bm5lbC5l eGFtcGxlXS0tLU9yaWdpbiBTZXJ2ZXJbZXhhbXBsZS5vcmddDQo+PiA+DQo+PiA+MS4gVGhlIGNs aWVudCByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYW4gdW5zZWN1cmVkIGNvbm5lY3Rpb24gdG8N Cj4+ID50dW5uZWwuZXhhbXBsZSAyLiBUaGUgY2xpZW50IHJlcXVlc3RzIHRoZSB0dW5uZWwgdG8g ZXN0YWJsaXNoIGFuDQo+PiA+dW5zZWN1cmVkIGNvbm5lY3Rpb24NCj4+ID4gICAgdG8gZXhhbXBs ZS5vcmcgYW5kIHRvIGFjdCBhcyBhIGJsaW5kIHJlbGF5IGJldHdlZW4gdGhlIHR3bw0KPj4gPmNv bm5lY3Rpb25zIDMuIFRoZSB0dW5uZWwgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHJlc29sdmlu ZyBhbmQNCj4+ZXN0YWJsaXNoaW5nDQo+PiBhbg0KPj4gPiAgICB1bnNlY3VyZWQgY29ubmVjdGlv biB0byBleGFtcGxlLm9yZyA0LiBUaGUgY2xpZW50IGVzdGFibGlzaGVzIGENCj4+ID5zZWN1cmUg Y29ubmVjdGlvbiB0byB0aGUgb3JpZ2luIHNlcnZlcg0KPj4gPiAgICB0aHJvdWdoIHRoZSB0dW5u ZWwNCj4+ID41LiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJl c291cmNlDQo+PiA+L3BhdGgvdG8vcmVzb3VyY2UgNi4gVGhlIG9yaWdpbiBzZXJ2ZXIgc2F0aXNm aWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcNCj4+ID5hIGxvY2FsIGZpbGUgdG8gdGhlIGNsaWVu dA0KPj4gDQo+PiBJbiB0aGlzIGNhc2UgY2xpZW50IGFuZCByZXNvdXJjZSBob3N0IG11dHVhbGx5 IGF1dGhlbnRpY2F0ZXMgYW5kDQo+PmVzdGFibGlzaGVzDQo+PiB0aGUgZW5kLXRvLWVuZCBzZWN1 cmUgY29ubmVjdGlvbiBpbiBzdGVwIDQuIFNpbWlsYXIgdG8gZXhhbXBsZXMgMSBhbmQgMi4NCj4+ IA0KPj4gDQo+PiBHw7ZyYW4NCj4+IA0KPj4gDQo+PiA+DQo+PiA+RG9lcyB0aGF0IGFuc3dlciB5 b3VyIHF1ZXN0aW9ucz8NCj4+ID4NCj4+ID5LbGF1cw0KPj4gPg0KPj4gPg0KPj4gPk9uIDI1IE1h cmNoIDIwMTQgMDk6NDcsIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0Pg0KPj4gPndyb3RlOg0KPj4gPj4gSGkgS2xhdXMsDQo+PiA+Pg0KPj4gPj4gdGhhbmtzIGZv ciB0aGUgZGVzY3JpcHRpb24uIFNpbmNlIEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0b29kIGl0DQo+ PiA+PiBjb3JyZWN0bHkgSSBoYXZlIGEgY291cGxlIG9mIGJhc2ljIHF1ZXN0aW9ucy4NCj4+ID4+ DQo+PiA+PiBPbiAwMy8yNC8yMDE0IDA4OjUwIFBNLCBLbGF1cyBIYXJ0a2Ugd3JvdGU6DQo+PiA+ Pj4gQ29BUCBwcm92aWRlcyB0d28gKHN5bnRhY3RpY2FsbHkgZGlmZmVyZW50KSB3YXlzIGZvciBh IGNsaWVudCAob3INCj4+ID4+PiBpbnRlcm1lZGlhcnkgaW4gdGhlIHJvbGUgb2YgYSBjbGllbnQp IHRvIHBlcmZvcm0gYSByZXF1ZXN0Og0KPj4gPj4+IChJJ20gdXNpbmcgcmVwcmVzZW50YXRpb24g cmV0cmlldmFsIGFzIGV4YW1wbGUgV09MT0cuKQ0KPj4gPj4+DQo+PiA+Pj4gQS4pIHRoZSBjbGll bnQgcmVxdWVzdHMgYSByZW1vdGUgZW5kcG9pbnQgdG8gcmV0dXJuIGEgcmVwcmVzZW50YXRpb24N Cj4+ID4+PiBvZiBhIHJlc291cmNlIGxvY2F0ZWQgX2luIHRoYXQgZW5kcG9pbnQncyBuYW1lc3Bh Y2VfLg0KPj4gPj4+DQo+PiA+Pj4gQi4pIHRoZSBjbGllbnQgcmVxdWVzdHMgYSByZW1vdGUgZW5k cG9pbnQgdG8gcmV0dXJuIGEgcmVwcmVzZW50YXRpb24NCj4+ID4+PiBvZiBhIHJlc291cmNlIGxv Y2F0ZWQgX2luIGFub3RoZXIgZW5kcG9pbnQncyBuYW1lc3BhY2VfLg0KPj4gPj4NCj4+ID4+IFRo ZSBjbGllbnQgZGV2aWNlIHdpbGwgc3RhcnQgd2l0aCBhIHNwZWNpZmljIEZRRE4gYW5kIHdpbGwg c3RhcnQgYQ0KPj4gPj4gRFRMUyBoYW5kc2hha2Ugd2l0aCB0aGF0IHNlcnZlci4gV2hlcmUgZG9l cyB0aGUgInJlcXVlc3RzIGEgcmVtb3RlDQo+PiA+PiBlbmRwb2ludCB0byByZXR1cm4gLi4uLiIg Y29tZSBpbnRvIHRoZSBwbGF5Pw0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4+DQo+PiA+Pj4g SW4gYm90aCBjYXNlcywgaXQncyBnZW5lcmFsbHkgdXAgdG8gdGhlIHJlbW90ZSBlbmRwb2ludCBo b3cgaXQNCj4+ID4+PiBvYnRhaW5zIHRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdGFyZ2V0IHJl c291cmNlLCBhcyBsb25nIGFzIHRoZQ0KPj4gPj4+IHJlc3VsdCAqaXMqIGEgcmVwcmVzZW50YXRp b24gb2YgdGhlIHRhcmdldCByZXNvdXJjZS4NCj4+ID4+PiBGb3IgZXhhbXBsZSwgaW4gQS4sIHRo ZSByZW1vdGUgZW5kcG9pbnQgY2FuIHNlcnZlIGEgbG9jYWwgZmlsZSAodGhlDQo+PiA+Pj4gZW5k cG9pbnQgaXMgdGhlbiB0eXBpY2FsbHkgY2FsbGVkIGEgInNlcnZlciIpLCByZXR1cm4gdGhlIG91 dHB1dCBvZg0KPj4gPj4+IGEgQ0dJIHNjcmlwdCAoIkNHSSBnYXRld2F5IiksIG9idGFpbiB0aGUg cmVwcmVzZW50YXRpb24gZnJvbSBhbiBIVFRQDQo+PiA+Pj4gc2VydmVyICgiY3Jvc3MtcHJvdG9j b2wgcHJveHkiKSwgb3Igb2J0YWluIHRoZSByZXByZXNlbnRhdGlvbiBmcm9tDQo+PiA+Pj4gYW5v dGhlciBDb0FQIHJlbW90ZSBlbmRwb2ludCAoInJldmVyc2UgcHJveHkiKS4gSW4gQi4sIHRoZSBy ZW1vdGUNCj4+ID4+PiBlbmRwb2ludCBpcyBnZW5lcmFsbHkgZXhwZWN0ZWQgdG8gb2J0YWluIHRo ZSByZXByZXNlbnRhdGlvbiBieQ0KPj4gPj4+IHJlcXVlc3RpbmcgaXQgZnJvbSB0aGUgZW5kcG9p bnQgc3BlY2lmaWVkIGluIHRoZSByZXF1ZXN0IFVSSQ0KPj4gPj4+ICgiZm9yd2FyZCBwcm94eSIp Lg0KPj4gPj4+DQo+PiA+Pj4gSW4gYm90aCBjYXNlcywgdGhlIGNsaWVudCBoYXMgbm8gd2F5IHRv IHZlcmlmeSB0aGF0IHRoZSBvYnRhaW5lZA0KPj4gPj4+IHJlc3VsdCBpcyBpbmRlZWQgYSByZXBy ZXNlbnRhdGlvbiBvZiB0aGUgdGFyZ2V0IHJlc291cmNlLiBJdCBtdXN0DQo+PiA+Pj4gdHJ1c3Qg dGhlIHJlbW90ZSBlbmRwb2ludCB0aGF0IGl0IHJldHVybnMgdGhlIGNvcnJlY3QNCj4+cmVwcmVz ZW50YXRpb24uDQo+PiA+Pj4gRFRMUyBqdXN0IHNlY3VyZXMgdGhlIHRyYW5zbWlzc2lvbiBvZiB0 aGUgcmVwcmVzZW50YXRpb24gZnJvbSB0aGUNCj4+ID4+PiByZW1vdGUgZW5kcG9pbnQgdG8gdGhl IGNsaWVudC4NCj4+ID4+Pg0KPj4gPj4+IChBRkFJSywgSFRUUCB3b3JrcyBleGFjdGx5IHRoZSBz YW1lIHdheS4pDQo+PiA+Pg0KPj4gPj4gSW4gdGhlIEhUVFBTIGNhc2UgdGhlIHN0b3J5IGlzIGFz IGZvbGxvd3M6DQo+PiA+Pg0KPj4gPj4gKiBUaGUgY2xpZW50IGNvbnRhY3RzIHRoZSBzZXJ2ZXIg YmVoaW5kIGEgaHR0cHM6Ly93d3cuaWV0Zi5vcmcgKGFmdGVyDQo+PiA+PiBkb2luZyBhIEROUyBs b29rLXVwKSB1c2luZyBUTFMuDQo+PiA+Pg0KPj4gPj4gKiBJdCBnZXRzIHRoZSBjZXJ0IGZyb20g dGhlIHNlcnZlci4NCj4+ID4+DQo+PiA+PiAqIFRoZSBjbGllbnQgY29tcGFyZXMgdGhlIGNvbnRl bnQgb2YgdGhlIGNlcnQgd2l0aCB3aGF0IGl0IGhhZA0KPj4gPj4gaW5pdGlhbGx5IHJlcXVlc3Rl ZCB0byBlbnN1cmUgaXQgdGFsa3MgdG8gdGhlIHJpZ2h0IHNlcnZlci4NCj4+ID4+DQo+PiA+PiBU aGUgVExTIHdpbGwgcHJldmVudCBhbnkgcHJveHkgYWxvbmcgdGhlIHBhdGggdG8gY2FjaGUgdGhl IGRhdGENCj4+ID4+IChzaW5jZSBpdCBpcyBlbmNyeXB0ZWQpLg0KPj4gPj4NCj4+ID4+IFNvLCBJ IGFtIG5vdCBzdXJlIGhvdyB0aGlzIGNvbXBhcmVzIHRvIENvQVAgYmFzZWQgb24geW91cg0KPj5k ZXNjcmlwdGlvbi4NCj4+ID4+DQo+PiA+PiBDaWFvDQo+PiA+PiBIYW5uZXMNCj4+ID4+DQo+PiA+ Pg0KPj4gPj4+DQo+PiA+Pj4gU28sIEkgd291bGQgc2F5IHRoYXQNCj4+ID4+Pg0KPj4gPj4+IC0g QUNFIHNob3VsZCBjb25zaWRlciBmb3J3YXJkIHByb3hpZXMsIHJldmVyc2UgcHJveGllcyBhbmQN Cj4+ID4+PiBwb3RlbnRpYWxseSBjcm9zcy1wcm90b2NvbCBwcm94aWVzIHN1Y2ggdGhhdCBvbmUg b2YgdGhlc2UgY2FuIG9idGFpbg0KPj4gPj4+IGEgcmVwcmVzZW50YXRpb24gb2YgYSByZXNvdXJj ZSB0aGF0IGEgY2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gYWNjZXNzDQo+PiA+Pj4gb24gYmVoYWxm IG9mIHRoYXQgY2xpZW50OyBhbmQNCj4+ID4+Pg0KPj4gPj4+IC0gQUNFIHNob3VsZCBub3QgY29u c2lkZXIgcmVtb3RlIGVuZHBvaW50cyB0aGF0IGNhbm5vdCBiZSB0cnVzdGVkIHRvDQo+PiA+Pj4g Y29ycmVjdGx5IHJldHVybiBhIHJlcHJlc2VudGF0aW9uIG9mIGEgdGFyZ2V0IHJlc291cmNlIChh cyB0aGlzDQo+PiA+Pj4gY29uY2VybnMgdGhlIGdlbmVyYWwgc2VjdXJpdHkgb2YgQ29BUCB3aGlj aCBzaG91bGQgYmUgYWRkcmVzc2VkIGluDQo+PiA+Pj4gQ29SRSkuDQo+PiA+Pj4NCj4+ID4+PiBL bGF1cw0KPj4gPg0KPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+QWNlIG1haWxpbmcgbGlzdA0KPj4gPkFjZUBpZXRmLm9yZw0KPj4gPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+PiANCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBY2UgbWFpbGluZyBsaXN0 DQo+PiBBY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYWNlDQoNCg== From nobody Fri Mar 28 01:40:04 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBA01A0869 for ; Fri, 28 Mar 2014 01:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKWGnEdreqtF for ; Fri, 28 Mar 2014 01:39:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC861A01F0 for ; Fri, 28 Mar 2014 01:39:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFA21347; Fri, 28 Mar 2014 08:39:51 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 08:39:06 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 08:39:35 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 28 Mar 2014 16:39:30 +0800 From: Likepeng To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Klaus Hartke" , "Ace@ietf.org" Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyGaZCy7gapW0iSUYgVT5QsOJru9ZoA///keQCAAMpVgIAAOAQAgAAhv4CAACJhAIAA2T4AgABkuICAAxfMAIABnVig//+Y1wCAAIa+MA== Date: Fri, 28 Mar 2014 08:39:29 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B0B4@SZXEMA501-MBS.china.huawei.com> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B049@SZXEMA501-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/2i8Xrks41GH5n84oaG-vAgavrB8 Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 08:40:00 -0000 PmhhdmluZyBhIGRyYWZ0IChhcyBpbiB0aGUgZXhhbXBsZSBvZiB0aGUgdXNlIGNhc2UgYW5kIHJl cXVpcmVtZW50cykgaXMgYSBwcm9ibGVtLg0KDQpOb3QgcmVhbGx5LiANCg0KVXNlIGNhc2VzIGFu ZCByZXF1aXJlbWVudHMgZHJhZnQgaXMgYSBnb29kIG9uZS4gDQoNCkluIGZhY3QsIGl0IGdvdCBh IGxvdCBvZiBpbnRlcmVzdCwgaGFzIGJlZW4gcmVmZXJlbmNlZCBzZXZlcmFsIHRpbWVzIGluIHRo ZSBtYWlsaW5nIGxpc3QgYW5kIGhlbHAgdXMgYSBsb3QgZHVyaW5nIHRoZSBkaXNjdXNzaW9uLg0K DQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R 5Lu25Lq6OiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5j b21dDQo+IOWPkemAgeaXtumXtDogMjAxNOW5tDPmnIgyOOaXpSAxNjozMg0KPiDmlLbku7bkuro6 IExpa2VwZW5nOyBLbGF1cyBIYXJ0a2U7IEFjZUBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbQWNl XSBTdW1tYXJ5IG9mIHRoZSBQcm94eSBEaXNjdXNzaW9uDQo+IA0KPiANCj4gDQo+IE9uIDI4LzAz LzE0IDA4OjI5LCAiTGlrZXBlbmciIDxsaWtlcGVuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+ ID4+IFRoZXJlIGFyZSBvZiBjb3Vyc2Ugc29sdXRpb25zIHRvIHRoaXMgcHJvYmxlbSwgYnV0IHRo ZSBpbXBvcnRhbnQNCj4gPj50aGluZyBhdCB0aGlzICBzdGFnZSBpcyB0aGF0IGZvcndhcmQgcHJv eGllcyBoYXMgYW4gaW1wYWN0IG9uIHRoZQ0KPiA+PnNvbHV0aW9uLiBJZiB3ZSB3YW50IHRvICBz dXBwb3J0IGZvcndhcmQgcHJveGllcywgZXZlbnR1YWxseSwgdGhlbiB3ZQ0KPiA+PnNob3VsZCBu b3QgcG9zdHBvbmUgdGhpcyB0byBhICBsYXRlciBwaGFzZSwgYmVjYXVzZSB0aGVyZSBpcyBhIGdv b2QNCj4gPj5jaGFuY2UgdGhhdCB3aWxsIHJlcXVpcmUgYSBjb21wbGV0ZWx5ICBkaWZmZXJlbnQg c29sdXRpb24uIEkgdGhlcmVmb3JlDQo+ID4+cHJvcG9zZSB0aGF0IHdlIGluY2x1ZGUgc3VwcG9y dCBmb3IgdGhlICBtZW50aW9uZWQgcHJveGllcyBpbiB0aGUNCj4gPj5hc3N1bXB0aW9ucy4NCj4g Pg0KPiA+SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBjb25zaWRlciB0aGUgcmVxdWlyZW1lbnRzIGZv ciB0aGUgcHJveHkgc3VwcG9ydA0KPiA+d2hlbiB3ZSBkZXNpZ24gb3VyIHNvbHV0aW9uLg0KPiA+ DQo+ID5CdXQgSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gZGVzaWduIG91ciBzb2x1dGlvbiBzdGVw IGJ5IHN0ZXAsIGluDQo+ID5kaWZmZXJlbnQgcGhhc2VzLg0KPiA+DQo+ID5NeSB3b3JyeSBpcywg cHJveHkgaXMgcXVpdGUgY29tcGxleCB0byBzdXBwb3J0LCB0aGlzIG1heSBkZWxheSBvdXINCj4g PnByb2dyZXNzIHRvIGZpbmlzaCBvdXIgYmFzaWMgc29sdXRpb24uDQo+ID4NCj4gPkFsc28gd2Ug ZG9u4oCZdCBoYXZlIGRyYWZ0cyBhdmFpbGFibGUgeWV0LCBJIGFtIG5vdCBzdXJlIHdobyBjYW4g bGVhZA0KPiA+dGhpcyB3b3JrLCBhbmQgaG93IGxvbmcgaXQgd2lsbCB0YWtlLg0KPiANCj4gSSB0 aGluayB0aGUgbWFpbCBleGNoYW5nZSBpcyBhIGdvb2Qgc3RhcnQgZm9yIGEgcHJvYmxlbSBzdGF0 ZW1lbnQgYW5kIHRlbnRhdGl2ZQ0KPiByZXF1aXJlbWVudHMgKGFsdGhvdWdoIEkgZG9u4oCZdCBl eGFjdGx5IGFncmVlIHdpdGggdGhlIGN1cnJlbnQgZm9ybXVsYXRpb24pLg0KPiBKdWRnaW5nIGJ5 IHRoZSBlbnRodXNpYXNtIG9mIHZvbHVudGVlcnMgcG9wcGluZyB1cCBJIGRvbuKAmXQgdGhpbmsg aXQgd2lsbCBiZQ0KPiBkaWZmaWN1bHQgdG8gZmluZCBhIGRyaXZlciBmb3IgdGhpcyB3b3JrIDst KQ0KPiANCj4gSnVzdCBhcyBhIG5vdGUgZnJvbSBhIGJlZ2lubmVyOiBJdCBpcyBhIGJpdCBwdXp6 bGluZyB0byBtZSwgdGhhdCBvbiB0aGUgb25lIGhhbmQNCj4gc2lkZSBoYXZpbmcgYSBkcmFmdCAo YXMgaW4gdGhlIGV4YW1wbGUgb2YgdGhlIHVzZSBjYXNlIGFuZA0KPiByZXF1aXJlbWVudHMpIGlz IGEgcHJvYmxlbSBhbmQgbm90IGhhdmluZyBhIGRyYWZ0IChhcyBpbiB0aGUgY3VycmVudA0KPiBl eGFtcGxlKSBpcyBhbHNvIGEgcHJvYmxlbSA6LSkNCj4gDQo+IA0KPiBHw7ZyYW4NCj4gDQo+IA0K PiA+DQo+ID5LaW5kIFJlZ2FyZHMNCj4gPktlcGVuZw0KPiA+DQo+ID4+IC0tLS0t6YKu5Lu25Y6f 5Lu2LS0tLS0NCj4gPj4g5Y+R5Lu25Lq6OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIEc/cmFuIFNlbGFuZGVyDQo+ID4+IOWPkemAgeaXtumXtDogMjAxNOW5tDPmnIgy N+aXpSAyMjowMg0KPiA+PiDmlLbku7bkuro6IEtsYXVzIEhhcnRrZTsgQWNlQGlldGYub3JnDQo+ ID4+IOS4u+mimDogUmU6IFtBY2VdIFN1bW1hcnkgb2YgdGhlIFByb3h5IERpc2N1c3Npb24NCj4g Pj4NCj4gPj4gSGkgS2xhdXMNCj4gPj4NCj4gPj4gVGhhbmtzIGZvciB0aGVzZSBleHBsaWNpdCBl eGFtcGxlcy4gSSBiZWxpZXZlIGV4YW1wbGUgMyAtIHRoZSBmb3J3YXJkDQo+ID4+cHJveHkgLSBp cyAgZGlmZmVyZW50IGZyb20gdGhlIG90aGVycyB3aXRoIHJlc3BlY3QgdG8gZW5kLXRvLWVuZA0K PiA+PnNlY3VyaXR5IGJldHdlZW4gY2xpZW50ICBhbmQgcmVxdWVzdGVkIHJlc291cmNlLiBJIHRo aW5rIHRoYXQgaGFzIGFuDQo+ID4+aW1wYWN0IG9uIHRoZSBzb2x1dGlvbiBzbyB3ZSAgc2hvdWxk IGV4cGxpY2l0bHkgY29uc2lkZXIgdGhlc2UNCj4gPj5leGFtcGxlcyBpbiB0aGUgd29yay4gU2Vl IGNvbW1lbnRzIGlubGluZS4NCj4gPj4NCj4gPj4NCj4gPj4gT24gMjUvMDMvMTQgMTU6NDgsICJL bGF1cyBIYXJ0a2UiIDxoYXJ0a2VAdHppLm9yZz4gd3JvdGU6DQo+ID4+DQo+ID4+ID5IaSBIYW5u ZXMsDQo+ID4+ID4NCj4gPj4gPmhlcmUgYXJlIGEgZmV3IGV4YW1wbGVzLiBJbiBlYWNoIGV4YW1w bGUsIHRoZSBjbGllbnQgd2FudHMgdG8gb2J0YWluDQo+ID4+ID5hIHJlcHJlc2VudGF0aW9uIG9m IHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm9yZy9wYXRoL3RvL3Jlc291cmNlLg0KPiA+PiA+QWxs IGV4YW1wbGVzIHdvcmsgZm9yIGJvdGggQ29BUCBhbmQgSFRUUCwgZXhjZXB0IGZvciB0aGUgbGFz dCB3aGljaA0KPiA+PiA+b25seSB3b3JrcyBmb3IgSFRUUC4NCj4gPj4gPg0KPiA+PiA+RXhhbXBs ZSAxOiBDbGllbnQtLS1PcmlnaW4gU2VydmVyW2V4YW1wbGUub3JnXQ0KPiA+PiA+DQo+ID4+ID4x LiBUaGUgY2xpZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25uZWN0aW9u IHRvDQo+ID4+ID5leGFtcGxlLm9yZyAyLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50 YXRpb24gb2YgdGhlIHJlc291cmNlDQo+ID4+ID4gICAgL3BhdGgvdG8vcmVzb3VyY2UgYnkgc2Vu ZGluZyBhIEdFVCByZXF1ZXN0IG1lc3NhZ2UgMy4gVGhlIG9yaWdpbg0KPiA+PiA+c2VydmVyIHNh dGlzZmllcyB0aGUgcmVxdWVzdCBieSBzZXJ2aW5nIGEgbG9jYWwgZmlsZSB0byB0aGUgY2xpZW50 DQo+ID4+DQo+ID4+IFRoZSByZXNvdXJjZSBob3N0IChvcmlnaW4gc2VydmVyKSBhbmQgdGhlIGNs aWVudCBtdXR1YWxseQ0KPiA+PmF1dGhlbnRpY2F0ZXMgYW5kICBwcm90ZWN0IHRoZSByZXF1ZXN0 L3Jlc3BvbnNlIHVzaW5nIHRoZSBzZWN1cmUNCj4gPj5jb25uZWN0aW9uLg0KPiA+Pg0KPiA+PiA+ DQo+ID4+ID5FeGFtcGxlIDI6IENsaWVudC0tLVJldmVyc2UgUHJveHlbZXhhbXBsZS5vcmddLS0t T3JpZ2luDQo+ID4+ID5TZXJ2ZXJbZXhhbXBsZS5uZXRdDQo+ID4+ID4NCj4gPj4gPjEuIFRoZSBj bGllbnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24gdG8NCj4g Pj4gPmV4YW1wbGUub3JnIDIuIFRoZSBjbGllbnQgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBv ZiB0aGUgcmVzb3VyY2UNCj4gPj4gPi9wYXRoL3RvL3Jlc291cmNlIDMuIFRoZSByZXZlcnNlIHBy b3h5IGNob29zZXMgdG8gc2F0aXNmeSB0aGUNCj4gPj4gPnJlcXVlc3QNCj4gPj5ieQ0KPiA+PiBv YnRhaW5pbmcgdGhlDQo+ID4+ID4gICAgcmVwcmVzZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTov L2V4YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVzb3VyY2UNCj4gPj4gPiAgICBhLiBUaGUgcmV2ZXJz ZSBwcm94eSByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbg0KPiA+ PiA+ICAgICAgICB0byBleGFtcGxlLm5ldA0KPiA+PiA+ICAgIGIuIFRoZSByZXZlcnNlIHByb3h5 IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlDQo+ID4+ID4gICAgICAg IC9zb21lL290aGVyL3Jlc291cmNlDQo+ID4+ID4gICAgYy4gVGhlIG9yaWdpbiBzZXJ2ZXIgc2F0 aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlDQo+ID4+ID4gICAgICAg IHRvIHRoZSByZXZlcnNlIHByb3h5DQo+ID4+ID40LiBUaGUgcmV2ZXJzZSBwcm94aWVzIHNlcnZl cyB0aGUgcmVwcmVzZW50YXRpb24gdG8gdGhlIGNsaWVudA0KPiA+Pg0KPiA+PiBJbiB0aGlzIGNh c2UsIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UsIGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhl DQo+ID4+Y2xpZW50LCBpcyAgaG9zdGVkIGJ5IHRoZSByZXZlcnNlIHByb3h5LCBiZXR3ZWVuIHdo aWNoIHRoZXJlIGNhbiBiZQ0KPiA+Pm11dHVhbCAgYXV0aGVudGljYXRpb24gYW5kIHNlY3VyZSBj b25uZWN0aW9uLiBXaGVyZSB0aGUgcmV2ZXJzZSBwcm94eQ0KPiA+PmdldHMgYSAgcmVwcmVzZW50 YXRpb24gZnJvbSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGNsaWVudC4NCj4gPj4NCj4gPj4NCj4g Pj4gPg0KPiA+PiA+RXhhbXBsZSAzOiBDbGllbnQtLS1Gb3J3YXJkIFByb3h5W3Byb3h5LmV4YW1w bGVdLS0tT3JpZ2luDQo+ID4+ID5TZXJ2ZXJbZXhhbXBsZS5vcmddDQo+ID4+ID4NCj4gPj4gPjEu IFRoZSBjbGllbnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24g dG8NCj4gPj4gPnByb3h5LmV4YW1wbGUgMi4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSByZXNvdXJjZQ0KPiA+PiA+ICAgIHtjb2FwcyxodHRwc306Ly9leGFtcGxl Lm9yZy9wYXRoL3RvL3Jlc291cmNlDQo+ID4+ID4zLiBUaGUgZm9yd2FyZCBwcm94eSBzYXRpc2Zp ZXMgdGhlIHJlcXVlc3QgYnkgb2J0YWluaW5nIHRoZQ0KPiA+PiA+ICAgIHJlcHJlc2VudGF0aW9u IG9mIHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm9yZy9wYXRoL3RvL3Jlc291cmNlDQo+ID4+ID4g ICAgYS4gVGhlIGZvcndhcmQgcHJveHkgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJl IGNvbm5lY3Rpb24NCj4gPj4gPiAgICAgICAgdG8gZXhhbXBsZS5vcmcNCj4gPj4gPiAgICBiLiBU aGUgZm9yd2FyZCBwcm94eSByZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJj ZQ0KPiA+PiA+ICAgICAgICAvcGF0aC90by9yZXNvdXJjZQ0KPiA+PiA+ICAgIGMuIFRoZSBvcmln aW4gc2VydmVyIHNhdGlzZmllcyB0aGUgcmVxdWVzdCBieSBzZXJ2aW5nIGEgbG9jYWwgZmlsZQ0K PiA+PiA+ICAgICAgICB0byB0aGUgZm9yd2FyZCBwcm94eQ0KPiA+PiA+NC4gVGhlIGZvcndhcmQg cHJveHkgc2VydmVzIHRoZSByZXByZXNlbnRhdGlvbiB0byB0aGUgY2xpZW50DQo+ID4+DQo+ID4+ IEluIHRoaXMgY2FzZSwgdGhlIGZvcndhcmQgcHJveHkgYW5kIGNsaWVudCBtdXR1YWxseSBhdXRo ZW50aWNhdGVzIGFuZA0KPiA+PmVzdGFibGlzaCAgc2VjdXJlIGNvbm5lY3Rpb24sIGFzIGRvZXMg Zm9yd2FyZCBwcm94eSBhbmQgcmVzb3VyY2UgaG9zdA0KPiA+PihvcmlnaW4gc2VydmVyKS4NCj4g Pj4gV2l0aCB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhpcyBleGFtcGxlLCB0aGUgcmVz b3VyY2UgaG9zdCBkb2VzDQo+ID4+bm90ICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgc28gc29t ZSBhZGRpdGlvbmFsIHNlY3VyaXR5IGlzIG5lZWRlZA0KPiA+PmZvciB0aGUgb3JpZ2luICBzZXJ2 ZXIgdG8gZW5mb3JjZSBhbiBhY2Nlc3MgY29udHJvbCBkZWNpc2lvbiBvcg0KPiA+PmV2YWx1YXRl IGFuIGFjY2VzcyBjb250cm9sICBwb2xpY3kgd2hpY2ggaXMgYm91bmQgdG8gYSBwYXJ0aWN1bGFy DQo+ID4+Y2xpZW50IChvciByb2xlIG9mIGNsaWVudCkuDQo+ID4+DQo+ID4+IFRoZXJlIGFyZSBv ZiBjb3Vyc2Ugc29sdXRpb25zIHRvIHRoaXMgcHJvYmxlbSwgYnV0IHRoZSBpbXBvcnRhbnQNCj4g Pj50aGluZyBhdCB0aGlzICBzdGFnZSBpcyB0aGF0IGZvcndhcmQgcHJveGllcyBoYXMgYW4gaW1w YWN0IG9uIHRoZQ0KPiA+PnNvbHV0aW9uLiBJZiB3ZSB3YW50IHRvICBzdXBwb3J0IGZvcndhcmQg cHJveGllcywgZXZlbnR1YWxseSwgdGhlbiB3ZQ0KPiA+PnNob3VsZCBub3QgcG9zdHBvbmUgdGhp cyB0byBhICBsYXRlciBwaGFzZSwgYmVjYXVzZSB0aGVyZSBpcyBhIGdvb2QNCj4gPj5jaGFuY2Ug dGhhdCB3aWxsIHJlcXVpcmUgYSBjb21wbGV0ZWx5ICBkaWZmZXJlbnQgc29sdXRpb24uIEkgdGhl cmVmb3JlDQo+ID4+cHJvcG9zZSB0aGF0IHdlIGluY2x1ZGUgc3VwcG9ydCBmb3IgdGhlICBtZW50 aW9uZWQgcHJveGllcyBpbiB0aGUNCj4gPj5hc3N1bXB0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4g Pg0KPiA+PiA+RXhhbXBsZSA0OiBDbGllbnQtLS1UdW5uZWxbdHVubmVsLmV4YW1wbGVdLS0tT3Jp Z2luDQo+ID4+ID5TZXJ2ZXJbZXhhbXBsZS5vcmddDQo+ID4+ID4NCj4gPj4gPjEuIFRoZSBjbGll bnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGFuIHVuc2VjdXJlZCBjb25uZWN0aW9uIHRvDQo+ ID4+ID50dW5uZWwuZXhhbXBsZSAyLiBUaGUgY2xpZW50IHJlcXVlc3RzIHRoZSB0dW5uZWwgdG8g ZXN0YWJsaXNoIGFuDQo+ID4+ID51bnNlY3VyZWQgY29ubmVjdGlvbg0KPiA+PiA+ICAgIHRvIGV4 YW1wbGUub3JnIGFuZCB0byBhY3QgYXMgYSBibGluZCByZWxheSBiZXR3ZWVuIHRoZSB0d28NCj4g Pj4gPmNvbm5lY3Rpb25zIDMuIFRoZSB0dW5uZWwgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHJl c29sdmluZyBhbmQNCj4gPj5lc3RhYmxpc2hpbmcNCj4gPj4gYW4NCj4gPj4gPiAgICB1bnNlY3Vy ZWQgY29ubmVjdGlvbiB0byBleGFtcGxlLm9yZyA0LiBUaGUgY2xpZW50IGVzdGFibGlzaGVzIGEN Cj4gPj4gPnNlY3VyZSBjb25uZWN0aW9uIHRvIHRoZSBvcmlnaW4gc2VydmVyDQo+ID4+ID4gICAg dGhyb3VnaCB0aGUgdHVubmVsDQo+ID4+ID41LiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVz ZW50YXRpb24gb2YgdGhlIHJlc291cmNlDQo+ID4+ID4vcGF0aC90by9yZXNvdXJjZSA2LiBUaGUg b3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhlIHJlcXVlc3QgYnkNCj4gPj4gPnNlcnZpbmcgYSBs b2NhbCBmaWxlIHRvIHRoZSBjbGllbnQNCj4gPj4NCj4gPj4gSW4gdGhpcyBjYXNlIGNsaWVudCBh bmQgcmVzb3VyY2UgaG9zdCBtdXR1YWxseSBhdXRoZW50aWNhdGVzIGFuZA0KPiA+PmVzdGFibGlz aGVzICB0aGUgZW5kLXRvLWVuZCBzZWN1cmUgY29ubmVjdGlvbiBpbiBzdGVwIDQuIFNpbWlsYXIg dG8NCj4gPj5leGFtcGxlcyAxIGFuZCAyLg0KPiA+Pg0KPiA+Pg0KPiA+PiBHw7ZyYW4NCj4gPj4N Cj4gPj4NCj4gPj4gPg0KPiA+PiA+RG9lcyB0aGF0IGFuc3dlciB5b3VyIHF1ZXN0aW9ucz8NCj4g Pj4gPg0KPiA+PiA+S2xhdXMNCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID5PbiAyNSBNYXJjaCAyMDE0 IDA5OjQ3LCBIYW5uZXMgVHNjaG9mZW5pZw0KPiA+PiA+PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ+DQo+ID4+ID53cm90ZToNCj4gPj4gPj4gSGkgS2xhdXMsDQo+ID4+ID4+DQo+ID4+ID4+IHRo YW5rcyBmb3IgdGhlIGRlc2NyaXB0aW9uLiBTaW5jZSBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdG9v ZCBpdA0KPiA+PiA+PiBjb3JyZWN0bHkgSSBoYXZlIGEgY291cGxlIG9mIGJhc2ljIHF1ZXN0aW9u cy4NCj4gPj4gPj4NCj4gPj4gPj4gT24gMDMvMjQvMjAxNCAwODo1MCBQTSwgS2xhdXMgSGFydGtl IHdyb3RlOg0KPiA+PiA+Pj4gQ29BUCBwcm92aWRlcyB0d28gKHN5bnRhY3RpY2FsbHkgZGlmZmVy ZW50KSB3YXlzIGZvciBhIGNsaWVudCAob3INCj4gPj4gPj4+IGludGVybWVkaWFyeSBpbiB0aGUg cm9sZSBvZiBhIGNsaWVudCkgdG8gcGVyZm9ybSBhIHJlcXVlc3Q6DQo+ID4+ID4+PiAoSSdtIHVz aW5nIHJlcHJlc2VudGF0aW9uIHJldHJpZXZhbCBhcyBleGFtcGxlIFdPTE9HLikNCj4gPj4gPj4+ DQo+ID4+ID4+PiBBLikgdGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlbW90ZSBlbmRwb2ludCB0byBy ZXR1cm4gYQ0KPiA+PiA+Pj4gcmVwcmVzZW50YXRpb24gb2YgYSByZXNvdXJjZSBsb2NhdGVkIF9p biB0aGF0IGVuZHBvaW50J3MgbmFtZXNwYWNlXy4NCj4gPj4gPj4+DQo+ID4+ID4+PiBCLikgdGhl IGNsaWVudCByZXF1ZXN0cyBhIHJlbW90ZSBlbmRwb2ludCB0byByZXR1cm4gYQ0KPiA+PiA+Pj4g cmVwcmVzZW50YXRpb24gb2YgYSByZXNvdXJjZSBsb2NhdGVkIF9pbiBhbm90aGVyIGVuZHBvaW50 J3MNCj4gbmFtZXNwYWNlXy4NCj4gPj4gPj4NCj4gPj4gPj4gVGhlIGNsaWVudCBkZXZpY2Ugd2ls bCBzdGFydCB3aXRoIGEgc3BlY2lmaWMgRlFETiBhbmQgd2lsbCBzdGFydCBhDQo+ID4+ID4+IERU TFMgaGFuZHNoYWtlIHdpdGggdGhhdCBzZXJ2ZXIuIFdoZXJlIGRvZXMgdGhlICJyZXF1ZXN0cyBh IHJlbW90ZQ0KPiA+PiA+PiBlbmRwb2ludCB0byByZXR1cm4gLi4uLiIgY29tZSBpbnRvIHRoZSBw bGF5Pw0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pj4NCj4gPj4gPj4+IEluIGJv dGggY2FzZXMsIGl0J3MgZ2VuZXJhbGx5IHVwIHRvIHRoZSByZW1vdGUgZW5kcG9pbnQgaG93IGl0 DQo+ID4+ID4+PiBvYnRhaW5zIHRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdGFyZ2V0IHJlc291 cmNlLCBhcyBsb25nIGFzIHRoZQ0KPiA+PiA+Pj4gcmVzdWx0ICppcyogYSByZXByZXNlbnRhdGlv biBvZiB0aGUgdGFyZ2V0IHJlc291cmNlLg0KPiA+PiA+Pj4gRm9yIGV4YW1wbGUsIGluIEEuLCB0 aGUgcmVtb3RlIGVuZHBvaW50IGNhbiBzZXJ2ZSBhIGxvY2FsIGZpbGUNCj4gPj4gPj4+ICh0aGUg ZW5kcG9pbnQgaXMgdGhlbiB0eXBpY2FsbHkgY2FsbGVkIGEgInNlcnZlciIpLCByZXR1cm4gdGhl DQo+ID4+ID4+PiBvdXRwdXQgb2YgYSBDR0kgc2NyaXB0ICgiQ0dJIGdhdGV3YXkiKSwgb2J0YWlu IHRoZSByZXByZXNlbnRhdGlvbg0KPiA+PiA+Pj4gZnJvbSBhbiBIVFRQIHNlcnZlciAoImNyb3Nz LXByb3RvY29sIHByb3h5IiksIG9yIG9idGFpbiB0aGUNCj4gPj4gPj4+IHJlcHJlc2VudGF0aW9u IGZyb20gYW5vdGhlciBDb0FQIHJlbW90ZSBlbmRwb2ludCAoInJldmVyc2UNCj4gPj4gPj4+IHBy b3h5IikuIEluIEIuLCB0aGUgcmVtb3RlIGVuZHBvaW50IGlzIGdlbmVyYWxseSBleHBlY3RlZCB0 bw0KPiA+PiA+Pj4gb2J0YWluIHRoZSByZXByZXNlbnRhdGlvbiBieSByZXF1ZXN0aW5nIGl0IGZy b20gdGhlIGVuZHBvaW50DQo+ID4+ID4+PiBzcGVjaWZpZWQgaW4gdGhlIHJlcXVlc3QgVVJJICgi Zm9yd2FyZCBwcm94eSIpLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IEluIGJvdGggY2FzZXMsIHRoZSBj bGllbnQgaGFzIG5vIHdheSB0byB2ZXJpZnkgdGhhdCB0aGUgb2J0YWluZWQNCj4gPj4gPj4+IHJl c3VsdCBpcyBpbmRlZWQgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdGFyZ2V0IHJlc291cmNlLiBJ dCBtdXN0DQo+ID4+ID4+PiB0cnVzdCB0aGUgcmVtb3RlIGVuZHBvaW50IHRoYXQgaXQgcmV0dXJu cyB0aGUgY29ycmVjdA0KPiA+PnJlcHJlc2VudGF0aW9uLg0KPiA+PiA+Pj4gRFRMUyBqdXN0IHNl Y3VyZXMgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgcmVwcmVzZW50YXRpb24gZnJvbSB0aGUNCj4g Pj4gPj4+IHJlbW90ZSBlbmRwb2ludCB0byB0aGUgY2xpZW50Lg0KPiA+PiA+Pj4NCj4gPj4gPj4+ IChBRkFJSywgSFRUUCB3b3JrcyBleGFjdGx5IHRoZSBzYW1lIHdheS4pDQo+ID4+ID4+DQo+ID4+ ID4+IEluIHRoZSBIVFRQUyBjYXNlIHRoZSBzdG9yeSBpcyBhcyBmb2xsb3dzOg0KPiA+PiA+Pg0K PiA+PiA+PiAqIFRoZSBjbGllbnQgY29udGFjdHMgdGhlIHNlcnZlciBiZWhpbmQgYSBodHRwczov L3d3dy5pZXRmLm9yZw0KPiA+PiA+PiAoYWZ0ZXIgZG9pbmcgYSBETlMgbG9vay11cCkgdXNpbmcg VExTLg0KPiA+PiA+Pg0KPiA+PiA+PiAqIEl0IGdldHMgdGhlIGNlcnQgZnJvbSB0aGUgc2VydmVy Lg0KPiA+PiA+Pg0KPiA+PiA+PiAqIFRoZSBjbGllbnQgY29tcGFyZXMgdGhlIGNvbnRlbnQgb2Yg dGhlIGNlcnQgd2l0aCB3aGF0IGl0IGhhZA0KPiA+PiA+PiBpbml0aWFsbHkgcmVxdWVzdGVkIHRv IGVuc3VyZSBpdCB0YWxrcyB0byB0aGUgcmlnaHQgc2VydmVyLg0KPiA+PiA+Pg0KPiA+PiA+PiBU aGUgVExTIHdpbGwgcHJldmVudCBhbnkgcHJveHkgYWxvbmcgdGhlIHBhdGggdG8gY2FjaGUgdGhl IGRhdGENCj4gPj4gPj4gKHNpbmNlIGl0IGlzIGVuY3J5cHRlZCkuDQo+ID4+ID4+DQo+ID4+ID4+ IFNvLCBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIGNvbXBhcmVzIHRvIENvQVAgYmFzZWQgb24geW91 cg0KPiA+PmRlc2NyaXB0aW9uLg0KPiA+PiA+Pg0KPiA+PiA+PiBDaWFvDQo+ID4+ID4+IEhhbm5l cw0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pj4NCj4gPj4gPj4+IFNvLCBJIHdvdWxkIHNheSB0 aGF0DQo+ID4+ID4+Pg0KPiA+PiA+Pj4gLSBBQ0Ugc2hvdWxkIGNvbnNpZGVyIGZvcndhcmQgcHJv eGllcywgcmV2ZXJzZSBwcm94aWVzIGFuZA0KPiA+PiA+Pj4gcG90ZW50aWFsbHkgY3Jvc3MtcHJv dG9jb2wgcHJveGllcyBzdWNoIHRoYXQgb25lIG9mIHRoZXNlIGNhbg0KPiA+PiA+Pj4gb2J0YWlu IGEgcmVwcmVzZW50YXRpb24gb2YgYSByZXNvdXJjZSB0aGF0IGEgY2xpZW50IGlzIGF1dGhvcml6 ZWQNCj4gPj4gPj4+IHRvIGFjY2VzcyBvbiBiZWhhbGYgb2YgdGhhdCBjbGllbnQ7IGFuZA0KPiA+ PiA+Pj4NCj4gPj4gPj4+IC0gQUNFIHNob3VsZCBub3QgY29uc2lkZXIgcmVtb3RlIGVuZHBvaW50 cyB0aGF0IGNhbm5vdCBiZSB0cnVzdGVkDQo+ID4+ID4+PiB0byBjb3JyZWN0bHkgcmV0dXJuIGEg cmVwcmVzZW50YXRpb24gb2YgYSB0YXJnZXQgcmVzb3VyY2UgKGFzDQo+ID4+ID4+PiB0aGlzIGNv bmNlcm5zIHRoZSBnZW5lcmFsIHNlY3VyaXR5IG9mIENvQVAgd2hpY2ggc2hvdWxkIGJlDQo+ID4+ ID4+PiBhZGRyZXNzZWQgaW4gQ29SRSkuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gS2xhdXMNCj4gPj4g Pg0KPiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4gPkFjZSBtYWlsaW5nIGxpc3QNCj4gPj4gPkFjZUBpZXRmLm9yZw0KPiA+PiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4gPj4NCj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gQWNlIG1haWxpbmcg bGlzdA0KPiA+PiBBY2VAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2UNCg0K From nobody Fri Mar 28 02:07:51 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5C1A04A8 for ; Fri, 28 Mar 2014 02:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaInLdW0Czlu for ; Fri, 28 Mar 2014 02:07:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7911A02CB for ; Fri, 28 Mar 2014 02:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2S97SAP017277; Fri, 28 Mar 2014 10:07:28 +0100 (CET) Received: from [192.168.217.105] (p54890E6B.dip0.t-ipconnect.de [84.137.14.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4E147703; Fri, 28 Mar 2014 10:07:23 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Fri, 28 Mar 2014 10:07:13 +0100 X-Mao-Original-Outgoing-Id: 417690433.920234-eb4c5ebac3737b5fa14a8751e28e3684 Content-Transfer-Encoding: quoted-printable Message-Id: <2AC392CA-07F7-4ABC-B93A-31ADA1506357@tzi.org> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B017@SZXEMA501-MBS.china.huawei.com> To: =?windows-1252?Q?G=F6ran_Selander?= X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/LTJzT1oGQteugwNG2Ooy4mCluco Cc: Klaus Hartke , Likepeng , "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 09:07:49 -0000 On 28 Mar 2014, at 09:29, G=F6ran Selander = wrote: > DCAF (what Carsten call =93the Berlin model=94)=20 Just to avoid confusion: DCAF is a specific protocol proposal. Among other things, it was designed to address the requirements that = come from the fact that client and server may be relying on different = =93wiser elders=94 (less-constrained nodes supporting the = highly-constrained nodes in a close relationship). The model we arrived at in Berlin appears to be the simplest model that = reflects this rather fundamental observation. Gr=FC=DFe, Carsten From nobody Fri Mar 28 07:02:09 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1420B1A0648 for ; Fri, 28 Mar 2014 07:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ykO6Zf1-S8E for ; Fri, 28 Mar 2014 07:02:05 -0700 (PDT) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6E91A00FA for ; Fri, 28 Mar 2014 07:02:04 -0700 (PDT) X-AuditID: c1b4fb28-b7f8e8e000007f0a-0a-533580d9fe0f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 70.09.32522.9D085335; Fri, 28 Mar 2014 15:02:01 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.80]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Fri, 28 Mar 2014 15:02:00 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Klaus Hartke , Kepeng Li <1095318589@qq.com> Thread-Topic: [Ace] Summary of the Proxy Discussion Thread-Index: AQHPRuyElZezb277v0yV5TaQjbw7iZrvavMA///keQCAAMpVgIAAOAQAgAAhv4CAACJhAIAA2T4AgABkt4CAAyiPgIAAEFIAgAGB/wA= Date: Fri, 28 Mar 2014 14:02:00 +0000 Message-ID: References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0C1290EDB935E145ADBBA965B642745A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3Rvdmg2mwwctXuhYHJn9gs/j+rYfZ YtvkV0wOzB5Llvxk8rj1bC2rx7RFmQHMUVw2Kak5mWWpRfp2CVwZPbsvsBWsN6lYurGTrYFx r1YXIyeHhICJxM7Wt2wQtpjEhXvrgWwuDiGBE4wSx5a8ZIVwFjNKfDlxlB2kik3AVeLAg3dM ILaIgIPEuolPwOLMAooSu2edBbOFBYwkdk7qA2rmAKoxlnj0iw+ivEzix7k+ZhCbRUBV4tav A2A2r4C5xI2/35khdj1gltiwYCsrSIJTIFBi2pk7YDMZga77fmoNE8QucYlbT+YzQVwtILFk z3lmCFtU4uXjf2C9ogJ6EvcezWWBiCtK7DzbzgzRqydxY+oUNpDbmAWsJb5tF4AIa0ssW/ga 6h5BiZMzn7BMYJSYhWTbLCTdsxC6ZyHpnoWkewEj6ypGyeLU4uLcdCNDvdz03BK91KLM5OLi /Dy94tRNjMD4PLjlt8YOxu5r9ocYpTlYlMR5q2Z2BgkJpCeWpGanphakFsUXleakFh9iZOLg lGpgZJ3V5iBXK3FYcLp9j/CK7dyFUXKlWqFim9aY5iVxTFY6dcd2T3T7EYHsdc9qWRdW8Svf zktP+FVwInKq5b4zCtcfFOTdtVnM5bNsdb5nlW/8xARPN0mmwOJvc90W5sWcmGhd1n1LccLO eSvNhdafUfpQxDwrb90akS0txdtflm+8qFrH4nlRiaU4I9FQi7moOBEAM2i+Vp0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/-GFvv3kHSVoWhFR_yXEjm3tCNvY Cc: "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:02:07 -0000 Hi Klaus, Keeping Klaus: Good input, I have some comments inline. I didn=B9t intend to work o= n the requirements here and now, but since you started . . . The point I wanted to make was that the proxy cases have an impact on the ACE requirements, so should be included in the work from the start. I guess you agree to that? Kepeng: I don=B9t think we need to come to a conclusion in this discussion to agree on the charter. We don=B9t even need to mention proxy in the charter as long as we agree to allow this to impact the requirements. G=F6ran On 27/03/14 17:00, "Klaus Hartke" wrote: >G=F6ran Selander wrote: >>>Example 1: Client---Origin Server[example.org] >>> >>>1. The client resolves and establishes a secure connection to >>>example.org >>>2. The client requests a representation of the resource >>> /path/to/resource by sending a GET request message >>>3. The origin server satisfies the request by serving a local file to >>>the >>>client >> >> The resource host (origin server) and the client mutually authenticates >> and protect the request/response using the secure connection. > >And this is probably the most basic solution to authorized resource >access: The origin server can determine for each request if the >authenticated client is authorized to perform the requested action on >the target resource or not. > >The important thing to note here is that the origin server is actually >performing three tasks: > >(1.) authenticating of the client, >(2.) having knowledge of which actions the _authenticated_ client is >authorized to perform on which resources, and >(3.) performing the action requested by an _authorized_ client on a >resource. > >If the origin server is too constrained to perform all these tasks, >the idea is to off-load some of them (1. and 2.) to a less constrained >third party. > >Then there must be a standard way for the client to (A.) securely >discover the third party, (B.) perform steps to first become an >authenticated client and then an authorized client, and finally (C.) >to make a request as an authorized (but not necessarily authenticated) >client. > >>>Example 2: Client---Reverse Proxy[example.org]---Origin >>>Server[example.net] >>> >>>1. The client resolves and establishes a secure connection to >>>example.org >>>2. The client requests a representation of the resource >>>/path/to/resource >>>3. The reverse proxy chooses to satisfy the request by obtaining the >>> representation of {coaps,https}://example.net/some/other/resource >>> a. The reverse proxy resolves and establishes a secure connection >>> to example.net >>> b. The reverse proxy requests a representation of the resource >>> /some/other/resource >>> c. The origin server satisfies the request by serving a local file >>> to the reverse proxy >>>4. The reverse proxies serves the representation to the client >> >> In this case, the requested resource, from the point of view of the >> client, is hosted by the reverse proxy, between which there can be >>mutual >> authentication and secure connection. Where the reverse proxy gets a >> representation from is out of scope of the client. > >It may be the origin server [example.net], though, which has the >knowledge of which actions the client (which authenticated to the >reverse proxy [example.org]) is authorized to perform on which >resources. The reverse proxy could merely act as a simple cache in >front of the origin server. In your example, the client is requesting access to example.org/path/to/resource. Do you propose the client should thereby acquire rights to access example.net/some/other/resource. Should the clients have rights to access both these resources? Same privileges? Should the AS keep track of the association? An alternative is that the reverse proxy has rights to access/subscribe to example.net/some/other/resource. > >So there must be (D.) a standard way for the reverse proxy to make >requests to the origin server on behalf of an authorized client. One alternative interpretation is that it is not =B3on behalf=B2, this it t= he reverse proxy which in its own rights (=3Dbeing a reverse proxy) have acces= s to the origin server. Then D would coincide with any other access request. > >>>Example 3: Client---Forward Proxy[proxy.example]---Origin >>>Server[example.org] >>> >>>1. The client resolves and establishes a secure connection to >>>proxy.example >>>2. The client requests a representation of the resource >>> {coaps,https}://example.org/path/to/resource >>>3. The forward proxy satisfies the request by obtaining the >>> representation of {coaps,https}://example.org/path/to/resource >>> a. The forward proxy resolves and establishes a secure connection >>> to example.org >>> b. The forward proxy requests a representation of the resource >>> /path/to/resource >>> c. The origin server satisfies the request by serving a local file >>> to the forward proxy >>>4. The forward proxy serves the representation to the client >> >> In this case, the forward proxy and client mutually authenticates and >> establish secure connection, as does forward proxy and resource host >> (origin server). > >It is noteworthy here that the client can only request the forward >proxy to make its request to the origin server securely (by specifying >the "coaps" scheme). It has no influence on acceptable cipher suits, >certificate roots, etc. The client has to trust the forward proxy that >it secures the connection to the origin server in a way that is >acceptable to the client. > >> With the mechanisms described in this example, the >> resource host does not authenticate the client, so some additional >> security is needed for the origin server to enforce an access control >> decision or evaluate an access control policy which is bound to a >> particular client (or role of client). > >So there must be (E.) a standard way for the forward proxy to make >requests to the origin server on behalf of an authorized client. Either the forward proxy is authorised to access the requested resource or it is not. I think one requirement should be that a forward proxy may not be authorised to access the requested resource. In that case there should be (E.) a standard way for the origin server to authorise a client behind a forward proxy without authorising the forward proxy. G=F6ran > >Klaus > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Fri Mar 28 07:42:31 2014 Return-Path: <1095318589@qq.com> X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F61A0651 for ; Fri, 28 Mar 2014 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.386 X-Spam-Level: X-Spam-Status: No, score=0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldLBd3Onk9Rg for ; Fri, 28 Mar 2014 07:42:20 -0700 (PDT) Received: from smtpbgbr1.qq.com (smtpbgbr1.qq.com [54.207.19.206]) by ietfa.amsl.com (Postfix) with SMTP id D496F1A0639 for ; Fri, 28 Mar 2014 07:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201307; t=1396017673; bh=xgb+wt2Qr9hy1+oVMg8WR+t9FtxeKAKEJ16ET3+rsA0=; h=X-QQ-mid:X-QQ-mid:X-QQ-SSF:From:To:Cc:Subject:Mime-Version: Content-Type:Content-Transfer-Encoding:Date:X-Priority:Message-ID: X-QQ-MIME:X-Mailer:X-QQ-Mailer:X-QQ-SENDSIZE; b=WHYVjne6oqPw+BNUy1K5wCJ1+i2sQWthH4j1tMhFJe+AUR6CXo/Kf8OaC9QhHEbCw 0IFJdgGcakh5fUrtEk8PEa4Xyqg+BVuUcv8ZNXL03yR5JzNlFJWyMnPp2t+mFSjd0o X/ZDmz/ORz7NAKVrnZkR6scvC+9ljuXdAbLxqOeY= X-QQ-mid: mb25t1396017672t8779771 X-QQ-mid: mb25t1396017672t8779771 X-QQ-SSF: 00000000000000F0F7100300000000L From: "=?utf-8?B?S2VwZW5nIExp?=" <1095318589@qq.com> To: "=?utf-8?B?Z29yYW4uc2VsYW5kZXI=?=" , "=?utf-8?B?aGFydGtl?=" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_53358A08_0D5FE228_34D74CA6" Content-Transfer-Encoding: 8Bit Date: Fri, 28 Mar 2014 22:41:12 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/09JzMnL7TfEHQ2GPs7R4CUs0N3M Cc: =?utf-8?B?QWNl?= Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:42:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_53358A08_0D5FE228_34D74CA6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIGRvbsK5dCB0aGluayB3ZSBuZWVkIHRvIGNvbWUgdG8gYSBjb25jbHVzaW9uIGluIHRo aXMgZGlzY3Vzc2lvbiB0byBhZ3JlZSBvbiB0aGUgY2hhcnRlci4gDQoNCkdvb2QhDQoNCj5X ZSBkb27CuXQgZXZlbiBuZWVkIHRvIG1lbnRpb24gcHJveHkgaW4gdGhlIGNoYXJ0ZXIgYXMg bG9uZyBhcyB3ZSBhZ3JlZSB0byBhbGxvdyB0aGlzIHRvIGltcGFjdCB0aGUgcmVxdWlyZW1l bnRzLg0KDQpJIHRoaW5rIHllcywgdGhpcyB3YXMgbWVudGlvbmVkIGluIEhhbm5lcycgc3Vt bWFyeSBhbHJlYWR5Lg0KDQpLZXBlbmcNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLSDljp/l p4vpgq7ku7YgLS0tLS0tLS0tLS0tLS0tLS0tDQrlj5Hku7bkuro6ICJH77+977+9cmFuIFNl bGFuZGUiIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+Ow0K5Y+R6YCB5pe26Ze0OiAy MDE05bm0M+aciDI45pelKOaYn+acn+S6lCkgMjI6MDINCuaUtuS7tuS6ujogIktsYXVzIEhh cnRrZSIgPGhhcnRrZUB0emkub3JnPjsiS2VwZW5nIExpIiA8MTA5NTMxODU4OUBxcS5jb20+ Ow0K5oqE6YCBOiAiQWNlQGlldGYub3JnIiA8QWNlQGlldGYub3JnPjsNCuS4u+mimDogUmU6 IFtBY2VdIFN1bW1hcnkgb2YgdGhlIFByb3h5IERpc2N1c3Npb24NCg0KDQoNCkhpIEtsYXVz LCBLZWVwaW5nIA0KIA0KS2xhdXM6IEdvb2QgaW5wdXQsIEkgaGF2ZSBzb21lIGNvbW1lbnRz IGlubGluZS4gSSBkaWRu77+977+9dCBpbnRlbmQgdG8gd29yayBvbiANCnRoZSByZXF1aXJl bWVudHMgaGVyZSBhbmQgbm93LCBidXQgc2luY2UgeW91IHN0YXJ0ZWQgLiAuIC4gIFRoZSBw b2ludCBJIA0Kd2FudGVkIHRvIG1ha2Ugd2FzIHRoYXQgdGhlIHByb3h5IGNhc2VzIGhhdmUg YW4gaW1wYWN0IG9uIHRoZSBBQ0UgDQpyZXF1aXJlbWVudHMsIHNvIHNob3VsZCBiZSBpbmNs dWRlZCBpbiB0aGUgd29yayBmcm9tIHRoZSBzdGFydC4gSSBndWVzcyANCnlvdSBhZ3JlZSB0 byB0aGF0PyANCiANCiANCktlcGVuZzogSSBkb27vv73vv710IHRoaW5rIHdlIG5lZWQgdG8g Y29tZSB0byBhIGNvbmNsdXNpb24gaW4gdGhpcyBkaXNjdXNzaW9uIA0KdG8gYWdyZWUgb24g dGhlIGNoYXJ0ZXIuIFdlIGRvbu+/ve+/vXQgZXZlbiBuZWVkIHRvIG1lbnRpb24gcHJveHkg aW4gdGhlIA0KY2hhcnRlciBhcyBsb25nIGFzIHdlIGFncmVlIHRvIGFsbG93IHRoaXMgdG8g aW1wYWN0IHRoZSByZXF1aXJlbWVudHMuIA0KIA0KR++/ve+/vXJhbiANCiANCiANCiANCk9u IDI3LzAzLzE0IDE3OjAwLCAiS2xhdXMgSGFydGtlIiA8aGFydGtlQHR6aS5vcmc+IHdyb3Rl OiANCiANCj5H77+977+9cmFuIFNlbGFuZGVyIHdyb3RlOiANCj4+PkV4YW1wbGUgMTogQ2xp ZW50LS0tT3JpZ2luIFNlcnZlcltleGFtcGxlLm9yZ10gDQo+Pj4gDQo+Pj4xLiBUaGUgY2xp ZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25uZWN0aW9uIHRvIA0K Pj4+ZXhhbXBsZS5vcmcgDQo+Pj4yLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50 YXRpb24gb2YgdGhlIHJlc291cmNlIA0KPj4+ICAgIC9wYXRoL3RvL3Jlc291cmNlIGJ5IHNl bmRpbmcgYSBHRVQgcmVxdWVzdCBtZXNzYWdlIA0KPj4+My4gVGhlIG9yaWdpbiBzZXJ2ZXIg c2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlIHRvIA0KPj4+ dGhlIA0KPj4+Y2xpZW50IA0KPj4gDQo+PiBUaGUgcmVzb3VyY2UgaG9zdCAob3JpZ2luIHNl cnZlcikgYW5kIHRoZSBjbGllbnQgbXV0dWFsbHkgYXV0aGVudGljYXRlcyANCj4+IGFuZCBw cm90ZWN0IHRoZSByZXF1ZXN0L3Jlc3BvbnNlIHVzaW5nIHRoZSBzZWN1cmUgY29ubmVjdGlv bi4gDQo+IA0KPkFuZCB0aGlzIGlzIHByb2JhYmx5IHRoZSBtb3N0IGJhc2ljIHNvbHV0aW9u IHRvIGF1dGhvcml6ZWQgcmVzb3VyY2UgDQo+YWNjZXNzOiBUaGUgb3JpZ2luIHNlcnZlciBj YW4gZGV0ZXJtaW5lIGZvciBlYWNoIHJlcXVlc3QgaWYgdGhlIA0KPmF1dGhlbnRpY2F0ZWQg Y2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gcGVyZm9ybSB0aGUgcmVxdWVzdGVkIGFjdGlvbiBv biANCj50aGUgdGFyZ2V0IHJlc291cmNlIG9yIG5vdC4gDQo+IA0KPlRoZSBpbXBvcnRhbnQg dGhpbmcgdG8gbm90ZSBoZXJlIGlzIHRoYXQgdGhlIG9yaWdpbiBzZXJ2ZXIgaXMgYWN0dWFs bHkgDQo+cGVyZm9ybWluZyB0aHJlZSB0YXNrczogDQo+IA0KPigxLikgYXV0aGVudGljYXRp bmcgb2YgdGhlIGNsaWVudCwgDQo+KDIuKSBoYXZpbmcga25vd2xlZGdlIG9mIHdoaWNoIGFj dGlvbnMgdGhlIF9hdXRoZW50aWNhdGVkXyBjbGllbnQgaXMgDQo+YXV0aG9yaXplZCB0byBw ZXJmb3JtIG9uIHdoaWNoIHJlc291cmNlcywgYW5kIA0KPigzLikgcGVyZm9ybWluZyB0aGUg YWN0aW9uIHJlcXVlc3RlZCBieSBhbiBfYXV0aG9yaXplZF8gY2xpZW50IG9uIGEgDQo+cmVz b3VyY2UuIA0KPiANCj5JZiB0aGUgb3JpZ2luIHNlcnZlciBpcyB0b28gY29uc3RyYWluZWQg dG8gcGVyZm9ybSBhbGwgdGhlc2UgdGFza3MsIA0KPnRoZSBpZGVhIGlzIHRvIG9mZi1sb2Fk IHNvbWUgb2YgdGhlbSAoMS4gYW5kIDIuKSB0byBhIGxlc3MgY29uc3RyYWluZWQgDQo+dGhp cmQgcGFydHkuIA0KPiANCj5UaGVuIHRoZXJlIG11c3QgYmUgYSBzdGFuZGFyZCB3YXkgZm9y IHRoZSBjbGllbnQgdG8gKEEuKSBzZWN1cmVseSANCj5kaXNjb3ZlciB0aGUgdGhpcmQgcGFy dHksIChCLikgcGVyZm9ybSBzdGVwcyB0byBmaXJzdCBiZWNvbWUgYW4gDQo+YXV0aGVudGlj YXRlZCBjbGllbnQgYW5kIHRoZW4gYW4gYXV0aG9yaXplZCBjbGllbnQsIGFuZCBmaW5hbGx5 IChDLikgDQo+dG8gbWFrZSBhIHJlcXVlc3QgYXMgYW4gYXV0aG9yaXplZCAoYnV0IG5vdCBu ZWNlc3NhcmlseSBhdXRoZW50aWNhdGVkKSANCj5jbGllbnQuIA0KPiANCj4+PkV4YW1wbGUg MjogQ2xpZW50LS0tUmV2ZXJzZSBQcm94eVtleGFtcGxlLm9yZ10tLS1PcmlnaW4gDQo+Pj5T ZXJ2ZXJbZXhhbXBsZS5uZXRdIA0KPj4+IA0KPj4+MS4gVGhlIGNsaWVudCByZXNvbHZlcyBh bmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbiB0byANCj4+PmV4YW1wbGUub3Jn IA0KPj4+Mi4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBy ZXNvdXJjZSANCj4+Pi9wYXRoL3RvL3Jlc291cmNlIA0KPj4+My4gVGhlIHJldmVyc2UgcHJv eHkgY2hvb3NlcyB0byBzYXRpc2Z5IHRoZSByZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUgDQo+ Pj4gICAgcmVwcmVzZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUubmV0L3Nv bWUvb3RoZXIvcmVzb3VyY2UgDQo+Pj4gICAgYS4gVGhlIHJldmVyc2UgcHJveHkgcmVzb2x2 ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24gDQo+Pj4gICAgICAgIHRv IGV4YW1wbGUubmV0IA0KPj4+ICAgIGIuIFRoZSByZXZlcnNlIHByb3h5IHJlcXVlc3RzIGEg cmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlIA0KPj4+ICAgICAgICAvc29tZS9vdGhl ci9yZXNvdXJjZSANCj4+PiAgICBjLiBUaGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhl IHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2FsIGZpbGUgDQo+Pj4gICAgICAgIHRvIHRoZSBy ZXZlcnNlIHByb3h5IA0KPj4+NC4gVGhlIHJldmVyc2UgcHJveGllcyBzZXJ2ZXMgdGhlIHJl cHJlc2VudGF0aW9uIHRvIHRoZSBjbGllbnQgDQo+PiANCj4+IEluIHRoaXMgY2FzZSwgdGhl IHJlcXVlc3RlZCByZXNvdXJjZSwgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgDQo+ PiBjbGllbnQsIGlzIGhvc3RlZCBieSB0aGUgcmV2ZXJzZSBwcm94eSwgYmV0d2VlbiB3aGlj aCB0aGVyZSBjYW4gYmUgDQo+Pm11dHVhbCANCj4+IGF1dGhlbnRpY2F0aW9uIGFuZCBzZWN1 cmUgY29ubmVjdGlvbi4gV2hlcmUgdGhlIHJldmVyc2UgcHJveHkgZ2V0cyBhIA0KPj4gcmVw cmVzZW50YXRpb24gZnJvbSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGNsaWVudC4gDQo+IA0K Pkl0IG1heSBiZSB0aGUgb3JpZ2luIHNlcnZlciBbZXhhbXBsZS5uZXRdLCB0aG91Z2gsIHdo aWNoIGhhcyB0aGUgDQo+a25vd2xlZGdlIG9mIHdoaWNoIGFjdGlvbnMgdGhlIGNsaWVudCAo d2hpY2ggYXV0aGVudGljYXRlZCB0byB0aGUgDQo+cmV2ZXJzZSBwcm94eSBbZXhhbXBsZS5v cmddKSBpcyBhdXRob3JpemVkIHRvIHBlcmZvcm0gb24gd2hpY2ggDQo+cmVzb3VyY2VzLiBU aGUgcmV2ZXJzZSBwcm94eSBjb3VsZCBtZXJlbHkgYWN0IGFzIGEgc2ltcGxlIGNhY2hlIGlu IA0KPmZyb250IG9mIHRoZSBvcmlnaW4gc2VydmVyLiANCiANCkluIHlvdXIgZXhhbXBsZSwg dGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFjY2VzcyB0byANCmV4YW1wbGUub3JnL3BhdGgv dG8vcmVzb3VyY2UuIERvIHlvdSBwcm9wb3NlIHRoZSBjbGllbnQgc2hvdWxkIHRoZXJlYnkg DQphY3F1aXJlIHJpZ2h0cyB0byBhY2Nlc3MgZXhhbXBsZS5uZXQvc29tZS9vdGhlci9yZXNv dXJjZS4gU2hvdWxkIHRoZSANCmNsaWVudHMgaGF2ZSByaWdodHMgdG8gYWNjZXNzIGJvdGgg dGhlc2UgcmVzb3VyY2VzPyBTYW1lIHByaXZpbGVnZXM/IA0KU2hvdWxkIHRoZSBBUyBrZWVw IHRyYWNrIG9mIHRoZSBhc3NvY2lhdGlvbj8gQW4gYWx0ZXJuYXRpdmUgaXMgdGhhdCB0aGUg DQpyZXZlcnNlIHByb3h5IGhhcyByaWdodHMgdG8gYWNjZXNzL3N1YnNjcmliZSB0byANCmV4 YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVzb3VyY2UuIA0KIA0KPiANCj5TbyB0aGVyZSBtdXN0 IGJlIChELikgYSBzdGFuZGFyZCB3YXkgZm9yIHRoZSByZXZlcnNlIHByb3h5IHRvIG1ha2Ug DQo+cmVxdWVzdHMgdG8gdGhlIG9yaWdpbiBzZXJ2ZXIgb24gYmVoYWxmIG9mIGFuIGF1dGhv cml6ZWQgY2xpZW50LiANCiANCk9uZSBhbHRlcm5hdGl2ZSBpbnRlcnByZXRhdGlvbiBpcyB0 aGF0IGl0IGlzIG5vdCDvv73vv71vbiBiZWhhbGbvv73vv70sIHRoaXMgaXQgdGhlIA0KcmV2 ZXJzZSBwcm94eSB3aGljaCBpbiBpdHMgb3duIHJpZ2h0cyAoPWJlaW5nIGEgcmV2ZXJzZSBw cm94eSkgaGF2ZSBhY2Nlc3MgDQp0byB0aGUgb3JpZ2luIHNlcnZlci4gVGhlbiBEIHdvdWxk IGNvaW5jaWRlIHdpdGggYW55IG90aGVyIGFjY2VzcyByZXF1ZXN0LiANCiANCj4gDQo+Pj5F eGFtcGxlIDM6IENsaWVudC0tLUZvcndhcmQgUHJveHlbcHJveHkuZXhhbXBsZV0tLS1Pcmln aW4gDQo+Pj5TZXJ2ZXJbZXhhbXBsZS5vcmddIA0KPj4+IA0KPj4+MS4gVGhlIGNsaWVudCBy ZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbiB0byANCj4+PnBy b3h5LmV4YW1wbGUgDQo+Pj4yLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRp b24gb2YgdGhlIHJlc291cmNlIA0KPj4+ICAgIHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm9y Zy9wYXRoL3RvL3Jlc291cmNlIA0KPj4+My4gVGhlIGZvcndhcmQgcHJveHkgc2F0aXNmaWVz IHRoZSByZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUgDQo+Pj4gICAgcmVwcmVzZW50YXRpb24g b2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUub3JnL3BhdGgvdG8vcmVzb3VyY2UgDQo+Pj4g ICAgYS4gVGhlIGZvcndhcmQgcHJveHkgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2Vj dXJlIGNvbm5lY3Rpb24gDQo+Pj4gICAgICAgIHRvIGV4YW1wbGUub3JnIA0KPj4+ICAgIGIu IFRoZSBmb3J3YXJkIHByb3h5IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJl c291cmNlIA0KPj4+ICAgICAgICAvcGF0aC90by9yZXNvdXJjZSANCj4+PiAgICBjLiBUaGUg b3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhlIHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2Fs IGZpbGUgDQo+Pj4gICAgICAgIHRvIHRoZSBmb3J3YXJkIHByb3h5IA0KPj4+NC4gVGhlIGZv cndhcmQgcHJveHkgc2VydmVzIHRoZSByZXByZXNlbnRhdGlvbiB0byB0aGUgY2xpZW50IA0K Pj4gDQo+PiBJbiB0aGlzIGNhc2UsIHRoZSBmb3J3YXJkIHByb3h5IGFuZCBjbGllbnQgbXV0 dWFsbHkgYXV0aGVudGljYXRlcyBhbmQgDQo+PiBlc3RhYmxpc2ggc2VjdXJlIGNvbm5lY3Rp b24sIGFzIGRvZXMgZm9yd2FyZCBwcm94eSBhbmQgcmVzb3VyY2UgaG9zdCANCj4+IChvcmln aW4gc2VydmVyKS4gDQo+IA0KPkl0IGlzIG5vdGV3b3J0aHkgaGVyZSB0aGF0IHRoZSBjbGll bnQgY2FuIG9ubHkgcmVxdWVzdCB0aGUgZm9yd2FyZCANCj5wcm94eSB0byBtYWtlIGl0cyBy ZXF1ZXN0IHRvIHRoZSBvcmlnaW4gc2VydmVyIHNlY3VyZWx5IChieSBzcGVjaWZ5aW5nIA0K PnRoZSAiY29hcHMiIHNjaGVtZSkuIEl0IGhhcyBubyBpbmZsdWVuY2Ugb24gYWNjZXB0YWJs ZSBjaXBoZXIgc3VpdHMsIA0KPmNlcnRpZmljYXRlIHJvb3RzLCBldGMuIFRoZSBjbGllbnQg aGFzIHRvIHRydXN0IHRoZSBmb3J3YXJkIHByb3h5IHRoYXQgDQo+aXQgc2VjdXJlcyB0aGUg Y29ubmVjdGlvbiB0byB0aGUgb3JpZ2luIHNlcnZlciBpbiBhIHdheSB0aGF0IGlzIA0KPmFj Y2VwdGFibGUgdG8gdGhlIGNsaWVudC4gDQo+IA0KPj4gV2l0aCB0aGUgbWVjaGFuaXNtcyBk ZXNjcmliZWQgaW4gdGhpcyBleGFtcGxlLCB0aGUgDQo+PiByZXNvdXJjZSBob3N0IGRvZXMg bm90IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCBzbyBzb21lIGFkZGl0aW9uYWwgDQo+PiBz ZWN1cml0eSBpcyBuZWVkZWQgZm9yIHRoZSBvcmlnaW4gc2VydmVyIHRvIGVuZm9yY2UgYW4g YWNjZXNzIGNvbnRyb2wgDQo+PiBkZWNpc2lvbiBvciBldmFsdWF0ZSBhbiBhY2Nlc3MgY29u dHJvbCBwb2xpY3kgd2hpY2ggaXMgYm91bmQgdG8gYSANCj4+IHBhcnRpY3VsYXIgY2xpZW50 IChvciByb2xlIG9mIGNsaWVudCkuIA0KPiANCj5TbyB0aGVyZSBtdXN0IGJlIChFLikgYSBz dGFuZGFyZCB3YXkgZm9yIHRoZSBmb3J3YXJkIHByb3h5IHRvIG1ha2UgDQo+cmVxdWVzdHMg dG8gdGhlIG9yaWdpbiBzZXJ2ZXIgb24gYmVoYWxmIG9mIGFuIGF1dGhvcml6ZWQgY2xpZW50 LiANCiANCkVpdGhlciB0aGUgZm9yd2FyZCBwcm94eSBpcyBhdXRob3Jpc2VkIHRvIGFjY2Vz cyB0aGUgcmVxdWVzdGVkIHJlc291cmNlIG9yIA0KaXQgaXMgbm90LiBJIHRoaW5rIG9uZSBy ZXF1aXJlbWVudCBzaG91bGQgYmUgdGhhdCBhIGZvcndhcmQgcHJveHkgbWF5IG5vdCANCmJl IGF1dGhvcmlzZWQgdG8gYWNjZXNzIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UuIEluIHRoYXQg Y2FzZSB0aGVyZSBzaG91bGQgDQpiZSAoRS4pIGEgc3RhbmRhcmQgd2F5IGZvciB0aGUgb3Jp Z2luIHNlcnZlciB0byBhdXRob3Jpc2UgYSBjbGllbnQgYmVoaW5kIA0KYSBmb3J3YXJkIHBy b3h5IHdpdGhvdXQgYXV0aG9yaXNpbmcgdGhlIGZvcndhcmQgcHJveHkuIA0KIA0KIA0KIA0K R++/ve+/vXJhbiANCiANCiANCj4gDQo+S2xhdXMgDQo+IA0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0KPkFjZSBtYWlsaW5nIGxpc3QgDQo+ QWNlQGlldGYub3JnIA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWM= ------=_NextPart_53358A08_0D5FE228_34D74CA6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 Jmd0OyBJIGRvbsK5dCB0aGluayB3ZSBuZWVkIHRvIGNvbWUgdG8gYSBjb25jbHVzaW9uIGlu IHRoaXMgZGlzY3Vzc2lvbiB0byBhZ3JlZSBvbiB0aGUgY2hhcnRlci4gPGJyPjxicj5Hb29k ITxicj48YnI+Jmd0O1dlIGRvbsK5dCBldmVuIG5lZWQgdG8gbWVudGlvbiBwcm94eSBpbiB0 aGUgY2hhcnRlciBhcyBsb25nIGFzIHdlIGFncmVlIHRvIGFsbG93IHRoaXMgdG8gaW1wYWN0 IHRoZSByZXF1aXJlbWVudHMuPGJyPjxicj5JIHRoaW5rIHllcywgdGhpcyB3YXMgbWVudGlv bmVkIGluIEhhbm5lcycgc3VtbWFyeSBhbHJlYWR5Ljxicj48YnI+S2VwZW5nPGJyPjxicj48 YnIvPjxici8+LS0tLS0tLS0tLS0tLS0tLS0tIOWOn+Wni+mCruS7tiAtLS0tLS0tLS0tLS0t LS0tLS08YnIvPjxIVE1MPjxCT0RZPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFj a2dyb3VuZDogbm9uZSByZXBlYXQgc2Nyb2xsIDAlIHJnYigyMzksIDIzOSwgMjM5KTsgcGFk ZGluZzogOHB4OyI+PGRpdiBpZD0ibWVudV9zZW5kZXIiPjxiPuWPkeS7tuS6ujo8L2I+Jm5i c3A7Ikfvv73vv71yYW4gU2VsYW5kZSIgJmx0O2dvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNv bSZndDs7PC9kaXY+PGRpdj48Yj7lj5HpgIHml7bpl7Q6PC9iPiZuYnNwOzIwMTTlubQz5pyI Mjjml6Uo5pif5pyf5LqUKSAyMjowMjwvZGl2PjxkaXY+PGI+5pS25Lu25Lq6OjwvYj4mbmJz cDsiS2xhdXMgSGFydGtlIiAmbHQ7aGFydGtlQHR6aS5vcmcmZ3Q7OyJLZXBlbmcgTGkiICZs dDsxMDk1MzE4NTg5QHFxLmNvbSZndDs7PC9kaXY+PGRpdj48Yj7mioTpgIE6PC9iPiZuYnNw OyJBY2VAaWV0Zi5vcmciICZsdDtBY2VAaWV0Zi5vcmcmZ3Q7OzwvZGl2PjxkaXY+PGI+5Li7 6aKYOjwvYj4mbmJzcDtSZTogW0FjZV0gU3VtbWFyeSBvZiB0aGUgUHJveHkgRGlzY3Vzc2lv bjwvZGl2PjwvZGl2PjwvQk9EWT48L0hUTUw+PGJyLz48YnIvPkhpIEtsYXVzLCBLZWVwaW5n DTxicj4NPGJyPktsYXVzOiBHb29kIGlucHV0LCBJIGhhdmUgc29tZSBjb21tZW50cyBpbmxp bmUuIEkgZGlkbu+/ve+/vXQgaW50ZW5kIHRvIHdvcmsgb24NPGJyPnRoZSByZXF1aXJlbWVu dHMgaGVyZSBhbmQgbm93LCBidXQgc2luY2UgeW91IHN0YXJ0ZWQgLiAuIC4mbmJzcDsgVGhl IHBvaW50IEkNPGJyPndhbnRlZCB0byBtYWtlIHdhcyB0aGF0IHRoZSBwcm94eSBjYXNlcyBo YXZlIGFuIGltcGFjdCBvbiB0aGUgQUNFDTxicj5yZXF1aXJlbWVudHMsIHNvIHNob3VsZCBi ZSBpbmNsdWRlZCBpbiB0aGUgd29yayBmcm9tIHRoZSBzdGFydC4gSSBndWVzcw08YnI+eW91 IGFncmVlIHRvIHRoYXQ/DTxicj4NPGJyPg08YnI+S2VwZW5nOiBJIGRvbu+/ve+/vXQgdGhp bmsgd2UgbmVlZCB0byBjb21lIHRvIGEgY29uY2x1c2lvbiBpbiB0aGlzIGRpc2N1c3Npb24N PGJyPnRvIGFncmVlIG9uIHRoZSBjaGFydGVyLiBXZSBkb27vv73vv710IGV2ZW4gbmVlZCB0 byBtZW50aW9uIHByb3h5IGluIHRoZQ08YnI+Y2hhcnRlciBhcyBsb25nIGFzIHdlIGFncmVl IHRvIGFsbG93IHRoaXMgdG8gaW1wYWN0IHRoZSByZXF1aXJlbWVudHMuDTxicj4NPGJyPkfv v73vv71yYW4NPGJyPg08YnI+DTxicj4NPGJyPk9uIDI3LzAzLzE0IDE3OjAwLCAiS2xhdXMg SGFydGtlIiAmbHQ7aGFydGtlQHR6aS5vcmcmZ3Q7IHdyb3RlOg08YnI+DTxicj4mZ3Q7R++/ ve+/vXJhbiBTZWxhbmRlciB3cm90ZToNPGJyPiZndDsmZ3Q7Jmd0O0V4YW1wbGUgMTogQ2xp ZW50LS0tT3JpZ2luIFNlcnZlcltleGFtcGxlLm9yZ10NPGJyPiZndDsmZ3Q7Jmd0Ow08YnI+ Jmd0OyZndDsmZ3Q7MS4gVGhlIGNsaWVudCByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBz ZWN1cmUgY29ubmVjdGlvbiB0bw08YnI+Jmd0OyZndDsmZ3Q7ZXhhbXBsZS5vcmcNPGJyPiZn dDsmZ3Q7Jmd0OzIuIFRoZSBjbGllbnQgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0 aGUgcmVzb3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAvcGF0aC90 by9yZXNvdXJjZSBieSBzZW5kaW5nIGEgR0VUIHJlcXVlc3QgbWVzc2FnZQ08YnI+Jmd0OyZn dDsmZ3Q7My4gVGhlIG9yaWdpbiBzZXJ2ZXIgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNl cnZpbmcgYSBsb2NhbCBmaWxlIHRvDTxicj4mZ3Q7Jmd0OyZndDt0aGUNPGJyPiZndDsmZ3Q7 Jmd0O2NsaWVudA08YnI+Jmd0OyZndDsNPGJyPiZndDsmZ3Q7IFRoZSByZXNvdXJjZSBob3N0 IChvcmlnaW4gc2VydmVyKSBhbmQgdGhlIGNsaWVudCBtdXR1YWxseSBhdXRoZW50aWNhdGVz DTxicj4mZ3Q7Jmd0OyBhbmQgcHJvdGVjdCB0aGUgcmVxdWVzdC9yZXNwb25zZSB1c2luZyB0 aGUgc2VjdXJlIGNvbm5lY3Rpb24uDTxicj4mZ3Q7DTxicj4mZ3Q7QW5kIHRoaXMgaXMgcHJv YmFibHkgdGhlIG1vc3QgYmFzaWMgc29sdXRpb24gdG8gYXV0aG9yaXplZCByZXNvdXJjZQ08 YnI+Jmd0O2FjY2VzczogVGhlIG9yaWdpbiBzZXJ2ZXIgY2FuIGRldGVybWluZSBmb3IgZWFj aCByZXF1ZXN0IGlmIHRoZQ08YnI+Jmd0O2F1dGhlbnRpY2F0ZWQgY2xpZW50IGlzIGF1dGhv cml6ZWQgdG8gcGVyZm9ybSB0aGUgcmVxdWVzdGVkIGFjdGlvbiBvbg08YnI+Jmd0O3RoZSB0 YXJnZXQgcmVzb3VyY2Ugb3Igbm90Lg08YnI+Jmd0Ow08YnI+Jmd0O1RoZSBpbXBvcnRhbnQg dGhpbmcgdG8gbm90ZSBoZXJlIGlzIHRoYXQgdGhlIG9yaWdpbiBzZXJ2ZXIgaXMgYWN0dWFs bHkNPGJyPiZndDtwZXJmb3JtaW5nIHRocmVlIHRhc2tzOg08YnI+Jmd0Ow08YnI+Jmd0Oygx LikgYXV0aGVudGljYXRpbmcgb2YgdGhlIGNsaWVudCwNPGJyPiZndDsoMi4pIGhhdmluZyBr bm93bGVkZ2Ugb2Ygd2hpY2ggYWN0aW9ucyB0aGUgX2F1dGhlbnRpY2F0ZWRfIGNsaWVudCBp cw08YnI+Jmd0O2F1dGhvcml6ZWQgdG8gcGVyZm9ybSBvbiB3aGljaCByZXNvdXJjZXMsIGFu ZA08YnI+Jmd0OygzLikgcGVyZm9ybWluZyB0aGUgYWN0aW9uIHJlcXVlc3RlZCBieSBhbiBf YXV0aG9yaXplZF8gY2xpZW50IG9uIGENPGJyPiZndDtyZXNvdXJjZS4NPGJyPiZndDsNPGJy PiZndDtJZiB0aGUgb3JpZ2luIHNlcnZlciBpcyB0b28gY29uc3RyYWluZWQgdG8gcGVyZm9y bSBhbGwgdGhlc2UgdGFza3MsDTxicj4mZ3Q7dGhlIGlkZWEgaXMgdG8gb2ZmLWxvYWQgc29t ZSBvZiB0aGVtICgxLiBhbmQgMi4pIHRvIGEgbGVzcyBjb25zdHJhaW5lZA08YnI+Jmd0O3Ro aXJkIHBhcnR5Lg08YnI+Jmd0Ow08YnI+Jmd0O1RoZW4gdGhlcmUgbXVzdCBiZSBhIHN0YW5k YXJkIHdheSBmb3IgdGhlIGNsaWVudCB0byAoQS4pIHNlY3VyZWx5DTxicj4mZ3Q7ZGlzY292 ZXIgdGhlIHRoaXJkIHBhcnR5LCAoQi4pIHBlcmZvcm0gc3RlcHMgdG8gZmlyc3QgYmVjb21l IGFuDTxicj4mZ3Q7YXV0aGVudGljYXRlZCBjbGllbnQgYW5kIHRoZW4gYW4gYXV0aG9yaXpl ZCBjbGllbnQsIGFuZCBmaW5hbGx5IChDLikNPGJyPiZndDt0byBtYWtlIGEgcmVxdWVzdCBh cyBhbiBhdXRob3JpemVkIChidXQgbm90IG5lY2Vzc2FyaWx5IGF1dGhlbnRpY2F0ZWQpDTxi cj4mZ3Q7Y2xpZW50Lg08YnI+Jmd0Ow08YnI+Jmd0OyZndDsmZ3Q7RXhhbXBsZSAyOiBDbGll bnQtLS1SZXZlcnNlIFByb3h5W2V4YW1wbGUub3JnXS0tLU9yaWdpbg08YnI+Jmd0OyZndDsm Z3Q7U2VydmVyW2V4YW1wbGUubmV0XQ08YnI+Jmd0OyZndDsmZ3Q7DTxicj4mZ3Q7Jmd0OyZn dDsxLiBUaGUgY2xpZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25u ZWN0aW9uIHRvDTxicj4mZ3Q7Jmd0OyZndDtleGFtcGxlLm9yZw08YnI+Jmd0OyZndDsmZ3Q7 Mi4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJj ZQ08YnI+Jmd0OyZndDsmZ3Q7L3BhdGgvdG8vcmVzb3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OzMu IFRoZSByZXZlcnNlIHByb3h5IGNob29zZXMgdG8gc2F0aXNmeSB0aGUgcmVxdWVzdCBieSBv YnRhaW5pbmcgdGhlDTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwcmVz ZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVz b3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhLiBUaGUgcmV2ZXJz ZSBwcm94eSByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbg08 YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRvIGV4YW1wbGUubmV0DTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg Yi4gVGhlIHJldmVyc2UgcHJveHkgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUg cmVzb3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAvc29tZS9vdGhlci9yZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGMuIFRoZSBvcmlnaW4gc2VydmVyIHNhdGlzZmllcyB0aGUgcmVx dWVzdCBieSBzZXJ2aW5nIGEgbG9jYWwgZmlsZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIHRoZSByZXZlcnNlIHByb3h5 DTxicj4mZ3Q7Jmd0OyZndDs0LiBUaGUgcmV2ZXJzZSBwcm94aWVzIHNlcnZlcyB0aGUgcmVw cmVzZW50YXRpb24gdG8gdGhlIGNsaWVudA08YnI+Jmd0OyZndDsNPGJyPiZndDsmZ3Q7IElu IHRoaXMgY2FzZSwgdGhlIHJlcXVlc3RlZCByZXNvdXJjZSwgZnJvbSB0aGUgcG9pbnQgb2Yg dmlldyBvZiB0aGUNPGJyPiZndDsmZ3Q7IGNsaWVudCwgaXMgaG9zdGVkIGJ5IHRoZSByZXZl cnNlIHByb3h5LCBiZXR3ZWVuIHdoaWNoIHRoZXJlIGNhbiBiZQ08YnI+Jmd0OyZndDttdXR1 YWwNPGJyPiZndDsmZ3Q7IGF1dGhlbnRpY2F0aW9uIGFuZCBzZWN1cmUgY29ubmVjdGlvbi4g V2hlcmUgdGhlIHJldmVyc2UgcHJveHkgZ2V0cyBhDTxicj4mZ3Q7Jmd0OyByZXByZXNlbnRh dGlvbiBmcm9tIGlzIG91dCBvZiBzY29wZSBvZiB0aGUgY2xpZW50Lg08YnI+Jmd0Ow08YnI+ Jmd0O0l0IG1heSBiZSB0aGUgb3JpZ2luIHNlcnZlciBbZXhhbXBsZS5uZXRdLCB0aG91Z2gs IHdoaWNoIGhhcyB0aGUNPGJyPiZndDtrbm93bGVkZ2Ugb2Ygd2hpY2ggYWN0aW9ucyB0aGUg Y2xpZW50ICh3aGljaCBhdXRoZW50aWNhdGVkIHRvIHRoZQ08YnI+Jmd0O3JldmVyc2UgcHJv eHkgW2V4YW1wbGUub3JnXSkgaXMgYXV0aG9yaXplZCB0byBwZXJmb3JtIG9uIHdoaWNoDTxi cj4mZ3Q7cmVzb3VyY2VzLiBUaGUgcmV2ZXJzZSBwcm94eSBjb3VsZCBtZXJlbHkgYWN0IGFz IGEgc2ltcGxlIGNhY2hlIGluDTxicj4mZ3Q7ZnJvbnQgb2YgdGhlIG9yaWdpbiBzZXJ2ZXIu DTxicj4NPGJyPkluIHlvdXIgZXhhbXBsZSwgdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFj Y2VzcyB0bw08YnI+ZXhhbXBsZS5vcmcvcGF0aC90by9yZXNvdXJjZS4gRG8geW91IHByb3Bv c2UgdGhlIGNsaWVudCBzaG91bGQgdGhlcmVieQ08YnI+YWNxdWlyZSByaWdodHMgdG8gYWNj ZXNzIGV4YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVzb3VyY2UuIFNob3VsZCB0aGUNPGJyPmNs aWVudHMgaGF2ZSByaWdodHMgdG8gYWNjZXNzIGJvdGggdGhlc2UgcmVzb3VyY2VzPyBTYW1l IHByaXZpbGVnZXM/DTxicj5TaG91bGQgdGhlIEFTIGtlZXAgdHJhY2sgb2YgdGhlIGFzc29j aWF0aW9uPyBBbiBhbHRlcm5hdGl2ZSBpcyB0aGF0IHRoZQ08YnI+cmV2ZXJzZSBwcm94eSBo YXMgcmlnaHRzIHRvIGFjY2Vzcy9zdWJzY3JpYmUgdG8NPGJyPmV4YW1wbGUubmV0L3NvbWUv b3RoZXIvcmVzb3VyY2UuDTxicj4NPGJyPiZndDsNPGJyPiZndDtTbyB0aGVyZSBtdXN0IGJl IChELikgYSBzdGFuZGFyZCB3YXkgZm9yIHRoZSByZXZlcnNlIHByb3h5IHRvIG1ha2UNPGJy PiZndDtyZXF1ZXN0cyB0byB0aGUgb3JpZ2luIHNlcnZlciBvbiBiZWhhbGYgb2YgYW4gYXV0 aG9yaXplZCBjbGllbnQuDTxicj4NPGJyPk9uZSBhbHRlcm5hdGl2ZSBpbnRlcnByZXRhdGlv biBpcyB0aGF0IGl0IGlzIG5vdCDvv73vv71vbiBiZWhhbGbvv73vv70sIHRoaXMgaXQgdGhl DTxicj5yZXZlcnNlIHByb3h5IHdoaWNoIGluIGl0cyBvd24gcmlnaHRzICg9YmVpbmcgYSBy ZXZlcnNlIHByb3h5KSBoYXZlIGFjY2Vzcw08YnI+dG8gdGhlIG9yaWdpbiBzZXJ2ZXIuIFRo ZW4gRCB3b3VsZCBjb2luY2lkZSB3aXRoIGFueSBvdGhlciBhY2Nlc3MgcmVxdWVzdC4NPGJy Pg08YnI+Jmd0Ow08YnI+Jmd0OyZndDsmZ3Q7RXhhbXBsZSAzOiBDbGllbnQtLS1Gb3J3YXJk IFByb3h5W3Byb3h5LmV4YW1wbGVdLS0tT3JpZ2luDTxicj4mZ3Q7Jmd0OyZndDtTZXJ2ZXJb ZXhhbXBsZS5vcmddDTxicj4mZ3Q7Jmd0OyZndDsNPGJyPiZndDsmZ3Q7Jmd0OzEuIFRoZSBj bGllbnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24gdG8N PGJyPiZndDsmZ3Q7Jmd0O3Byb3h5LmV4YW1wbGUNPGJyPiZndDsmZ3Q7Jmd0OzIuIFRoZSBj bGllbnQgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzb3VyY2UNPGJyPiZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB7Y29hcHMsaHR0cHN9Oi8vZXhhbXBsZS5v cmcvcGF0aC90by9yZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7My4gVGhlIGZvcndhcmQgcHJv eHkgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUNPGJyPiZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyByZXByZXNlbnRhdGlvbiBvZiB7Y29hcHMsaHR0cHN9 Oi8vZXhhbXBsZS5vcmcvcGF0aC90by9yZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGEuIFRoZSBmb3J3YXJkIHByb3h5IHJlc29sdmVzIGFuZCBlc3RhYmxp c2hlcyBhIHNlY3VyZSBjb25uZWN0aW9uDTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gZXhhbXBsZS5vcmcNPGJyPiZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBiLiBUaGUgZm9yd2FyZCBwcm94eSByZXF1ZXN0 cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9wYXRoL3RvL3Jlc291 cmNlDTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYy4gVGhlIG9yaWdpbiBz ZXJ2ZXIgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlDTxi cj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdG8gdGhlIGZvcndhcmQgcHJveHkNPGJyPiZndDsmZ3Q7Jmd0OzQuIFRoZSBmb3J3YXJk IHByb3h5IHNlcnZlcyB0aGUgcmVwcmVzZW50YXRpb24gdG8gdGhlIGNsaWVudA08YnI+Jmd0 OyZndDsNPGJyPiZndDsmZ3Q7IEluIHRoaXMgY2FzZSwgdGhlIGZvcndhcmQgcHJveHkgYW5k IGNsaWVudCBtdXR1YWxseSBhdXRoZW50aWNhdGVzIGFuZA08YnI+Jmd0OyZndDsgZXN0YWJs aXNoIHNlY3VyZSBjb25uZWN0aW9uLCBhcyBkb2VzIGZvcndhcmQgcHJveHkgYW5kIHJlc291 cmNlIGhvc3QNPGJyPiZndDsmZ3Q7IChvcmlnaW4gc2VydmVyKS4NPGJyPiZndDsNPGJyPiZn dDtJdCBpcyBub3Rld29ydGh5IGhlcmUgdGhhdCB0aGUgY2xpZW50IGNhbiBvbmx5IHJlcXVl c3QgdGhlIGZvcndhcmQNPGJyPiZndDtwcm94eSB0byBtYWtlIGl0cyByZXF1ZXN0IHRvIHRo ZSBvcmlnaW4gc2VydmVyIHNlY3VyZWx5IChieSBzcGVjaWZ5aW5nDTxicj4mZ3Q7dGhlICJj b2FwcyIgc2NoZW1lKS4gSXQgaGFzIG5vIGluZmx1ZW5jZSBvbiBhY2NlcHRhYmxlIGNpcGhl ciBzdWl0cywNPGJyPiZndDtjZXJ0aWZpY2F0ZSByb290cywgZXRjLiBUaGUgY2xpZW50IGhh cyB0byB0cnVzdCB0aGUgZm9yd2FyZCBwcm94eSB0aGF0DTxicj4mZ3Q7aXQgc2VjdXJlcyB0 aGUgY29ubmVjdGlvbiB0byB0aGUgb3JpZ2luIHNlcnZlciBpbiBhIHdheSB0aGF0IGlzDTxi cj4mZ3Q7YWNjZXB0YWJsZSB0byB0aGUgY2xpZW50Lg08YnI+Jmd0Ow08YnI+Jmd0OyZndDsg V2l0aCB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhpcyBleGFtcGxlLCB0aGUNPGJy PiZndDsmZ3Q7IHJlc291cmNlIGhvc3QgZG9lcyBub3QgYXV0aGVudGljYXRlIHRoZSBjbGll bnQsIHNvIHNvbWUgYWRkaXRpb25hbA08YnI+Jmd0OyZndDsgc2VjdXJpdHkgaXMgbmVlZGVk IGZvciB0aGUgb3JpZ2luIHNlcnZlciB0byBlbmZvcmNlIGFuIGFjY2VzcyBjb250cm9sDTxi cj4mZ3Q7Jmd0OyBkZWNpc2lvbiBvciBldmFsdWF0ZSBhbiBhY2Nlc3MgY29udHJvbCBwb2xp Y3kgd2hpY2ggaXMgYm91bmQgdG8gYQ08YnI+Jmd0OyZndDsgcGFydGljdWxhciBjbGllbnQg KG9yIHJvbGUgb2YgY2xpZW50KS4NPGJyPiZndDsNPGJyPiZndDtTbyB0aGVyZSBtdXN0IGJl IChFLikgYSBzdGFuZGFyZCB3YXkgZm9yIHRoZSBmb3J3YXJkIHByb3h5IHRvIG1ha2UNPGJy PiZndDtyZXF1ZXN0cyB0byB0aGUgb3JpZ2luIHNlcnZlciBvbiBiZWhhbGYgb2YgYW4gYXV0 aG9yaXplZCBjbGllbnQuDTxicj4NPGJyPkVpdGhlciB0aGUgZm9yd2FyZCBwcm94eSBpcyBh dXRob3Jpc2VkIHRvIGFjY2VzcyB0aGUgcmVxdWVzdGVkIHJlc291cmNlIG9yDTxicj5pdCBp cyBub3QuIEkgdGhpbmsgb25lIHJlcXVpcmVtZW50IHNob3VsZCBiZSB0aGF0IGEgZm9yd2Fy ZCBwcm94eSBtYXkgbm90DTxicj5iZSBhdXRob3Jpc2VkIHRvIGFjY2VzcyB0aGUgcmVxdWVz dGVkIHJlc291cmNlLiBJbiB0aGF0IGNhc2UgdGhlcmUgc2hvdWxkDTxicj5iZSAoRS4pIGEg c3RhbmRhcmQgd2F5IGZvciB0aGUgb3JpZ2luIHNlcnZlciB0byBhdXRob3Jpc2UgYSBjbGll bnQgYmVoaW5kDTxicj5hIGZvcndhcmQgcHJveHkgd2l0aG91dCBhdXRob3Jpc2luZyB0aGUg Zm9yd2FyZCBwcm94eS4NPGJyPg08YnI+DTxicj4NPGJyPkfvv73vv71yYW4NPGJyPg08YnI+ DTxicj4mZ3Q7DTxicj4mZ3Q7S2xhdXMNPGJyPiZndDsNPGJyPiZndDtfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw08YnI+Jmd0O0FjZSBtYWlsaW5n IGxpc3QNPGJyPiZndDtBY2VAaWV0Zi5vcmcNPGJyPiZndDtodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Fj ------=_NextPart_53358A08_0D5FE228_34D74CA6-- From nobody Fri Mar 28 07:42:45 2014 Return-Path: <1095318589@qq.com> X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1D1A0639 for ; Fri, 28 Mar 2014 07:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJGcmCHwAEDE for ; Fri, 28 Mar 2014 07:42:36 -0700 (PDT) Received: from smtpproxy19.qq.com (smtpproxy19.qq.com [184.105.206.84]) by ietfa.amsl.com (Postfix) with SMTP id EF3891A06DF for ; Fri, 28 Mar 2014 07:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201307; t=1396017673; bh=xgb+wt2Qr9hy1+oVMg8WR+t9FtxeKAKEJ16ET3+rsA0=; h=X-QQ-mid:X-QQ-mid:X-QQ-SSF:From:To:Cc:Subject:Mime-Version: Content-Type:Content-Transfer-Encoding:Date:X-Priority:Message-ID: X-QQ-MIME:X-Mailer:X-QQ-Mailer:X-QQ-SENDSIZE; b=WHYVjne6oqPw+BNUy1K5wCJ1+i2sQWthH4j1tMhFJe+AUR6CXo/Kf8OaC9QhHEbCw 0IFJdgGcakh5fUrtEk8PEa4Xyqg+BVuUcv8ZNXL03yR5JzNlFJWyMnPp2t+mFSjd0o X/ZDmz/ORz7NAKVrnZkR6scvC+9ljuXdAbLxqOeY= X-QQ-mid: mb25t1396017672t8779771 X-QQ-mid: mb25t1396017672t8779771 X-QQ-SSF: 00000000000000F0F7100300000000L From: "=?utf-8?B?S2VwZW5nIExp?=" <1095318589@qq.com> To: "=?utf-8?B?Z29yYW4uc2VsYW5kZXI=?=" , "=?utf-8?B?aGFydGtl?=" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_53358A08_0D5FE228_34D74CA6" Content-Transfer-Encoding: 8Bit Date: Fri, 28 Mar 2014 22:41:12 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/09JzMnL7TfEHQ2GPs7R4CUs0N3M Cc: =?utf-8?B?QWNl?= Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:42:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_53358A08_0D5FE228_34D74CA6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIGRvbsK5dCB0aGluayB3ZSBuZWVkIHRvIGNvbWUgdG8gYSBjb25jbHVzaW9uIGluIHRo aXMgZGlzY3Vzc2lvbiB0byBhZ3JlZSBvbiB0aGUgY2hhcnRlci4gDQoNCkdvb2QhDQoNCj5X ZSBkb27CuXQgZXZlbiBuZWVkIHRvIG1lbnRpb24gcHJveHkgaW4gdGhlIGNoYXJ0ZXIgYXMg bG9uZyBhcyB3ZSBhZ3JlZSB0byBhbGxvdyB0aGlzIHRvIGltcGFjdCB0aGUgcmVxdWlyZW1l bnRzLg0KDQpJIHRoaW5rIHllcywgdGhpcyB3YXMgbWVudGlvbmVkIGluIEhhbm5lcycgc3Vt bWFyeSBhbHJlYWR5Lg0KDQpLZXBlbmcNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLSDljp/l p4vpgq7ku7YgLS0tLS0tLS0tLS0tLS0tLS0tDQrlj5Hku7bkuro6ICJH77+977+9cmFuIFNl bGFuZGUiIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+Ow0K5Y+R6YCB5pe26Ze0OiAy MDE05bm0M+aciDI45pelKOaYn+acn+S6lCkgMjI6MDINCuaUtuS7tuS6ujogIktsYXVzIEhh cnRrZSIgPGhhcnRrZUB0emkub3JnPjsiS2VwZW5nIExpIiA8MTA5NTMxODU4OUBxcS5jb20+ Ow0K5oqE6YCBOiAiQWNlQGlldGYub3JnIiA8QWNlQGlldGYub3JnPjsNCuS4u+mimDogUmU6 IFtBY2VdIFN1bW1hcnkgb2YgdGhlIFByb3h5IERpc2N1c3Npb24NCg0KDQoNCkhpIEtsYXVz LCBLZWVwaW5nIA0KIA0KS2xhdXM6IEdvb2QgaW5wdXQsIEkgaGF2ZSBzb21lIGNvbW1lbnRz IGlubGluZS4gSSBkaWRu77+977+9dCBpbnRlbmQgdG8gd29yayBvbiANCnRoZSByZXF1aXJl bWVudHMgaGVyZSBhbmQgbm93LCBidXQgc2luY2UgeW91IHN0YXJ0ZWQgLiAuIC4gIFRoZSBw b2ludCBJIA0Kd2FudGVkIHRvIG1ha2Ugd2FzIHRoYXQgdGhlIHByb3h5IGNhc2VzIGhhdmUg YW4gaW1wYWN0IG9uIHRoZSBBQ0UgDQpyZXF1aXJlbWVudHMsIHNvIHNob3VsZCBiZSBpbmNs dWRlZCBpbiB0aGUgd29yayBmcm9tIHRoZSBzdGFydC4gSSBndWVzcyANCnlvdSBhZ3JlZSB0 byB0aGF0PyANCiANCiANCktlcGVuZzogSSBkb27vv73vv710IHRoaW5rIHdlIG5lZWQgdG8g Y29tZSB0byBhIGNvbmNsdXNpb24gaW4gdGhpcyBkaXNjdXNzaW9uIA0KdG8gYWdyZWUgb24g dGhlIGNoYXJ0ZXIuIFdlIGRvbu+/ve+/vXQgZXZlbiBuZWVkIHRvIG1lbnRpb24gcHJveHkg aW4gdGhlIA0KY2hhcnRlciBhcyBsb25nIGFzIHdlIGFncmVlIHRvIGFsbG93IHRoaXMgdG8g aW1wYWN0IHRoZSByZXF1aXJlbWVudHMuIA0KIA0KR++/ve+/vXJhbiANCiANCiANCiANCk9u IDI3LzAzLzE0IDE3OjAwLCAiS2xhdXMgSGFydGtlIiA8aGFydGtlQHR6aS5vcmc+IHdyb3Rl OiANCiANCj5H77+977+9cmFuIFNlbGFuZGVyIHdyb3RlOiANCj4+PkV4YW1wbGUgMTogQ2xp ZW50LS0tT3JpZ2luIFNlcnZlcltleGFtcGxlLm9yZ10gDQo+Pj4gDQo+Pj4xLiBUaGUgY2xp ZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25uZWN0aW9uIHRvIA0K Pj4+ZXhhbXBsZS5vcmcgDQo+Pj4yLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50 YXRpb24gb2YgdGhlIHJlc291cmNlIA0KPj4+ICAgIC9wYXRoL3RvL3Jlc291cmNlIGJ5IHNl bmRpbmcgYSBHRVQgcmVxdWVzdCBtZXNzYWdlIA0KPj4+My4gVGhlIG9yaWdpbiBzZXJ2ZXIg c2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlIHRvIA0KPj4+ dGhlIA0KPj4+Y2xpZW50IA0KPj4gDQo+PiBUaGUgcmVzb3VyY2UgaG9zdCAob3JpZ2luIHNl cnZlcikgYW5kIHRoZSBjbGllbnQgbXV0dWFsbHkgYXV0aGVudGljYXRlcyANCj4+IGFuZCBw cm90ZWN0IHRoZSByZXF1ZXN0L3Jlc3BvbnNlIHVzaW5nIHRoZSBzZWN1cmUgY29ubmVjdGlv bi4gDQo+IA0KPkFuZCB0aGlzIGlzIHByb2JhYmx5IHRoZSBtb3N0IGJhc2ljIHNvbHV0aW9u IHRvIGF1dGhvcml6ZWQgcmVzb3VyY2UgDQo+YWNjZXNzOiBUaGUgb3JpZ2luIHNlcnZlciBj YW4gZGV0ZXJtaW5lIGZvciBlYWNoIHJlcXVlc3QgaWYgdGhlIA0KPmF1dGhlbnRpY2F0ZWQg Y2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gcGVyZm9ybSB0aGUgcmVxdWVzdGVkIGFjdGlvbiBv biANCj50aGUgdGFyZ2V0IHJlc291cmNlIG9yIG5vdC4gDQo+IA0KPlRoZSBpbXBvcnRhbnQg dGhpbmcgdG8gbm90ZSBoZXJlIGlzIHRoYXQgdGhlIG9yaWdpbiBzZXJ2ZXIgaXMgYWN0dWFs bHkgDQo+cGVyZm9ybWluZyB0aHJlZSB0YXNrczogDQo+IA0KPigxLikgYXV0aGVudGljYXRp bmcgb2YgdGhlIGNsaWVudCwgDQo+KDIuKSBoYXZpbmcga25vd2xlZGdlIG9mIHdoaWNoIGFj dGlvbnMgdGhlIF9hdXRoZW50aWNhdGVkXyBjbGllbnQgaXMgDQo+YXV0aG9yaXplZCB0byBw ZXJmb3JtIG9uIHdoaWNoIHJlc291cmNlcywgYW5kIA0KPigzLikgcGVyZm9ybWluZyB0aGUg YWN0aW9uIHJlcXVlc3RlZCBieSBhbiBfYXV0aG9yaXplZF8gY2xpZW50IG9uIGEgDQo+cmVz b3VyY2UuIA0KPiANCj5JZiB0aGUgb3JpZ2luIHNlcnZlciBpcyB0b28gY29uc3RyYWluZWQg dG8gcGVyZm9ybSBhbGwgdGhlc2UgdGFza3MsIA0KPnRoZSBpZGVhIGlzIHRvIG9mZi1sb2Fk IHNvbWUgb2YgdGhlbSAoMS4gYW5kIDIuKSB0byBhIGxlc3MgY29uc3RyYWluZWQgDQo+dGhp cmQgcGFydHkuIA0KPiANCj5UaGVuIHRoZXJlIG11c3QgYmUgYSBzdGFuZGFyZCB3YXkgZm9y IHRoZSBjbGllbnQgdG8gKEEuKSBzZWN1cmVseSANCj5kaXNjb3ZlciB0aGUgdGhpcmQgcGFy dHksIChCLikgcGVyZm9ybSBzdGVwcyB0byBmaXJzdCBiZWNvbWUgYW4gDQo+YXV0aGVudGlj YXRlZCBjbGllbnQgYW5kIHRoZW4gYW4gYXV0aG9yaXplZCBjbGllbnQsIGFuZCBmaW5hbGx5 IChDLikgDQo+dG8gbWFrZSBhIHJlcXVlc3QgYXMgYW4gYXV0aG9yaXplZCAoYnV0IG5vdCBu ZWNlc3NhcmlseSBhdXRoZW50aWNhdGVkKSANCj5jbGllbnQuIA0KPiANCj4+PkV4YW1wbGUg MjogQ2xpZW50LS0tUmV2ZXJzZSBQcm94eVtleGFtcGxlLm9yZ10tLS1PcmlnaW4gDQo+Pj5T ZXJ2ZXJbZXhhbXBsZS5uZXRdIA0KPj4+IA0KPj4+MS4gVGhlIGNsaWVudCByZXNvbHZlcyBh bmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbiB0byANCj4+PmV4YW1wbGUub3Jn IA0KPj4+Mi4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBy ZXNvdXJjZSANCj4+Pi9wYXRoL3RvL3Jlc291cmNlIA0KPj4+My4gVGhlIHJldmVyc2UgcHJv eHkgY2hvb3NlcyB0byBzYXRpc2Z5IHRoZSByZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUgDQo+ Pj4gICAgcmVwcmVzZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUubmV0L3Nv bWUvb3RoZXIvcmVzb3VyY2UgDQo+Pj4gICAgYS4gVGhlIHJldmVyc2UgcHJveHkgcmVzb2x2 ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24gDQo+Pj4gICAgICAgIHRv IGV4YW1wbGUubmV0IA0KPj4+ICAgIGIuIFRoZSByZXZlcnNlIHByb3h5IHJlcXVlc3RzIGEg cmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlIA0KPj4+ICAgICAgICAvc29tZS9vdGhl ci9yZXNvdXJjZSANCj4+PiAgICBjLiBUaGUgb3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhl IHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2FsIGZpbGUgDQo+Pj4gICAgICAgIHRvIHRoZSBy ZXZlcnNlIHByb3h5IA0KPj4+NC4gVGhlIHJldmVyc2UgcHJveGllcyBzZXJ2ZXMgdGhlIHJl cHJlc2VudGF0aW9uIHRvIHRoZSBjbGllbnQgDQo+PiANCj4+IEluIHRoaXMgY2FzZSwgdGhl IHJlcXVlc3RlZCByZXNvdXJjZSwgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgDQo+ PiBjbGllbnQsIGlzIGhvc3RlZCBieSB0aGUgcmV2ZXJzZSBwcm94eSwgYmV0d2VlbiB3aGlj aCB0aGVyZSBjYW4gYmUgDQo+Pm11dHVhbCANCj4+IGF1dGhlbnRpY2F0aW9uIGFuZCBzZWN1 cmUgY29ubmVjdGlvbi4gV2hlcmUgdGhlIHJldmVyc2UgcHJveHkgZ2V0cyBhIA0KPj4gcmVw cmVzZW50YXRpb24gZnJvbSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGNsaWVudC4gDQo+IA0K Pkl0IG1heSBiZSB0aGUgb3JpZ2luIHNlcnZlciBbZXhhbXBsZS5uZXRdLCB0aG91Z2gsIHdo aWNoIGhhcyB0aGUgDQo+a25vd2xlZGdlIG9mIHdoaWNoIGFjdGlvbnMgdGhlIGNsaWVudCAo d2hpY2ggYXV0aGVudGljYXRlZCB0byB0aGUgDQo+cmV2ZXJzZSBwcm94eSBbZXhhbXBsZS5v cmddKSBpcyBhdXRob3JpemVkIHRvIHBlcmZvcm0gb24gd2hpY2ggDQo+cmVzb3VyY2VzLiBU aGUgcmV2ZXJzZSBwcm94eSBjb3VsZCBtZXJlbHkgYWN0IGFzIGEgc2ltcGxlIGNhY2hlIGlu IA0KPmZyb250IG9mIHRoZSBvcmlnaW4gc2VydmVyLiANCiANCkluIHlvdXIgZXhhbXBsZSwg dGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFjY2VzcyB0byANCmV4YW1wbGUub3JnL3BhdGgv dG8vcmVzb3VyY2UuIERvIHlvdSBwcm9wb3NlIHRoZSBjbGllbnQgc2hvdWxkIHRoZXJlYnkg DQphY3F1aXJlIHJpZ2h0cyB0byBhY2Nlc3MgZXhhbXBsZS5uZXQvc29tZS9vdGhlci9yZXNv dXJjZS4gU2hvdWxkIHRoZSANCmNsaWVudHMgaGF2ZSByaWdodHMgdG8gYWNjZXNzIGJvdGgg dGhlc2UgcmVzb3VyY2VzPyBTYW1lIHByaXZpbGVnZXM/IA0KU2hvdWxkIHRoZSBBUyBrZWVw IHRyYWNrIG9mIHRoZSBhc3NvY2lhdGlvbj8gQW4gYWx0ZXJuYXRpdmUgaXMgdGhhdCB0aGUg DQpyZXZlcnNlIHByb3h5IGhhcyByaWdodHMgdG8gYWNjZXNzL3N1YnNjcmliZSB0byANCmV4 YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVzb3VyY2UuIA0KIA0KPiANCj5TbyB0aGVyZSBtdXN0 IGJlIChELikgYSBzdGFuZGFyZCB3YXkgZm9yIHRoZSByZXZlcnNlIHByb3h5IHRvIG1ha2Ug DQo+cmVxdWVzdHMgdG8gdGhlIG9yaWdpbiBzZXJ2ZXIgb24gYmVoYWxmIG9mIGFuIGF1dGhv cml6ZWQgY2xpZW50LiANCiANCk9uZSBhbHRlcm5hdGl2ZSBpbnRlcnByZXRhdGlvbiBpcyB0 aGF0IGl0IGlzIG5vdCDvv73vv71vbiBiZWhhbGbvv73vv70sIHRoaXMgaXQgdGhlIA0KcmV2 ZXJzZSBwcm94eSB3aGljaCBpbiBpdHMgb3duIHJpZ2h0cyAoPWJlaW5nIGEgcmV2ZXJzZSBw cm94eSkgaGF2ZSBhY2Nlc3MgDQp0byB0aGUgb3JpZ2luIHNlcnZlci4gVGhlbiBEIHdvdWxk IGNvaW5jaWRlIHdpdGggYW55IG90aGVyIGFjY2VzcyByZXF1ZXN0LiANCiANCj4gDQo+Pj5F eGFtcGxlIDM6IENsaWVudC0tLUZvcndhcmQgUHJveHlbcHJveHkuZXhhbXBsZV0tLS1Pcmln aW4gDQo+Pj5TZXJ2ZXJbZXhhbXBsZS5vcmddIA0KPj4+IA0KPj4+MS4gVGhlIGNsaWVudCBy ZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbiB0byANCj4+PnBy b3h5LmV4YW1wbGUgDQo+Pj4yLiBUaGUgY2xpZW50IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRp b24gb2YgdGhlIHJlc291cmNlIA0KPj4+ICAgIHtjb2FwcyxodHRwc306Ly9leGFtcGxlLm9y Zy9wYXRoL3RvL3Jlc291cmNlIA0KPj4+My4gVGhlIGZvcndhcmQgcHJveHkgc2F0aXNmaWVz IHRoZSByZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUgDQo+Pj4gICAgcmVwcmVzZW50YXRpb24g b2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUub3JnL3BhdGgvdG8vcmVzb3VyY2UgDQo+Pj4g ICAgYS4gVGhlIGZvcndhcmQgcHJveHkgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2Vj dXJlIGNvbm5lY3Rpb24gDQo+Pj4gICAgICAgIHRvIGV4YW1wbGUub3JnIA0KPj4+ICAgIGIu IFRoZSBmb3J3YXJkIHByb3h5IHJlcXVlc3RzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJl c291cmNlIA0KPj4+ICAgICAgICAvcGF0aC90by9yZXNvdXJjZSANCj4+PiAgICBjLiBUaGUg b3JpZ2luIHNlcnZlciBzYXRpc2ZpZXMgdGhlIHJlcXVlc3QgYnkgc2VydmluZyBhIGxvY2Fs IGZpbGUgDQo+Pj4gICAgICAgIHRvIHRoZSBmb3J3YXJkIHByb3h5IA0KPj4+NC4gVGhlIGZv cndhcmQgcHJveHkgc2VydmVzIHRoZSByZXByZXNlbnRhdGlvbiB0byB0aGUgY2xpZW50IA0K Pj4gDQo+PiBJbiB0aGlzIGNhc2UsIHRoZSBmb3J3YXJkIHByb3h5IGFuZCBjbGllbnQgbXV0 dWFsbHkgYXV0aGVudGljYXRlcyBhbmQgDQo+PiBlc3RhYmxpc2ggc2VjdXJlIGNvbm5lY3Rp b24sIGFzIGRvZXMgZm9yd2FyZCBwcm94eSBhbmQgcmVzb3VyY2UgaG9zdCANCj4+IChvcmln aW4gc2VydmVyKS4gDQo+IA0KPkl0IGlzIG5vdGV3b3J0aHkgaGVyZSB0aGF0IHRoZSBjbGll bnQgY2FuIG9ubHkgcmVxdWVzdCB0aGUgZm9yd2FyZCANCj5wcm94eSB0byBtYWtlIGl0cyBy ZXF1ZXN0IHRvIHRoZSBvcmlnaW4gc2VydmVyIHNlY3VyZWx5IChieSBzcGVjaWZ5aW5nIA0K PnRoZSAiY29hcHMiIHNjaGVtZSkuIEl0IGhhcyBubyBpbmZsdWVuY2Ugb24gYWNjZXB0YWJs ZSBjaXBoZXIgc3VpdHMsIA0KPmNlcnRpZmljYXRlIHJvb3RzLCBldGMuIFRoZSBjbGllbnQg aGFzIHRvIHRydXN0IHRoZSBmb3J3YXJkIHByb3h5IHRoYXQgDQo+aXQgc2VjdXJlcyB0aGUg Y29ubmVjdGlvbiB0byB0aGUgb3JpZ2luIHNlcnZlciBpbiBhIHdheSB0aGF0IGlzIA0KPmFj Y2VwdGFibGUgdG8gdGhlIGNsaWVudC4gDQo+IA0KPj4gV2l0aCB0aGUgbWVjaGFuaXNtcyBk ZXNjcmliZWQgaW4gdGhpcyBleGFtcGxlLCB0aGUgDQo+PiByZXNvdXJjZSBob3N0IGRvZXMg bm90IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCBzbyBzb21lIGFkZGl0aW9uYWwgDQo+PiBz ZWN1cml0eSBpcyBuZWVkZWQgZm9yIHRoZSBvcmlnaW4gc2VydmVyIHRvIGVuZm9yY2UgYW4g YWNjZXNzIGNvbnRyb2wgDQo+PiBkZWNpc2lvbiBvciBldmFsdWF0ZSBhbiBhY2Nlc3MgY29u dHJvbCBwb2xpY3kgd2hpY2ggaXMgYm91bmQgdG8gYSANCj4+IHBhcnRpY3VsYXIgY2xpZW50 IChvciByb2xlIG9mIGNsaWVudCkuIA0KPiANCj5TbyB0aGVyZSBtdXN0IGJlIChFLikgYSBz dGFuZGFyZCB3YXkgZm9yIHRoZSBmb3J3YXJkIHByb3h5IHRvIG1ha2UgDQo+cmVxdWVzdHMg dG8gdGhlIG9yaWdpbiBzZXJ2ZXIgb24gYmVoYWxmIG9mIGFuIGF1dGhvcml6ZWQgY2xpZW50 LiANCiANCkVpdGhlciB0aGUgZm9yd2FyZCBwcm94eSBpcyBhdXRob3Jpc2VkIHRvIGFjY2Vz cyB0aGUgcmVxdWVzdGVkIHJlc291cmNlIG9yIA0KaXQgaXMgbm90LiBJIHRoaW5rIG9uZSBy ZXF1aXJlbWVudCBzaG91bGQgYmUgdGhhdCBhIGZvcndhcmQgcHJveHkgbWF5IG5vdCANCmJl IGF1dGhvcmlzZWQgdG8gYWNjZXNzIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UuIEluIHRoYXQg Y2FzZSB0aGVyZSBzaG91bGQgDQpiZSAoRS4pIGEgc3RhbmRhcmQgd2F5IGZvciB0aGUgb3Jp Z2luIHNlcnZlciB0byBhdXRob3Jpc2UgYSBjbGllbnQgYmVoaW5kIA0KYSBmb3J3YXJkIHBy b3h5IHdpdGhvdXQgYXV0aG9yaXNpbmcgdGhlIGZvcndhcmQgcHJveHkuIA0KIA0KIA0KIA0K R++/ve+/vXJhbiANCiANCiANCj4gDQo+S2xhdXMgDQo+IA0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0KPkFjZSBtYWlsaW5nIGxpc3QgDQo+ QWNlQGlldGYub3JnIA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWM= ------=_NextPart_53358A08_0D5FE228_34D74CA6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 Jmd0OyBJIGRvbsK5dCB0aGluayB3ZSBuZWVkIHRvIGNvbWUgdG8gYSBjb25jbHVzaW9uIGlu IHRoaXMgZGlzY3Vzc2lvbiB0byBhZ3JlZSBvbiB0aGUgY2hhcnRlci4gPGJyPjxicj5Hb29k ITxicj48YnI+Jmd0O1dlIGRvbsK5dCBldmVuIG5lZWQgdG8gbWVudGlvbiBwcm94eSBpbiB0 aGUgY2hhcnRlciBhcyBsb25nIGFzIHdlIGFncmVlIHRvIGFsbG93IHRoaXMgdG8gaW1wYWN0 IHRoZSByZXF1aXJlbWVudHMuPGJyPjxicj5JIHRoaW5rIHllcywgdGhpcyB3YXMgbWVudGlv bmVkIGluIEhhbm5lcycgc3VtbWFyeSBhbHJlYWR5Ljxicj48YnI+S2VwZW5nPGJyPjxicj48 YnIvPjxici8+LS0tLS0tLS0tLS0tLS0tLS0tIOWOn+Wni+mCruS7tiAtLS0tLS0tLS0tLS0t LS0tLS08YnIvPjxIVE1MPjxCT0RZPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFj a2dyb3VuZDogbm9uZSByZXBlYXQgc2Nyb2xsIDAlIHJnYigyMzksIDIzOSwgMjM5KTsgcGFk ZGluZzogOHB4OyI+PGRpdiBpZD0ibWVudV9zZW5kZXIiPjxiPuWPkeS7tuS6ujo8L2I+Jm5i c3A7Ikfvv73vv71yYW4gU2VsYW5kZSIgJmx0O2dvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNv bSZndDs7PC9kaXY+PGRpdj48Yj7lj5HpgIHml7bpl7Q6PC9iPiZuYnNwOzIwMTTlubQz5pyI Mjjml6Uo5pif5pyf5LqUKSAyMjowMjwvZGl2PjxkaXY+PGI+5pS25Lu25Lq6OjwvYj4mbmJz cDsiS2xhdXMgSGFydGtlIiAmbHQ7aGFydGtlQHR6aS5vcmcmZ3Q7OyJLZXBlbmcgTGkiICZs dDsxMDk1MzE4NTg5QHFxLmNvbSZndDs7PC9kaXY+PGRpdj48Yj7mioTpgIE6PC9iPiZuYnNw OyJBY2VAaWV0Zi5vcmciICZsdDtBY2VAaWV0Zi5vcmcmZ3Q7OzwvZGl2PjxkaXY+PGI+5Li7 6aKYOjwvYj4mbmJzcDtSZTogW0FjZV0gU3VtbWFyeSBvZiB0aGUgUHJveHkgRGlzY3Vzc2lv bjwvZGl2PjwvZGl2PjwvQk9EWT48L0hUTUw+PGJyLz48YnIvPkhpIEtsYXVzLCBLZWVwaW5n DTxicj4NPGJyPktsYXVzOiBHb29kIGlucHV0LCBJIGhhdmUgc29tZSBjb21tZW50cyBpbmxp bmUuIEkgZGlkbu+/ve+/vXQgaW50ZW5kIHRvIHdvcmsgb24NPGJyPnRoZSByZXF1aXJlbWVu dHMgaGVyZSBhbmQgbm93LCBidXQgc2luY2UgeW91IHN0YXJ0ZWQgLiAuIC4mbmJzcDsgVGhl IHBvaW50IEkNPGJyPndhbnRlZCB0byBtYWtlIHdhcyB0aGF0IHRoZSBwcm94eSBjYXNlcyBo YXZlIGFuIGltcGFjdCBvbiB0aGUgQUNFDTxicj5yZXF1aXJlbWVudHMsIHNvIHNob3VsZCBi ZSBpbmNsdWRlZCBpbiB0aGUgd29yayBmcm9tIHRoZSBzdGFydC4gSSBndWVzcw08YnI+eW91 IGFncmVlIHRvIHRoYXQ/DTxicj4NPGJyPg08YnI+S2VwZW5nOiBJIGRvbu+/ve+/vXQgdGhp bmsgd2UgbmVlZCB0byBjb21lIHRvIGEgY29uY2x1c2lvbiBpbiB0aGlzIGRpc2N1c3Npb24N PGJyPnRvIGFncmVlIG9uIHRoZSBjaGFydGVyLiBXZSBkb27vv73vv710IGV2ZW4gbmVlZCB0 byBtZW50aW9uIHByb3h5IGluIHRoZQ08YnI+Y2hhcnRlciBhcyBsb25nIGFzIHdlIGFncmVl IHRvIGFsbG93IHRoaXMgdG8gaW1wYWN0IHRoZSByZXF1aXJlbWVudHMuDTxicj4NPGJyPkfv v73vv71yYW4NPGJyPg08YnI+DTxicj4NPGJyPk9uIDI3LzAzLzE0IDE3OjAwLCAiS2xhdXMg SGFydGtlIiAmbHQ7aGFydGtlQHR6aS5vcmcmZ3Q7IHdyb3RlOg08YnI+DTxicj4mZ3Q7R++/ ve+/vXJhbiBTZWxhbmRlciB3cm90ZToNPGJyPiZndDsmZ3Q7Jmd0O0V4YW1wbGUgMTogQ2xp ZW50LS0tT3JpZ2luIFNlcnZlcltleGFtcGxlLm9yZ10NPGJyPiZndDsmZ3Q7Jmd0Ow08YnI+ Jmd0OyZndDsmZ3Q7MS4gVGhlIGNsaWVudCByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBz ZWN1cmUgY29ubmVjdGlvbiB0bw08YnI+Jmd0OyZndDsmZ3Q7ZXhhbXBsZS5vcmcNPGJyPiZn dDsmZ3Q7Jmd0OzIuIFRoZSBjbGllbnQgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0 aGUgcmVzb3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAvcGF0aC90 by9yZXNvdXJjZSBieSBzZW5kaW5nIGEgR0VUIHJlcXVlc3QgbWVzc2FnZQ08YnI+Jmd0OyZn dDsmZ3Q7My4gVGhlIG9yaWdpbiBzZXJ2ZXIgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNl cnZpbmcgYSBsb2NhbCBmaWxlIHRvDTxicj4mZ3Q7Jmd0OyZndDt0aGUNPGJyPiZndDsmZ3Q7 Jmd0O2NsaWVudA08YnI+Jmd0OyZndDsNPGJyPiZndDsmZ3Q7IFRoZSByZXNvdXJjZSBob3N0 IChvcmlnaW4gc2VydmVyKSBhbmQgdGhlIGNsaWVudCBtdXR1YWxseSBhdXRoZW50aWNhdGVz DTxicj4mZ3Q7Jmd0OyBhbmQgcHJvdGVjdCB0aGUgcmVxdWVzdC9yZXNwb25zZSB1c2luZyB0 aGUgc2VjdXJlIGNvbm5lY3Rpb24uDTxicj4mZ3Q7DTxicj4mZ3Q7QW5kIHRoaXMgaXMgcHJv YmFibHkgdGhlIG1vc3QgYmFzaWMgc29sdXRpb24gdG8gYXV0aG9yaXplZCByZXNvdXJjZQ08 YnI+Jmd0O2FjY2VzczogVGhlIG9yaWdpbiBzZXJ2ZXIgY2FuIGRldGVybWluZSBmb3IgZWFj aCByZXF1ZXN0IGlmIHRoZQ08YnI+Jmd0O2F1dGhlbnRpY2F0ZWQgY2xpZW50IGlzIGF1dGhv cml6ZWQgdG8gcGVyZm9ybSB0aGUgcmVxdWVzdGVkIGFjdGlvbiBvbg08YnI+Jmd0O3RoZSB0 YXJnZXQgcmVzb3VyY2Ugb3Igbm90Lg08YnI+Jmd0Ow08YnI+Jmd0O1RoZSBpbXBvcnRhbnQg dGhpbmcgdG8gbm90ZSBoZXJlIGlzIHRoYXQgdGhlIG9yaWdpbiBzZXJ2ZXIgaXMgYWN0dWFs bHkNPGJyPiZndDtwZXJmb3JtaW5nIHRocmVlIHRhc2tzOg08YnI+Jmd0Ow08YnI+Jmd0Oygx LikgYXV0aGVudGljYXRpbmcgb2YgdGhlIGNsaWVudCwNPGJyPiZndDsoMi4pIGhhdmluZyBr bm93bGVkZ2Ugb2Ygd2hpY2ggYWN0aW9ucyB0aGUgX2F1dGhlbnRpY2F0ZWRfIGNsaWVudCBp cw08YnI+Jmd0O2F1dGhvcml6ZWQgdG8gcGVyZm9ybSBvbiB3aGljaCByZXNvdXJjZXMsIGFu ZA08YnI+Jmd0OygzLikgcGVyZm9ybWluZyB0aGUgYWN0aW9uIHJlcXVlc3RlZCBieSBhbiBf YXV0aG9yaXplZF8gY2xpZW50IG9uIGENPGJyPiZndDtyZXNvdXJjZS4NPGJyPiZndDsNPGJy PiZndDtJZiB0aGUgb3JpZ2luIHNlcnZlciBpcyB0b28gY29uc3RyYWluZWQgdG8gcGVyZm9y bSBhbGwgdGhlc2UgdGFza3MsDTxicj4mZ3Q7dGhlIGlkZWEgaXMgdG8gb2ZmLWxvYWQgc29t ZSBvZiB0aGVtICgxLiBhbmQgMi4pIHRvIGEgbGVzcyBjb25zdHJhaW5lZA08YnI+Jmd0O3Ro aXJkIHBhcnR5Lg08YnI+Jmd0Ow08YnI+Jmd0O1RoZW4gdGhlcmUgbXVzdCBiZSBhIHN0YW5k YXJkIHdheSBmb3IgdGhlIGNsaWVudCB0byAoQS4pIHNlY3VyZWx5DTxicj4mZ3Q7ZGlzY292 ZXIgdGhlIHRoaXJkIHBhcnR5LCAoQi4pIHBlcmZvcm0gc3RlcHMgdG8gZmlyc3QgYmVjb21l IGFuDTxicj4mZ3Q7YXV0aGVudGljYXRlZCBjbGllbnQgYW5kIHRoZW4gYW4gYXV0aG9yaXpl ZCBjbGllbnQsIGFuZCBmaW5hbGx5IChDLikNPGJyPiZndDt0byBtYWtlIGEgcmVxdWVzdCBh cyBhbiBhdXRob3JpemVkIChidXQgbm90IG5lY2Vzc2FyaWx5IGF1dGhlbnRpY2F0ZWQpDTxi cj4mZ3Q7Y2xpZW50Lg08YnI+Jmd0Ow08YnI+Jmd0OyZndDsmZ3Q7RXhhbXBsZSAyOiBDbGll bnQtLS1SZXZlcnNlIFByb3h5W2V4YW1wbGUub3JnXS0tLU9yaWdpbg08YnI+Jmd0OyZndDsm Z3Q7U2VydmVyW2V4YW1wbGUubmV0XQ08YnI+Jmd0OyZndDsmZ3Q7DTxicj4mZ3Q7Jmd0OyZn dDsxLiBUaGUgY2xpZW50IHJlc29sdmVzIGFuZCBlc3RhYmxpc2hlcyBhIHNlY3VyZSBjb25u ZWN0aW9uIHRvDTxicj4mZ3Q7Jmd0OyZndDtleGFtcGxlLm9yZw08YnI+Jmd0OyZndDsmZ3Q7 Mi4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJj ZQ08YnI+Jmd0OyZndDsmZ3Q7L3BhdGgvdG8vcmVzb3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OzMu IFRoZSByZXZlcnNlIHByb3h5IGNob29zZXMgdG8gc2F0aXNmeSB0aGUgcmVxdWVzdCBieSBv YnRhaW5pbmcgdGhlDTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwcmVz ZW50YXRpb24gb2Yge2NvYXBzLGh0dHBzfTovL2V4YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVz b3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhLiBUaGUgcmV2ZXJz ZSBwcm94eSByZXNvbHZlcyBhbmQgZXN0YWJsaXNoZXMgYSBzZWN1cmUgY29ubmVjdGlvbg08 YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRvIGV4YW1wbGUubmV0DTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg Yi4gVGhlIHJldmVyc2UgcHJveHkgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUg cmVzb3VyY2UNPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAvc29tZS9vdGhlci9yZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGMuIFRoZSBvcmlnaW4gc2VydmVyIHNhdGlzZmllcyB0aGUgcmVx dWVzdCBieSBzZXJ2aW5nIGEgbG9jYWwgZmlsZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIHRoZSByZXZlcnNlIHByb3h5 DTxicj4mZ3Q7Jmd0OyZndDs0LiBUaGUgcmV2ZXJzZSBwcm94aWVzIHNlcnZlcyB0aGUgcmVw cmVzZW50YXRpb24gdG8gdGhlIGNsaWVudA08YnI+Jmd0OyZndDsNPGJyPiZndDsmZ3Q7IElu IHRoaXMgY2FzZSwgdGhlIHJlcXVlc3RlZCByZXNvdXJjZSwgZnJvbSB0aGUgcG9pbnQgb2Yg dmlldyBvZiB0aGUNPGJyPiZndDsmZ3Q7IGNsaWVudCwgaXMgaG9zdGVkIGJ5IHRoZSByZXZl cnNlIHByb3h5LCBiZXR3ZWVuIHdoaWNoIHRoZXJlIGNhbiBiZQ08YnI+Jmd0OyZndDttdXR1 YWwNPGJyPiZndDsmZ3Q7IGF1dGhlbnRpY2F0aW9uIGFuZCBzZWN1cmUgY29ubmVjdGlvbi4g V2hlcmUgdGhlIHJldmVyc2UgcHJveHkgZ2V0cyBhDTxicj4mZ3Q7Jmd0OyByZXByZXNlbnRh dGlvbiBmcm9tIGlzIG91dCBvZiBzY29wZSBvZiB0aGUgY2xpZW50Lg08YnI+Jmd0Ow08YnI+ Jmd0O0l0IG1heSBiZSB0aGUgb3JpZ2luIHNlcnZlciBbZXhhbXBsZS5uZXRdLCB0aG91Z2gs IHdoaWNoIGhhcyB0aGUNPGJyPiZndDtrbm93bGVkZ2Ugb2Ygd2hpY2ggYWN0aW9ucyB0aGUg Y2xpZW50ICh3aGljaCBhdXRoZW50aWNhdGVkIHRvIHRoZQ08YnI+Jmd0O3JldmVyc2UgcHJv eHkgW2V4YW1wbGUub3JnXSkgaXMgYXV0aG9yaXplZCB0byBwZXJmb3JtIG9uIHdoaWNoDTxi cj4mZ3Q7cmVzb3VyY2VzLiBUaGUgcmV2ZXJzZSBwcm94eSBjb3VsZCBtZXJlbHkgYWN0IGFz IGEgc2ltcGxlIGNhY2hlIGluDTxicj4mZ3Q7ZnJvbnQgb2YgdGhlIG9yaWdpbiBzZXJ2ZXIu DTxicj4NPGJyPkluIHlvdXIgZXhhbXBsZSwgdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFj Y2VzcyB0bw08YnI+ZXhhbXBsZS5vcmcvcGF0aC90by9yZXNvdXJjZS4gRG8geW91IHByb3Bv c2UgdGhlIGNsaWVudCBzaG91bGQgdGhlcmVieQ08YnI+YWNxdWlyZSByaWdodHMgdG8gYWNj ZXNzIGV4YW1wbGUubmV0L3NvbWUvb3RoZXIvcmVzb3VyY2UuIFNob3VsZCB0aGUNPGJyPmNs aWVudHMgaGF2ZSByaWdodHMgdG8gYWNjZXNzIGJvdGggdGhlc2UgcmVzb3VyY2VzPyBTYW1l IHByaXZpbGVnZXM/DTxicj5TaG91bGQgdGhlIEFTIGtlZXAgdHJhY2sgb2YgdGhlIGFzc29j aWF0aW9uPyBBbiBhbHRlcm5hdGl2ZSBpcyB0aGF0IHRoZQ08YnI+cmV2ZXJzZSBwcm94eSBo YXMgcmlnaHRzIHRvIGFjY2Vzcy9zdWJzY3JpYmUgdG8NPGJyPmV4YW1wbGUubmV0L3NvbWUv b3RoZXIvcmVzb3VyY2UuDTxicj4NPGJyPiZndDsNPGJyPiZndDtTbyB0aGVyZSBtdXN0IGJl IChELikgYSBzdGFuZGFyZCB3YXkgZm9yIHRoZSByZXZlcnNlIHByb3h5IHRvIG1ha2UNPGJy PiZndDtyZXF1ZXN0cyB0byB0aGUgb3JpZ2luIHNlcnZlciBvbiBiZWhhbGYgb2YgYW4gYXV0 aG9yaXplZCBjbGllbnQuDTxicj4NPGJyPk9uZSBhbHRlcm5hdGl2ZSBpbnRlcnByZXRhdGlv biBpcyB0aGF0IGl0IGlzIG5vdCDvv73vv71vbiBiZWhhbGbvv73vv70sIHRoaXMgaXQgdGhl DTxicj5yZXZlcnNlIHByb3h5IHdoaWNoIGluIGl0cyBvd24gcmlnaHRzICg9YmVpbmcgYSBy ZXZlcnNlIHByb3h5KSBoYXZlIGFjY2Vzcw08YnI+dG8gdGhlIG9yaWdpbiBzZXJ2ZXIuIFRo ZW4gRCB3b3VsZCBjb2luY2lkZSB3aXRoIGFueSBvdGhlciBhY2Nlc3MgcmVxdWVzdC4NPGJy Pg08YnI+Jmd0Ow08YnI+Jmd0OyZndDsmZ3Q7RXhhbXBsZSAzOiBDbGllbnQtLS1Gb3J3YXJk IFByb3h5W3Byb3h5LmV4YW1wbGVdLS0tT3JpZ2luDTxicj4mZ3Q7Jmd0OyZndDtTZXJ2ZXJb ZXhhbXBsZS5vcmddDTxicj4mZ3Q7Jmd0OyZndDsNPGJyPiZndDsmZ3Q7Jmd0OzEuIFRoZSBj bGllbnQgcmVzb2x2ZXMgYW5kIGVzdGFibGlzaGVzIGEgc2VjdXJlIGNvbm5lY3Rpb24gdG8N PGJyPiZndDsmZ3Q7Jmd0O3Byb3h5LmV4YW1wbGUNPGJyPiZndDsmZ3Q7Jmd0OzIuIFRoZSBj bGllbnQgcmVxdWVzdHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzb3VyY2UNPGJyPiZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB7Y29hcHMsaHR0cHN9Oi8vZXhhbXBsZS5v cmcvcGF0aC90by9yZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7My4gVGhlIGZvcndhcmQgcHJv eHkgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IG9idGFpbmluZyB0aGUNPGJyPiZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyByZXByZXNlbnRhdGlvbiBvZiB7Y29hcHMsaHR0cHN9 Oi8vZXhhbXBsZS5vcmcvcGF0aC90by9yZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGEuIFRoZSBmb3J3YXJkIHByb3h5IHJlc29sdmVzIGFuZCBlc3RhYmxp c2hlcyBhIHNlY3VyZSBjb25uZWN0aW9uDTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gZXhhbXBsZS5vcmcNPGJyPiZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBiLiBUaGUgZm9yd2FyZCBwcm94eSByZXF1ZXN0 cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJjZQ08YnI+Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9wYXRoL3RvL3Jlc291 cmNlDTxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYy4gVGhlIG9yaWdpbiBz ZXJ2ZXIgc2F0aXNmaWVzIHRoZSByZXF1ZXN0IGJ5IHNlcnZpbmcgYSBsb2NhbCBmaWxlDTxi cj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdG8gdGhlIGZvcndhcmQgcHJveHkNPGJyPiZndDsmZ3Q7Jmd0OzQuIFRoZSBmb3J3YXJk IHByb3h5IHNlcnZlcyB0aGUgcmVwcmVzZW50YXRpb24gdG8gdGhlIGNsaWVudA08YnI+Jmd0 OyZndDsNPGJyPiZndDsmZ3Q7IEluIHRoaXMgY2FzZSwgdGhlIGZvcndhcmQgcHJveHkgYW5k IGNsaWVudCBtdXR1YWxseSBhdXRoZW50aWNhdGVzIGFuZA08YnI+Jmd0OyZndDsgZXN0YWJs aXNoIHNlY3VyZSBjb25uZWN0aW9uLCBhcyBkb2VzIGZvcndhcmQgcHJveHkgYW5kIHJlc291 cmNlIGhvc3QNPGJyPiZndDsmZ3Q7IChvcmlnaW4gc2VydmVyKS4NPGJyPiZndDsNPGJyPiZn dDtJdCBpcyBub3Rld29ydGh5IGhlcmUgdGhhdCB0aGUgY2xpZW50IGNhbiBvbmx5IHJlcXVl c3QgdGhlIGZvcndhcmQNPGJyPiZndDtwcm94eSB0byBtYWtlIGl0cyByZXF1ZXN0IHRvIHRo ZSBvcmlnaW4gc2VydmVyIHNlY3VyZWx5IChieSBzcGVjaWZ5aW5nDTxicj4mZ3Q7dGhlICJj b2FwcyIgc2NoZW1lKS4gSXQgaGFzIG5vIGluZmx1ZW5jZSBvbiBhY2NlcHRhYmxlIGNpcGhl ciBzdWl0cywNPGJyPiZndDtjZXJ0aWZpY2F0ZSByb290cywgZXRjLiBUaGUgY2xpZW50IGhh cyB0byB0cnVzdCB0aGUgZm9yd2FyZCBwcm94eSB0aGF0DTxicj4mZ3Q7aXQgc2VjdXJlcyB0 aGUgY29ubmVjdGlvbiB0byB0aGUgb3JpZ2luIHNlcnZlciBpbiBhIHdheSB0aGF0IGlzDTxi cj4mZ3Q7YWNjZXB0YWJsZSB0byB0aGUgY2xpZW50Lg08YnI+Jmd0Ow08YnI+Jmd0OyZndDsg V2l0aCB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhpcyBleGFtcGxlLCB0aGUNPGJy PiZndDsmZ3Q7IHJlc291cmNlIGhvc3QgZG9lcyBub3QgYXV0aGVudGljYXRlIHRoZSBjbGll bnQsIHNvIHNvbWUgYWRkaXRpb25hbA08YnI+Jmd0OyZndDsgc2VjdXJpdHkgaXMgbmVlZGVk IGZvciB0aGUgb3JpZ2luIHNlcnZlciB0byBlbmZvcmNlIGFuIGFjY2VzcyBjb250cm9sDTxi cj4mZ3Q7Jmd0OyBkZWNpc2lvbiBvciBldmFsdWF0ZSBhbiBhY2Nlc3MgY29udHJvbCBwb2xp Y3kgd2hpY2ggaXMgYm91bmQgdG8gYQ08YnI+Jmd0OyZndDsgcGFydGljdWxhciBjbGllbnQg KG9yIHJvbGUgb2YgY2xpZW50KS4NPGJyPiZndDsNPGJyPiZndDtTbyB0aGVyZSBtdXN0IGJl IChFLikgYSBzdGFuZGFyZCB3YXkgZm9yIHRoZSBmb3J3YXJkIHByb3h5IHRvIG1ha2UNPGJy PiZndDtyZXF1ZXN0cyB0byB0aGUgb3JpZ2luIHNlcnZlciBvbiBiZWhhbGYgb2YgYW4gYXV0 aG9yaXplZCBjbGllbnQuDTxicj4NPGJyPkVpdGhlciB0aGUgZm9yd2FyZCBwcm94eSBpcyBh dXRob3Jpc2VkIHRvIGFjY2VzcyB0aGUgcmVxdWVzdGVkIHJlc291cmNlIG9yDTxicj5pdCBp cyBub3QuIEkgdGhpbmsgb25lIHJlcXVpcmVtZW50IHNob3VsZCBiZSB0aGF0IGEgZm9yd2Fy ZCBwcm94eSBtYXkgbm90DTxicj5iZSBhdXRob3Jpc2VkIHRvIGFjY2VzcyB0aGUgcmVxdWVz dGVkIHJlc291cmNlLiBJbiB0aGF0IGNhc2UgdGhlcmUgc2hvdWxkDTxicj5iZSAoRS4pIGEg c3RhbmRhcmQgd2F5IGZvciB0aGUgb3JpZ2luIHNlcnZlciB0byBhdXRob3Jpc2UgYSBjbGll bnQgYmVoaW5kDTxicj5hIGZvcndhcmQgcHJveHkgd2l0aG91dCBhdXRob3Jpc2luZyB0aGUg Zm9yd2FyZCBwcm94eS4NPGJyPg08YnI+DTxicj4NPGJyPkfvv73vv71yYW4NPGJyPg08YnI+ DTxicj4mZ3Q7DTxicj4mZ3Q7S2xhdXMNPGJyPiZndDsNPGJyPiZndDtfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw08YnI+Jmd0O0FjZSBtYWlsaW5n IGxpc3QNPGJyPiZndDtBY2VAaWV0Zi5vcmcNPGJyPiZndDtodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Fj ------=_NextPart_53358A08_0D5FE228_34D74CA6-- From nobody Fri Mar 28 11:35:14 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE991A0982 for ; Fri, 28 Mar 2014 11:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bFDYpX4m35s for ; Fri, 28 Mar 2014 11:35:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id F40371A06CC for ; Fri, 28 Mar 2014 11:35:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C775C20048; Fri, 28 Mar 2014 15:54:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2436C63ABA; Fri, 28 Mar 2014 14:34:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FD6E63AA2; Fri, 28 Mar 2014 14:34:59 -0400 (EDT) From: Michael Richardson To: Likepeng In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B049@SZXEMA501-MBS.china.huawei.com> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B049@SZXEMA501-MBS.china.huawei.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/MuL4W8CzauLCqrVnYO--nTOeZf8 Cc: =?us-ascii?Q?=3D=3Futf-8=3FB=3FR8O2cmFuIFNlbGFuZGVy=3F=3D?= , Klaus Hartke , "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:35:11 -0000 --=-=-= Likepeng wrote: > I agree that we should consider the requirements for the proxy support > when we design our solution. > But I think it is better to design our solution step by step, in > different phases. > My worry is, proxy is quite complex to support, this may delay our > progress to finish our basic solution. If we do not state this up-front, then we will wind up either throwing out the basic solution, or we will hack it up horribly. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzXA0IqHRg3pndX9AQLPjgP9EPcw+wMkLBxB8KqH+MLSd39AT2WMmID7 XddQeTu8Q5ybhusJcb6boF7V4mCToLAzqqG+RcK3ZaAo6YenKb3Au554Js1+k9jS 39YNcaqAWR8KOdUVLmIOwt56nULaQkUs15nRYm8xFIcb3ohX8resMXYLujYHepRB jCRIIzajn8s= =1aL2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 28 13:04:05 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2691A0344 for ; Fri, 28 Mar 2014 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXG6Ncwh5JJk for ; Fri, 28 Mar 2014 13:04:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4181A0333 for ; Fri, 28 Mar 2014 13:04:01 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2SK3pAe024339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 20:03:52 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2SK3o5S027804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Mar 2014 20:03:50 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2SK3nho025648; Fri, 28 Mar 2014 20:03:49 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Mar 2014 13:03:17 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <29256.1396031699@sandelman.ca> Date: Fri, 28 Mar 2014 13:03:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D020C91-75BD-4495-8014-F73D4FDC038B@oracle.com> References: <532F68E7.7000802@gmx.net> <23517.1395626408@sandelman.ca> <532F7A90.1040302@gmx.net> <22120.1395663947@sandelman.ca> <53305348.2020105@gmx.net> <26153.1395683223@sandelman.ca> <533142AA.4040108@gmx.net> <34966E97BE8AD64EAE9D3D6E4DEE36F252B0B049@SZXEMA501-MBS.china.huawei.com> <29256.1396031699@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/ace/43zBK4am3wNQvc_KhuQownPWZ-4 Cc: =?us-ascii?Q?=3D=3Futf-8=3FB=3FR8O2cmFuIFNlbGFuZGVy=3F=3D?= , Klaus Hartke , Likepeng , "Ace@ietf.org" Subject: Re: [Ace] Summary of the Proxy Discussion X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 20:04:04 -0000 One of my concerns with a proxy requirement in the charter is that = within the OAuth WG and JOSE WG we are working on MAC/HOK tokens that = allow for mutual authentication at the application layer. Not to say whether or not ACE will use OAuth, but with regards to = tokens, while constrained environments might prefer to use DTLS for this = authn and encryption, I wonder if similar app layer authentication = requirements won't come up that block the ability to have "proxy" = support. My gut reaction has been to consider that some endpoints are "dual" = TCP/UDP endpoints to allow inter-op between UDP environs and the larger = web TCP world. I would keep the charter somewhat neutral until some initial proposals = have been received and the group can better evaluate the best approach. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-03-28, at 11:34 AM, Michael Richardson = wrote: >=20 > Likepeng wrote: >> I agree that we should consider the requirements for the proxy = support >> when we design our solution. >=20 >> But I think it is better to design our solution step by step, in >> different phases. >=20 >> My worry is, proxy is quite complex to support, this may delay our >> progress to finish our basic solution. >=20 > If we do not state this up-front, then we will wind up either throwing = out > the basic solution, or we will hack it up horribly. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Fri Mar 28 15:09:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942481A03E7 for ; Fri, 28 Mar 2014 15:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmWlLH5d4f0l for ; Fri, 28 Mar 2014 15:09:42 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6237E1A01F3 for ; Fri, 28 Mar 2014 15:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14142; q=dns/txt; s=iport; t=1396044580; x=1397254180; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=Y9HqvW5iUUTVAN2TzdJQUHhZufFGIqLBxx0iNaoxA8c=; b=iUL4Lrawk3/oLA/J984pJkqXAqZnAKrETrUZyNToKVuzeWXY8DlWMpAC zgluVYuIB+4R1IGWOWp1kiQEfvUOBpTYFOfpcNAPPQDNaEhkMagk2nSFN lEaULGI6jcryyafs2LBffrvP02ey3jtGmcSluMiU6MsO5ROX2eBT1tv91 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FACzyNVOrRDoG/2dsb2JhbABZgkJEO4k/sliHNYEYFnSCJQEBAQQBAQFrBgQRCxEBAwEBAQkMCggHCQMCAQIBFR8DBggTBgIBAQWHXAMQAQ20a50lF4xegiIBCoQuBJhOhk2LaINM X-IronPort-AV: E=Sophos;i="4.97,753,1389744000"; d="scan'208,217";a="106689938" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 28 Mar 2014 22:09:39 +0000 Received: from [161.44.68.195] ([161.44.68.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2SM9ctW014876 for ; Fri, 28 Mar 2014 22:09:39 GMT Message-ID: <5335F322.6040100@cisco.com> Date: Fri, 28 Mar 2014 18:09:38 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ace@ietf.org References: , <9904FB1B0159DA42B0B887B7FA8119CA2E3EEE4D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090508080602020006030704" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/H1ONV2U5Fv63pl9myyg4tZDc5DM Subject: Re: [Ace] Tutorials X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 22:09:46 -0000 This is a multi-part message in MIME format. --------------090508080602020006030704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings. Where these tutorials recorded and posted somewhere? Cheers On 2/6/2014 4:16 AM, Hannes Tschofenig wrote: > Hi Dan, > yes, that's unfortunate but maybe we can create a recording of them. > Ciao > Hannes > *Gesendet:* Donnerstag, 06. Februar 2014 um 09:14 Uhr > *Von:* "Romascanu, Dan (Dan)" > *An:* "Hannes Tschofenig" , "ace@ietf.org" > > *Betreff:* RE: [Ace] Tutorials > > Unfortunately the privacy and AAA tutorials are scheduled one against > the other according to http://www.ietf.org/meeting/89/tutorials.html. > I am not sure if anything can be done about this at this stage. > > Regards, > > Dan > > *From:*Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Hannes Tschofenig > *Sent:* ??? ? 05 ?????? 2014 17:00 > *To:* ace@ietf.org > *Subject:* [Ace] Tutorials > > Hi all, > > you may have noticed that I see value in re-using existing IETF work > (or to at least see whether prior work can be re-used). > > I thought that we could try something new and therefore I approached a > few folks and asked them whether they are willing to give a tutorial > to the folks in the group. > > In particular, I have asked the following persons: > > * Thomas Hardjono: Kerberos > > * Justin Richer: OAuth > > * Eve Maler: UMA > > * Sean Turner: PKI/certificates > > There will also be two tutorials on the Sunday before the IETF > meeting, namely one about the AAA architecture, and another one about > engineering privacy into protocols. The AAA tutorial will be given by > Lionel Morand, and I do the privacy tutorial. > > I will send information about these tutorials to the list ASAP. Note > that I will have to take the availability of the speakers into account > (as you can imagine). > > Ciao > Hannes > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------090508080602020006030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Greetings.

Where these tutorials recorded and posted somewhere?

Cheers


On 2/6/2014 4:16 AM, Hannes Tschofenig wrote:
Hi Dan, 
 
yes, that's unfortunate but maybe we can create a recording of them. 
 
Ciao
Hannes
 
Gesendet: Donnerstag, 06. Februar 2014 um 09:14 Uhr
Von: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
An: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, "ace@ietf.org" <ace@ietf.org>
Betreff: RE: [Ace] Tutorials

Unfortunately the privacy and AAA tutorials are scheduled one against the other according to http://www.ietf.org/meeting/89/tutorials.html. I am not sure if anything can be done about this at this stage.

 

Regards,

 

Dan

 

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: יום ד 05 פברואר 2014 17:00
To: ace@ietf.org
Subject: [Ace] Tutorials

 

Hi all, 

 

you may have noticed that I see value in re-using existing IETF work (or to at least see whether prior work can be re-used). 

I thought that we could try something new and therefore I approached a few folks and asked them whether they are willing to give a tutorial to the folks in the group. 

In particular, I have asked the following persons: 

* Thomas Hardjono: Kerberos

* Justin Richer: OAuth

* Eve Maler: UMA

* Sean Turner: PKI/certificates 

 

There will also be two tutorials on the Sunday before the IETF meeting, namely one about the AAA architecture, and another one about engineering privacy into protocols. The AAA tutorial will be given by Lionel Morand, and I do the privacy tutorial. 

 

I will send information about these tutorials to the list ASAP. Note that I will have to take the availability of the speakers into account (as you can imagine). 

 

Ciao
Hannes

 



_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--------------090508080602020006030704-- From nobody Sun Mar 30 17:34:07 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5881A0724 for ; Sat, 29 Mar 2014 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aivvRGHc1PXU for ; Sat, 29 Mar 2014 13:27:50 -0700 (PDT) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB8311A0723 for ; Sat, 29 Mar 2014 13:27:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 1CD74B00D7 for ; Sat, 29 Mar 2014 21:27:46 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Es0d+YEBAgk for ; Sat, 29 Mar 2014 21:27:41 +0100 (CET) Received: from zmail220.enst-bretagne.fr (zmail220.enst-bretagne.fr [10.29.89.131]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 751D4B00D8 for ; Sat, 29 Mar 2014 21:27:41 +0100 (CET) Date: Sat, 29 Mar 2014 21:27:41 +0100 (CET) From: Ronan CLOATRE To: ace@ietf.org Message-ID: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [88.173.95.148] X-Mailer: Zimbra 7.1.3_GA_3374 (zclient/7.1.3_GA_3374) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/5vbkkZowBbJjwMD9dLUrosJWjq0 X-Mailman-Approved-At: Sun, 30 Mar 2014 17:34:05 -0700 Subject: [Ace] unsubscribe X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 20:27:51 -0000 unsubscribe From nobody Mon Mar 31 03:19:31 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D551A0665 for ; Mon, 31 Mar 2014 03:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f0dcRHdfIoh for ; Mon, 31 Mar 2014 03:19:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B254E1A0661 for ; Mon, 31 Mar 2014 03:19:26 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LsTjw-1XATi60m0e-011xij; Mon, 31 Mar 2014 12:19:22 +0200 Message-ID: <53393FDD.3020400@gmx.net> Date: Mon, 31 Mar 2014 12:13:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: paduffy@cisco.com, ace@ietf.org References: , <9904FB1B0159DA42B0B887B7FA8119CA2E3EEE4D@AZ-FFEXMB04.global.avaya.com> <5335F322.6040100@cisco.com> In-Reply-To: <5335F322.6040100@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uswQ6juDfWn51Fk6oAIkCLch8T0wDQ99D" X-Provags-ID: V03:K0:7e0I28gphPw7is0urGbyN8a9v/eFA+nNo0BOlyeNt3HoRK9YZfq xkTYa6yOY++UYFRu54WFV/fpMaNXrFpTOmqsz3PFhZ8ig+GF/JYpP1hjZ9xGnj65NdIsW7V Vf9L3dPfox0/1P5ibUjfidqOlkCaWciFnJX/9NvYwxeAQzoM6XZOBOry7a/1QtZC4ngwCKq e7e/C7JPRYUpO3Ts8NHDg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/mEeDl-uo24ZuPnbHm_D50SzPPWw Subject: Re: [Ace] Tutorials X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 10:19:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uswQ6juDfWn51Fk6oAIkCLch8T0wDQ99D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, yes, we recorded the tutorials and I put them here: http://www.tschofenig.priv.at/wp/?p=3D1012 Ciao Hannes On 03/28/2014 11:09 PM, Paul Duffy wrote: > Greetings. >=20 > Where these tutorials recorded and posted somewhere? >=20 > Cheers >=20 >=20 > On 2/6/2014 4:16 AM, Hannes Tschofenig wrote: >> Hi Dan,=20 >> =20 >> yes, that's unfortunate but maybe we can create a recording of them.=20 >> =20 >> Ciao >> Hannes >> =20 >> *Gesendet:* Donnerstag, 06. Februar 2014 um 09:14 Uhr >> *Von:* "Romascanu, Dan (Dan)" >> *An:* "Hannes Tschofenig" , "ace@ietf.org" >> >> *Betreff:* RE: [Ace] Tutorials >> >> Unfortunately the privacy and AAA tutorials are scheduled one against >> the other according to http://www.ietf.org/meeting/89/tutorials.html. >> I am not sure if anything can be done about this at this stage. >> >> =20 >> >> Regards, >> >> =20 >> >> Dan >> >> =20 >> >> =20 >> >> *From:*Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Hannes Tschofe= nig >> *Sent:* =D7=99=D7=95=D7=9D =D7=93 05 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7= =A8 2014 17:00 >> *To:* ace@ietf.org >> *Subject:* [Ace] Tutorials >> >> =20 >> >> Hi all,=20 >> >> =20 >> >> you may have noticed that I see value in re-using existing IETF work >> (or to at least see whether prior work can be re-used).=20 >> >> I thought that we could try something new and therefore I approached a= >> few folks and asked them whether they are willing to give a tutorial >> to the folks in the group.=20 >> >> In particular, I have asked the following persons:=20 >> >> * Thomas Hardjono: Kerberos >> >> * Justin Richer: OAuth >> >> * Eve Maler: UMA >> >> * Sean Turner: PKI/certificates=20 >> >> =20 >> >> There will also be two tutorials on the Sunday before the IETF >> meeting, namely one about the AAA architecture, and another one about >> engineering privacy into protocols. The AAA tutorial will be given by >> Lionel Morand, and I do the privacy tutorial.=20 >> >> =20 >> >> I will send information about these tutorials to the list ASAP. Note >> that I will have to take the availability of the speakers into account= >> (as you can imagine).=20 >> >> =20 >> >> Ciao >> Hannes >> >> =20 >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --uswQ6juDfWn51Fk6oAIkCLch8T0wDQ99D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTOT/dAAoJEGhJURNOOiAtJewIAJraYEKyzXZjhZ898tlTM667 ToQVMJRa8Nc+y8tJ40frGPLThri1NR3URPEdwwps0EokIF7ksEyO6GTqvZ7IOVym SxoKirV3Vr5wib7FYZ6r1/yoPMl6jrreWJGk7wfMBj69fYk4lRXokAEa7+e5Fnd6 z7BK/9sEVZfVXyCJQNsbX8ep7/TEDLhorVNE+yfXHGrNoJIZdxSokUD9cu5OmVBK fLLp7MPZmPci8EiTtIMzvUZws8Sm6C2rTu1RtvJE87opNP7uWNdNMk6RR+6rirYQ 2ueUygxHxqeR0iqP0I26LZBr7jJEKT1bAqX2LgwJ8+pLrRPo4gScuF2zIP4dDic= =iTUM -----END PGP SIGNATURE----- --uswQ6juDfWn51Fk6oAIkCLch8T0wDQ99D--