From nobody Wed Apr 2 02:43: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 638571A016F for ; Wed, 2 Apr 2014 02:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_57=0.6, 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 h6qL-pnddv0t for ; Wed, 2 Apr 2014 02:43:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2F97E1A0178 for ; Wed, 2 Apr 2014 02:43:03 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MUpI8-1WYWq21DcS-00YCjk; Wed, 02 Apr 2014 11:42:49 +0200 Message-ID: <533BDA78.9060903@gmx.net> Date: Wed, 02 Apr 2014 11:38:00 +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: 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> <533142AA.4040108@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0NsnRM0NRSW03g2MnkfTU6aXm2aNpTd3w" X-Provags-ID: V03:K0:UG7bwlajPekYjg+hZnzpCldUtVfEq4ZLgEXt4YIIo2OZPrW3y5r 6DyRlEtBCXaTg0009mvGjqqO0gz4CTKIs7iW8MkNc0LrdR6kgS/KFSW5SQXm8oPckibzvEt sqdD8FY4UWjRCV6Th8uqKok7DyccdsLbJgZ2DPCBjlW7OeVEpv3IH/lGehnjt9iWaEkTDZ6 aTIBY/cZ0g1kmSICqWFMg== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/y9Onmnr3AvHiTxTQ3jr_I2-vJa0 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: Wed, 02 Apr 2014 09:43:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0NsnRM0NRSW03g2MnkfTU6aXm2aNpTd3w Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Klaus, thanks for the detailed response. A few remarks below. On 03/25/2014 03:48 PM, Klaus Hartke wrote: > Hi Hannes, >=20 > 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. >=20 > Example 1: Client---Origin Server[example.org] >=20 > 1. The client resolves and establishes a secure connection to example.o= rg > 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 t= he client >=20 Here is don't see a problem since there is no proxy involved. > Example 2: Client---Reverse Proxy[example.org]---Origin Server[example.= net] >=20 > 1. The client resolves and establishes a secure connection to example.o= rg > 2. The client requests a representation of the resource /path/to/resour= ce > 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 I don't see a problem here either since the client assumes that it is talking to example.org. I have seen these reverse proxies in many server deployments as load balancers and accelerators. This, of course, assumes that the example.org and the example.net are in the same administrative domain and that the client is indeed configured to talk to example.org (rather than example.net). >=20 > Example 3: Client---Forward Proxy[proxy.example]---Origin Server[exampl= e.org] >=20 > 1. The client resolves and establishes a secure connection to proxy.exa= mple > 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 If the client assumes that it wants to talk to example.org and suddenly it sees a certificate with proxy.example then the exchange will fail. There is a secret sauce somewhere here. How do you expect the security of this to work? >=20 > Example 4: Client---Tunnel[tunnel.example]---Origin Server[example.org]= >=20 > 1. The client resolves and establishes an unsecured connection to tunne= l.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 connecti= ons > 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/resour= ce > 6. The origin server satisfies the request by serving a local file to t= he client This is not supported in CoAP, which is unfortunate. Ciao Hannes >=20 > Does that answer your questions? >=20 > Klaus >=20 >=20 > On 25 March 2014 09:47, Hannes Tschofenig w= rote: >> 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 DTL= S >> 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 obtain= s >>> 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 ("forwar= d >>> 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 initial= ly >> 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 potentiall= y >>> 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 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --0NsnRM0NRSW03g2MnkfTU6aXm2aNpTd3w 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/ iQEcBAEBCgAGBQJTO9p4AAoJEGhJURNOOiAtxcIH/1tSmJiw/j8fNRyzgzXPDWth BCl2D3sEhrjmt3Js6kXBmw2nrhvROb1REg0/RRFL5BIMWILykfQTD+1ChNQatF0J NnS6BL9VKqGK2uzKq/5vIKQpArw5rDSrBDYKWC2SM7i8EVaxZbvLXZ4DYCl8RLzk HQDpCoGEgGlG+Ryo824ZM/biekFSY1o00+uuV0SbAUUgTGtB95mkZ9XtiVwDtVht WQlSKp57aw79ON/Sj9uc+mbs/a1lfwVELE0lEYARblUOs7KBSHkKlOqTqOF2jEzb 5bxyLQJwnYePOuY46S3xMg29pRGwru/XT4X0HBzp+U+CL/rXpZwnMWIZR27iFak= =Ts5x -----END PGP SIGNATURE----- --0NsnRM0NRSW03g2MnkfTU6aXm2aNpTd3w-- From nobody Wed Apr 2 02:45: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 6962F1A0187 for ; Wed, 2 Apr 2014 02:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_57=0.6, 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 j8zzJgLkp4dP for ; Wed, 2 Apr 2014 02:44:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC941A0132 for ; Wed, 2 Apr 2014 02:44:54 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MRkhB-1WbZHN3Jc1-00Sxrc; Wed, 02 Apr 2014 11:44:49 +0200 Message-ID: <533BDAF4.7090803@gmx.net> Date: Wed, 02 Apr 2014 11:40:04 +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: Michael Richardson , "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> <533142AA.4040108@gmx.net> <32386.1395778304@sandelman.ca> In-Reply-To: <32386.1395778304@sandelman.ca> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FFNvgVs99lIKcIm99WIemeD9R0Binq4NJ" X-Provags-ID: V03:K0:k2WPGeOUtRty7zL1lLoANpeX5x0jqUwvM8SG6jythUh5LyITzwb bwOYNMb+FHbuPzTsuov/J0oY4oVwltVYaB1aNDRuPiP0A+NMwc3FijQzV6t//4fi8x0ELu4 o7YdMWI2uyvsZEskm0kqNKbwNyqiY02ynonDZKoXS/87UvsX06cbtfqsuOUSEphYljFYD08 PFCxRkBZGM0lV8LniPaZA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/LBtkRQtMaQEkEZhJVLTsP7jc70k 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: Wed, 02 Apr 2014 09:44:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FFNvgVs99lIKcIm99WIemeD9R0Binq4NJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, a few remarks below. On 03/25/2014 09:11 PM, Michael Richardson wrote: >=20 > I'm going to keep just the step two, because it's where the differences= are. >=20 > Klaus Hartke wrote: > > 2. The client requests a representation of the resource > > /path/to/resource by sending a GET request message >=20 > > 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 >=20 > > 2. The client requests the tunnel to establish an unsecured conne= ction > > to example.org and to act as a blind relay between the tw= o > > connections >=20 > There is a fifth situation which we try never to talk about: >=20 > Example 5: Client---TransparentProxy[proxy.example]--Origin Server[exam= ple.org] >=20 > 1. client opens a connection to example.org. > TCP connection is intercepted (think NAPT, not perpass) by proxy.exa= mple. > 2. client requests a representation of the resource /path/to/resource > 3. proxy.example, connects to real example.org (by IP, which it observe= d in > the TCP getsockname()), requests resource, returns it to client. >=20 > 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!) >=20 This will not work with DTLS unless you run a man-in-the-middle attack against it (by the CA trick or if example.org shares its long-term credentials with proxy.example). > The relevant situation that I understand, and which I think might want = to > support is: >=20 > Example 6: Client---HTTP/CoAPProxy[proxy.example]--Origin Server[exampl= e.org] >=20 > 1. client opens a connection to example.org. > TCP/HTTPS connection is intercepted (think NAPT, not perpass) by > proxy.example. >=20 > 2. client requests a representation of the resource /path/to/resource >=20 > 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= =2E >=20 > 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 think that this example is indeed really similar to the reverse proxy, particularly if the translation gateway is operated by the same party as the actual example.com HTTP server. >=20 > I want to be able to do this securely such that the this man-in-the-mid= dle > is clearly authorized to be in the middle, and with an audit trail that= > becomes visible to both client and origin servers. >=20 > It's also clear to me that the authorization on the left probably has t= o > play nicely with OAuth2. For the translation gateway case to work seamlessly end-to-end across protocol boundaries, I agree with your statement. But for the reverse proxy case that might not even be desired since one argument for using reverse proxies it to terminate security early at the edge. 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 --FFNvgVs99lIKcIm99WIemeD9R0Binq4NJ 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/ iQEcBAEBCgAGBQJTO9r0AAoJEGhJURNOOiAtzNoH/1h89kvtFTEcdafGPv4lKnVU PFbhbPxsxhH+rohdkHllIc5mJ8ydS4HLb2q4o7h4+4Yri/YNBipYvHoRDj+I6eiF VyiSTMVbKKX3ZImkr7eYeJvFgRapprIP5vMIScgou0xGy8Mqe7KM1wKGcgc913wk OIDVZ5g2ZCUbdQktzJ/s9zaAKTY3jh/bbTghUIk42CMbsCYlgzdjEVJsSgApMHAn 6C2y1XprhtcIFRGml+j60QOHz/ZzSMCr3NdwqoyPk9LBlfCx/C+ZAJN1IG4Q3HWW ylDe/i1lc+klCU/C1MDnzWBJfye5QL5/18/LyELQzCqh7DWtXPAnNW4CgPcfw7c= =VqY6 -----END PGP SIGNATURE----- --FFNvgVs99lIKcIm99WIemeD9R0Binq4NJ-- From nobody Wed Apr 2 23:41: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 D7FF71A00DA for ; Wed, 2 Apr 2014 23:40:58 -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 vzW-3_AmYpyC for ; Wed, 2 Apr 2014 23:40:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 38B431A00DB for ; Wed, 2 Apr 2014 23:40:54 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXEs5-1WYkdA1Aov-00WFpF for ; Thu, 03 Apr 2014 08:40:49 +0200 Message-ID: <533CFC50.3090801@gmx.net> Date: Thu, 03 Apr 2014 08:14:40 +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: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iS4Oi14Gbd2W1bOeEUS8GN2Aa71ut8uNn" X-Provags-ID: V03:K0:so0bGtFb8b0shDtOd07ZHZNTUrZiaU+XPjkmX+E8AdAf1l0bk5W 5v6SYTEBAeLaFJ3i6C56HWIFX04KEqBZuMEJlQeas+PxuLSUs7XJiHucvRJ7E30sXBnccXb bsJK/WEbwiXoftNFClzLFKsBgOsewjaHQmWOCZj8HCky9dB1L0nu3YhaTsJMpKErZpqcRem 2T3HTYRLIwlf+OmvHG0KA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/FwvC0z8foFE5x7DtQUrKmx0iI08 Subject: [Ace] Last Call for Comments on ACE Charter Text 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, 03 Apr 2014 06:40:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iS4Oi14Gbd2W1bOeEUS8GN2Aa71ut8uNn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, we have used the time after the IETF to discuss various open issues and we believe that we have covered all topics raised. It is our impression that the current charter text reflects the views of the group. Here is the latest version distributed by Kepeng a few days ago: http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# Before we forward the charter text to the IESG we want to issue a 'last call for comments'. Please provide your feedback at latest by **April 10th**. Ciao Hannes & Kepeng PS: Regarding the recent proxy discussion it was our impression that no changes to the charter text are necessary. The topic can (and should) be covered as part of the requirements/use case discussion, which is already explicitly stated in the charter. --iS4Oi14Gbd2W1bOeEUS8GN2Aa71ut8uNn 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/ iQEcBAEBCgAGBQJTPPxQAAoJEGhJURNOOiAtiywIAJHUpTf9GY2Yd3JYAWYoNweB sya5rkBSMPA+wP7B+OzCBZEwmPOPC3SjjuGo1Dci7oSFwIra6qigXaEJEk8xE44g BC0h2sOLUt7gB5iy6X6HJHxl6XxPj8p8oV0mMj6/wFY+TCpK5m1nnMyzVBRpBxcj PV/5kljXRRoFXm7vDtL/gFR3lYvpmvc7MioIbwYaqczwKpXIUvvIkXEiSH3jFqmk Wx7hj7N9EsSgXxfyVBorCSyPyjSAXsSgIF2fdcMtlOK652TJDIEuIoWvZryYubp4 C5LyefMAMCp3AaJ7iLSKldDYsRP9LXOiHlwnDMZHXRoA50h3qKZYdgeEyEj6dww= =ij4i -----END PGP SIGNATURE----- --iS4Oi14Gbd2W1bOeEUS8GN2Aa71ut8uNn-- From nobody Thu Apr 3 04:33: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 9203D1A03BF for ; Thu, 3 Apr 2014 04:33:37 -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, 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 Em_EDc3T7Ula for ; Thu, 3 Apr 2014 04:33:33 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 965A31A03EA for ; Thu, 3 Apr 2014 04:31:45 -0700 (PDT) X-ASG-Debug-ID: 1396524700-06daaa1bdadffe0001-Yzt3Th Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id NhAhRvtnFv616zXL for ; Thu, 03 Apr 2014 07:31:40 -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, 3 Apr 2014 07:31:56 -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, 3 Apr 2014 07:31:54 -0400 X-ASG-Orig-Subj: RE: [Ace] Last Call for Comments on ACE Charter Text Message-ID: In-Reply-To: <533CFC50.3090801@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text Thread-Index: Ac9PB8CW4MiW8J0NTjWKYphCstJqBAAKFD1g References: <533CFC50.3090801@gmx.net> From: "Rahman, Akbar" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 03 Apr 2014 11:31:56.0464 (UTC) FILETIME=[51B16B00:01CF4F30] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1396524700 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4542 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/ace/oczkyDD9bOFPwtpzjLFofO4Shbk Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 03 Apr 2014 11:33:37 -0000 +1 (and strongly agree with the caveat that proxies should (or rather MUST) be covered as part of the requirements/use case discussions). -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, April 03, 2014 2:15 AM To: ace@ietf.org Subject: [Ace] Last Call for Comments on ACE Charter Text Hi all, we have used the time after the IETF to discuss various open issues and we believe that we have covered all topics raised. It is our impression that the current charter text reflects the views of the group. Here is the latest version distributed by Kepeng a few days ago: http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# Before we forward the charter text to the IESG we want to issue a 'last call for comments'. Please provide your feedback at latest by **April 10th**. Ciao Hannes & Kepeng PS: Regarding the recent proxy discussion it was our impression that no changes to the charter text are necessary. The topic can (and should) be covered as part of the requirements/use case discussion, which is already explicitly stated in the charter. From nobody Thu Apr 3 05:56:29 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 4A0081A011F for ; Thu, 3 Apr 2014 05:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, J_CHICKENPOX_57=0.6, 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 QuNj3lc0OHai for ; Thu, 3 Apr 2014 05:56: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 B3AAC1A0152 for ; Thu, 3 Apr 2014 05:56:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D0025200D4; Thu, 3 Apr 2014 10:16:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A5E9C63ABA; Thu, 3 Apr 2014 08:56:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9680463AB2; Thu, 3 Apr 2014 08:56:17 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <533BDA78.9060903@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> <533BDA78.9060903@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/0ASS_QB7XNkEzY8OPulJoJPY0ak Cc: 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: Thu, 03 Apr 2014 12:56:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: >> 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 > I don't see a problem here either since the client assumes that it is > talking to example.org. I have seen these reverse proxies in many ser= ver > deployments as load balancers and accelerators. Yes, it is common,although with the availability of wildcard certificates, and/or useful/affordable intermediate CA certificates some banks/etc now redirect you from the main login page to www123234.example.co= m. This has significant scalability and geo-diversity advantages, and cryptographically means one can sometimes avoid sharing private keys. > This, of course, assumes that the example.org and the example.net are= in > the same administrative domain and that the client is indeed configur= ed > to talk to example.org (rather than example.net). That was an assumption between example being the same org. (Clearly we need a few more example domains...) >> 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 > If the client assumes that it wants to talk to example.org and sudden= ly > it sees a certificate with proxy.example then the exchange will fail. > There is a secret sauce somewhere here. > How do you expect the security of this to work? local configuration override. same as you might set $http_proxy or set you browser's proxies. >> Example 4: Client---Tunnel[tunnel.example]---Origin Server[example.o= rg] >>=20 >> 1. The client resolves and establishes an unsecured connection to tu= nnel.example >> 2. The client requests the tunnel to establish an unsecured connecti= on >> to example.org and to act as a blind relay between the two connectio= ns >> 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/res= ource >> 6. The origin server satisfies the request by serving a local file t= o the client > This is not supported in CoAP, which is unfortunate. true.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUz1acYqHRg3pndX9AQL1sAP7BvM/9DkntLQAeilrlK9nkQT1QG3APych 4CCTjC1uYk0Fw8YHYzzBoUj1yKeweL37PfXlh14Qn4FAY1GzLCXYkTPJRVks8rcb X2XCpLPNMEJbMYVXb+C+0ub+gs29QJceGi8s9uR6uRdP+s52H3kyX+7HHpA1oaka zvZiCzwNs1c= =K3+7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 3 06:03: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 D1C261A01FC for ; Thu, 3 Apr 2014 06:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 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] 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 UdyxNFf6HkSz for ; Thu, 3 Apr 2014 06:03:24 -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 9CF831A0152 for ; Thu, 3 Apr 2014 06:03:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 32506200D4; Thu, 3 Apr 2014 10:23:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 682F663ABA; Thu, 3 Apr 2014 09:03:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 520A963AB2; Thu, 3 Apr 2014 09:03:20 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <533BDAF4.7090803@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> <32386.1395778304@sandelman.ca> <533BDAF4.7090803@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/t6flq38pXitLzAv4mTJRxQwRjDI 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, 03 Apr 2014 13:03:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable see inline Hannes Tschofenig wrote: >> Klaus Hartke wrote: >> > 2. The client requests a representation of the resource >> > /path/to/resource by sending a GET request message >>=20 >> > 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 >>=20 >> > 2. The client requests the tunnel to establish an unsecured connec= tion >> > to example.org and to act as a blind relay between the two >> > connections >>=20 >> There is a fifth situation which we try never to talk about: >>=20 >> Example 5: Client---TransparentProxy[proxy.example]--Origin Server[e= xample.org] >>=20 >> 1. client opens a connection to example.org. >> TCP connection is intercepted (think NAPT, not perpass) by proxy.exa= mple. >> 2. client requests a representation of the resource /path/to/resource >> 3. proxy.example, connects to real example.org (by IP, which it obse= rved in >> the TCP getsockname()), requests resource, returns it to client. >>=20 >> 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 c= ord, >> or network device work (for good or bad!) >>=20 > This will not work with DTLS unless you run a man-in-the-middle attack > against it (by the CA trick or if example.org shares its long-term > credentials with proxy.example). Agreed. PHB's omnibroker idea deals with some of the trust issues that ensue...=20=20 >> Example 6: Client---HTTP/CoAPProxy[proxy.example]--Origin Server[exa= mple.org] >>=20 >> 1. client opens a connection to example.org. >> TCP/HTTPS connection is intercepted (think NAPT, not perpass) by >> proxy.example. >>=20 >> 2. client requests a representation of the resource /path/to/resource >>=20 >> 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. >>=20 >> 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 mo= re >> 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 sing= le >> one of them preconfigured. > I think that this example is indeed really similar to the reverse pro= xy, > particularly if the translation gateway is operated by the same party= as > the actual example.com HTTP server. It is very similar, and there would have to be a relationship; but not necessarily a close one if we do our work right. The operator of the interception device might be the "ISP" for the IoT service (think ISP supplied home router), but the devices are owned by, for instance, the home owner. The home owner does not with to share private keys on the one hand (they don't want to lock themselves into a single vendor!), on the other hand, they don't want to handle all of the authorization processing themselves.=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUz1cGIqHRg3pndX9AQLIHwP9ERpd8PdjWnjZZmSNukf8HPdj6/HmGpt3 602CWMSwCd2zT6h8U2k1ulDD4dkDfJPsT3zkpj6wK0DISXBIiQwtesZbkzRvTzI/ 72ISUJpyqXArKTp2G8LEsjmVm1xe3EaxBt4lEMfOeBDUT1pRnuFxmFDa8UqpHiQ8 LVSEiAzfxvM= =enKj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 3 08:17: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 117B61A021C for ; Thu, 3 Apr 2014 08:17:11 -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 M140Mz0Y8NbY for ; Thu, 3 Apr 2014 08:17:06 -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 30E091A022C for ; Thu, 3 Apr 2014 08:16:49 -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 s33FGdpC013474 for ; Thu, 3 Apr 2014 17:16:39 +0200 (CEST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1524384E for ; Thu, 3 Apr 2014 17:16:38 +0200 (CEST) Received: by mail-vc0-f174.google.com with SMTP id ld13so2004565vcb.5 for ; Thu, 03 Apr 2014 08:16:37 -0700 (PDT) X-Received: by 10.52.147.238 with SMTP id tn14mr6773817vdb.23.1396538197880; Thu, 03 Apr 2014 08:16:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.242 with HTTP; Thu, 3 Apr 2014 08:15:57 -0700 (PDT) In-Reply-To: <533BDA78.9060903@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> <533BDA78.9060903@gmx.net> From: Klaus Hartke Date: Thu, 3 Apr 2014 17:15:57 +0200 Message-ID: To: "Ace@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/jo9SK35OcVFDvhg_GCmPq-kD0zU 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, 03 Apr 2014 15:17:11 -0000 Hannes Tschofenig wrote: >> Example 2: Client---Reverse Proxy[example.org]---Origin Server[example.net] > > I don't see a problem here either since the client assumes that it is > talking to example.org. I have seen these reverse proxies in many server > deployments as load balancers and accelerators. With respect to authorization, it might be useful to separate between two kinds of reverse proxies: those that have knowledge of which actions a client is authorized to perform on which resources, and those that don't. Example 2a: Client---Reverse Proxy *with* authorization knowledge[example.org]---Origin Server[internal.example.org] 1. The client establishes a secure connection to example.org 2. The client requests a representation of the resource /path/to/resource 3. The reverse proxy checks if the client is authorized to obtain a representation of the resource /path/to/resource 4. The reverse proxy chooses to satisfy the request by obtaining the representation of {coaps,https}://internal.example.org/path/to/resource a. The reverse proxy establishes a secure connection to internal.example.org b. The reverse proxy requests a representation of the resource /path/to/resource c. The origin server satisfies the request by serving a local file to the reverse proxy 5. The reverse proxies serves the representation to the client Example 2b: Client---Reverse Proxy *without* authorization knowledge[example.org]---Origin Server[internal.example.org] 1. The client 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}://internal.example.org/path/to/resource on behalf of the client a. The reverse proxy establishes a secure connection to internal.example.org b. The reverse proxy requests a representation of the resource /path/to/resource, indicating that it's acting _on behalf of the client_ c. The origin server checks if the _client_ is authorized to obtain a representation of the resource /path/to/resource (even though it is the reverse proxy that is requesting the representation) d. 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] > > If the client assumes that it wants to talk to example.org and suddenly > it sees a certificate with proxy.example then the exchange will fail. > There is a secret sauce somewhere here. > > How do you expect the security of this to work? If the client assumes that it wants to talk to example.org and suddenly it sees a certificate with proxy.example, then we're talking about an interception proxy/transparent proxy/captive portal, not a forward proxy. A forward proxy is knowingly selected by a client, usually via local configuration rules, to perform requests on behalf of the client. Let me make the example more explicit: Example 3: Client---Forward Proxy[proxy.example]---Origin Server[example.org] 0. The client is configured to use the forward proxy coaps://proxy.example:1234/ 1. Because the client is configured to use a forward proxy, instead of securely connecting to example.org and expecting a certificate for example.org, it securely connects to proxy.example:1234 and expects a certificate for proxy.example 2. The client requests the forward proxy to return a representation of the resource coaps://example.org/path/to/resource over the secure connection Note that this is an interaction between the client and the forward proxy, not between the client and the origin server through the forward proxy. 3. The forward proxy satisfies the request by obtaining the representation of coaps://example.org/path/to/resource a. The forward proxy securely connects to example.org and expects a certificate for example.org b. The forward proxy requests a representation of the resource /path/to/resource. Note that this is an interaction between the forward proxy and the origin server, not between the client and the origin server through the forward proxy. c. The origin server satisfies the request by serving a local file to the forward proxy 4. The forward proxy returns the representation to the client So the interaction between the client and the forward proxy on the one hand and the interaction between the forward proxy and the origin server on the other hand are both secured. But there is no end-to-end security between the client and the origin server. Klaus From nobody Thu Apr 3 08:27: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 405FD1A0274 for ; Thu, 3 Apr 2014 08:27: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 MnrXLN1AxTQj for ; Thu, 3 Apr 2014 08:26:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F3C481A0273 for ; Thu, 3 Apr 2014 08:26:55 -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 BFF76940; Thu, 03 Apr 2014 15:26:51 +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, 3 Apr 2014 16:25:52 +0100 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; Thu, 3 Apr 2014 16:26:50 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 3 Apr 2014 23:26:43 +0800 From: Bert Greevenbosch To: "ace@ietf.org" Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text Thread-Index: AQHPTwe6LhSbB24tbk68ms8SIF38L5sAA4aC Date: Thu, 3 Apr 2014 15:26:43 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E4976D0@SZXEMA510-MBX.china.huawei.com> References: <533CFC50.3090801@gmx.net> In-Reply-To: <533CFC50.3090801@gmx.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.69.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/rotkj_9nQ74EYyNzXNsvIz-MZls Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 03 Apr 2014 15:27:03 -0000 The charter looks good to me. Ready to ship! Bert ________________________________________ From: Ace [ace-bounces@ietf.org] on behalf of Hannes Tschofenig [hannes.tsc= hofenig@gmx.net] Sent: 03 April 2014 14:14 To: ace@ietf.org Subject: [Ace] Last Call for Comments on ACE Charter Text Hi all, we have used the time after the IETF to discuss various open issues and we believe that we have covered all topics raised. It is our impression that the current charter text reflects the views of the group. Here is the latest version distributed by Kepeng a few days ago: http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# Before we forward the charter text to the IESG we want to issue a 'last call for comments'. Please provide your feedback at latest by **April 10th**. Ciao Hannes & Kepeng PS: Regarding the recent proxy discussion it was our impression that no changes to the charter text are necessary. The topic can (and should) be covered as part of the requirements/use case discussion, which is already explicitly stated in the charter.= From nobody Fri Apr 4 07:52: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 0EBC51A014E for ; Fri, 4 Apr 2014 07:52:46 -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 Slu3ouPyMDIj for ; Fri, 4 Apr 2014 07:52:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B84B41A0134 for ; Fri, 4 Apr 2014 07:52:40 -0700 (PDT) Received: from [192.168.131.138] ([80.92.122.106]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSutp-1We1Re0IXV-00RoUs for ; Fri, 04 Apr 2014 16:52:35 +0200 Message-ID: <533EC002.2010506@gmx.net> Date: Fri, 04 Apr 2014 16:21:54 +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: "ace@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0oEp7nlkh1AHPlKFBtemArlPq5iapeqlK" X-Provags-ID: V03:K0:2EFZVzp6bgRQsxSZctprcz7QuE1cRQgW0cwiYYIzvQZ91RkW+4d g+Wdua1K65I/gk1Am+m4cZ6uGE50GLdsrtukcDmZyXj53c0dBd2Ww3siJfpcauwxKlJxGNa 5b9fdGi04g0j1+MiFpEXkPSLninnCkpCnHHiUFWtWjNbr6A/5n4n/E17cqCgaqGAeZYH633 ej5RFcn1GmOGq6GeVsPkw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/f9MM4nk_qdlbAHcj7OWFw7i9UhA Subject: [Ace] ABFAB Tutorial - April 22nd 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, 04 Apr 2014 14:52:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0oEp7nlkh1AHPlKFBtemArlPq5iapeqlK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, at the ACE BOF we promised to also schedule a tutorial about ABFAB. We have been working with Margaret, Sam, and Rhys on the details and they kindly offered to give us an overview of ABFAB and how it applies to the IoT space. Date: Tuesday, April 22, 2014 Time: 1:00 pm BST =3D 8am EDT =3D 8pm CST http://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2014&mon= th=3D4&day=3D22&hour=3D12&min=3D0&sec=3D0&p1=3D37&p2=3D136&p3=3D179&p4=3D= 33 Webex: https://ietf.webex.com/ietf/j.php?MTID=3Dmd4e56d458aa66a2bbdfd2e1463dbc97= 7 Meeting Number: 644 405 818 Meeting Password: abfab Audio: +1-650-479-3208 Access code:644 405 818 Due to the IETF Webex configuration restrictions there are no other dial-in codes available. Ciao Hannes & Kepeng --0oEp7nlkh1AHPlKFBtemArlPq5iapeqlK 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/ iQEcBAEBCgAGBQJTPsACAAoJEGhJURNOOiAtxyUIAJ+wpqXDKxwPZGAbzJhBg+AK WW4jPXbkgvJkuBjDFYZ7J4d00RGhZTsu3NzWpU0oMF/t1uz09E2nQLeKTeSGdCzc KrkuIebSEJBsu6IT1sPDvJIjySc3C6jTgUb2rIrTpgJ8dj5hZfoA7RX5pmgYBI83 HpddHBo5GdVmukbrJd2ZDYabqXv2h8HrDA9l0BIP0sJ/+g71KYRY1n0lLENIX80I PY5BLLJ0ESRAjTS8NSMqXaMbiMbL1ZJUNo/4PniMgsO+b7eg06ZYsQ03djKhlDv/ 9rsjlD57HayWOYZeqM4Swl53MVJmfk1IuykzPRU9AGbwA3U3e38tWzCQrNNpPX4= =sblc -----END PGP SIGNATURE----- --0oEp7nlkh1AHPlKFBtemArlPq5iapeqlK-- From nobody Fri Apr 4 08:58: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 3A59C1A0201 for ; Fri, 4 Apr 2014 08:58:31 -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 IsYY_yrivbwU for ; Fri, 4 Apr 2014 08:58:27 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id B1CDD1A01E0 for ; Fri, 4 Apr 2014 08:58:26 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so2608963lbd.37 for ; Fri, 04 Apr 2014 08:58:21 -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=+G8I5JkV7/MP0l95+CEsStklt4tXJDXDY3jNFHBBL3w=; b=uAVHmjDeomJKM8f34g/2KmNK9/p1Zl47y+lnOuSM849W8/VfRRKw3R/bsGYF4BKy+9 etaJzAhSrdmHlsb56sIwHRdsML6u8OpZ55qNvB6+nwKMSPAV9Njv4Cha3tbyEJrKhyok pChwxaXhOooByTnEMFbPJHVd+5y7iyV0oxq3U0WLgw/CYfj/z3mKRLUnq/HceXNHu3mu UX5Yyeq2Wfgf+62xQyWzFas4vHKyyCp//sSb2KPOe63AEjsaRsNsAeviw4UlCqfBStY7 5VK9vLcEXEEPTa+C03C1ZI7B77S9cQQzuXLAmg/wr36KI8u0epNfCAxIZTvmuJWlyMml 2QRQ== MIME-Version: 1.0 X-Received: by 10.112.200.130 with SMTP id js2mr8899733lbc.28.1396627101539; Fri, 04 Apr 2014 08:58:21 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Fri, 4 Apr 2014 08:58:21 -0700 (PDT) In-Reply-To: <533CFC50.3090801@gmx.net> References: <533CFC50.3090801@gmx.net> Date: Fri, 4 Apr 2014 10:58:21 -0500 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c331b64561c904f6399682 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/SnexMCxkDRiB34toat-sZbW-9MY Cc: "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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: Fri, 04 Apr 2014 15:58:31 -0000 --001a11c331b64561c904f6399682 Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes, I was reading the charter and noticed a few issues as follows: > How does the digital key communicate with the lock? I think there is something wrong with this sentence. > Both resource server and client may be resource constraint. I think it should be resource constrained. There are a few other typos also. Regards, Behcet On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig wrote: > Hi all, > > we have used the time after the IETF to discuss various open issues and > we believe that we have covered all topics raised. > > It is our impression that the current charter text reflects the views of > the group. Here is the latest version distributed by Kepeng a few days > ago: > http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# > > Before we forward the charter text to the IESG we want to issue a 'last > call for comments'. Please provide your feedback at latest by **April > 10th**. > > Ciao > Hannes & Kepeng > > PS: Regarding the recent proxy discussion it was our impression that no > changes to the charter text are necessary. The topic can (and should) be > covered as part of the requirements/use case discussion, which is > already explicitly stated in the charter. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a11c331b64561c904f6399682 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

I wa= s reading the charter and noticed a few issues as follows:

> How = does the digital key communicate with the lock?

I think there = is something wrong with this sentence.

> Both resource server and client may be resource constraint.
I think it should be resource constrained.

There are a = few other typos also.

Regards,

Behcet


On Thu, Apr 3= , 2014 at 1:14 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

we have used the time after the IETF to discuss various open issues and
we believe that we have covered all topics raised.

It is our impression that the current charter text reflects the views of the group. Here is the latest version distributed by Kepeng a few =A0days ago:
http://tools.ietf.org/wg/core/trac/wiki/ACE_charter#

Before we forward the charter text to the IESG we want to issue a 'last=
call for comments'. Please provide your feedback at latest by **April 10th**.

Ciao
Hannes & Kepeng

PS: Regarding the recent proxy discussion it was our impression that no
changes to the charter text are necessary. The topic can (and should) be covered as part of the requirements/use case discussion, which is
already explicitly stated in the charter.


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


--001a11c331b64561c904f6399682-- From nobody Fri Apr 4 09:21: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 906271A023B for ; Fri, 4 Apr 2014 09:21:40 -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 mCbenvqE8zCT for ; Fri, 4 Apr 2014 09:21:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5F11A0230 for ; Fri, 4 Apr 2014 09:21:35 -0700 (PDT) Received: from [192.168.131.138] ([80.92.122.106]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Mb8MV-1Wl9yk0M83-00KfLX; Fri, 04 Apr 2014 18:21:29 +0200 Message-ID: <533ED496.8060608@gmx.net> Date: Fri, 04 Apr 2014 17:49:42 +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: sarikaya@ieee.org References: <533CFC50.3090801@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CshcwESAWII33RUes6D9fTMpOQFCFmRLp" X-Provags-ID: V03:K0:Zul4yDwozs/sa9ixxrTZKFla8ivXGyD1hEiwqT3Dziu7G7ssgGL iEwgneYC/2cpX92mT97Titjpi24/S/KsUnffq5Us4F3BQBAXaFoq8UtcCBGAuHxMSzfveW2 LVlblo3ab72H4es6pzisJUCNy9e9yQgIOhNvzf9lFidktsjk5kSpRM+Nfxgq92S1QSBiRAB 6gdg8ePnHB1nL8vJPdw3g== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/l6V1aUE4hyHpP9zeMij8gSXPNO8 Cc: "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 04 Apr 2014 16:21:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CshcwESAWII33RUes6D9fTMpOQFCFmRLp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Behcet, thanks for your review. There are indeed a couple of editorial glitches in the charter text. I have asked my co-worker Robert Taylor to do a review to get those fixed. Will have an updated version on the Wiki in a few minutes. Ciao Hannes On 04/04/2014 05:58 PM, Behcet Sarikaya wrote: > Hi Hannes, >=20 > I was reading the charter and noticed a few issues as follows: >=20 >> How does the digital key communicate with the lock? >=20 > I think there is something wrong with this sentence. >=20 >> Both resource server and client may be resource constraint. >=20 > I think it should be resource constrained. >=20 > There are a few other typos also. >=20 > Regards, >=20 > Behcet >=20 >=20 > On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig > > wrote: >=20 > Hi all, >=20 > we have used the time after the IETF to discuss various open issues= and > we believe that we have covered all topics raised. >=20 > It is our impression that the current charter text reflects the vie= ws of > the group. Here is the latest version distributed by Kepeng a few = days > ago: > http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# >=20 > Before we forward the charter text to the IESG we want to issue a '= last > call for comments'. Please provide your feedback at latest by **Apr= il > 10th**. >=20 > Ciao > Hannes & Kepeng >=20 > PS: Regarding the recent proxy discussion it was our impression tha= t no > changes to the charter text are necessary. The topic can (and shoul= d) be > covered as part of the requirements/use case discussion, which is > already explicitly stated in the charter. >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 >=20 --CshcwESAWII33RUes6D9fTMpOQFCFmRLp 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/ iQEcBAEBCgAGBQJTPtSWAAoJEGhJURNOOiAtGBsH/0EUWWGCyimjwA4tGirMy6Z3 P7kFOIEtEieADMCoMGM0G6S4qpEYVBgsEBRyLReqa61xJQqfrFjAGK18+kL7jOWR XTc3CUypN2KEgUqRv4+pHzJWcn6py28wGMWZLrdYmu/X7Oy7OmBcknK/3yB2xxCk 6IXvGjhGZ0CNf7xgX1i3HOlxsjPgLuVc+15TUVhHzmeE1kIakVVLGVrlegGW8Jip x17P0eKfv1jCa0e5b9L/xGXEkPUEVFIbJlv29t3D3nVpbOm/VkAgZNhjqgSzRWIM cOWOr7W0cX6L4ygqRYxyqY8ECG7a9Fsgp+2Z2x6v3l2IO9e+jUQPBh4mP7ztxF4= =vnkH -----END PGP SIGNATURE----- --CshcwESAWII33RUes6D9fTMpOQFCFmRLp-- From nobody Fri Apr 4 16:55: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 E220B1A031E for ; Fri, 4 Apr 2014 16:55:55 -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 85cI9KBiigPh for ; Fri, 4 Apr 2014 16:55:51 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AFCCE1A02FB for ; Fri, 4 Apr 2014 16:55:48 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ec20so3056189lab.29 for ; Fri, 04 Apr 2014 16:55:43 -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=HJh8ekpQji+Al/tlCDgdReYM3CvR5xKUKwYxmN151xM=; b=cWYzQf4wEdDNBF6yuCPJyZWGIaSxIlUhUJk0bLAz30Un709o6+A3vaQ8E5nbqlkEa/ PvokYziOW6E/qpdzn9gPZOUBZysIgo77gS3wND6lMbuTVSCaBoY2FOsQSYq2N1B7uFEl +abpRLG0Imh0QaTdLxJXWbfVr9mfHazRfkO9+WoGN+8qVX4kQrKrgB0z4lihToZ1QunK J6SuVvhST15TKo+D3gkxoz0vZfaAtIwaLePzpqZIa0zXOr1VdnLdZXwUD1KTUvP+lwNc sBMN39o+pf/KHJDmEpV43X0rKEufNwqN71MECiolqat9NmCfFbN/rfwtzqO4ZVwqklb7 GP/w== MIME-Version: 1.0 X-Received: by 10.112.22.130 with SMTP id d2mr9858099lbf.33.1396655743358; Fri, 04 Apr 2014 16:55:43 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Fri, 4 Apr 2014 16:55:43 -0700 (PDT) In-Reply-To: <533ED496.8060608@gmx.net> References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> Date: Fri, 4 Apr 2014 18:55:43 -0500 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=14dae94732b974ddbf04f64041bb Archived-At: http://mailarchive.ietf.org/arch/msg/ace/_oPcT8GZrTphY7VaeSKeL3p5tn8 Cc: "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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: Fri, 04 Apr 2014 23:55:56 -0000 --14dae94732b974ddbf04f64041bb Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes, Reading the charter, I am confused about one thing: There is mention of clients and resource server but no mention of resource constrained nodes or sensors. Why? I don't think they are the clients. My guess is they are considered part of the resource server. I hope you can clarify. Regards, Behcet On Fri, Apr 4, 2014 at 10:49 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Behcet, > > thanks for your review. There are indeed a couple of editorial glitches > in the charter text. I have asked my co-worker Robert Taylor to do a > review to get those fixed. Will have an updated version on the Wiki in a > few minutes. > > Ciao > Hannes > > > On 04/04/2014 05:58 PM, Behcet Sarikaya wrote: > > Hi Hannes, > > > > I was reading the charter and noticed a few issues as follows: > > > >> How does the digital key communicate with the lock? > > > > I think there is something wrong with this sentence. > > > >> Both resource server and client may be resource constraint. > > > > I think it should be resource constrained. > > > > There are a few other typos also. > > > > Regards, > > > > Behcet > > > > > > On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig > > > wrote: > > > > Hi all, > > > > we have used the time after the IETF to discuss various open issues > and > > we believe that we have covered all topics raised. > > > > It is our impression that the current charter text reflects the > views of > > the group. Here is the latest version distributed by Kepeng a few > days > > ago: > > http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# > > > > Before we forward the charter text to the IESG we want to issue a > 'last > > call for comments'. Please provide your feedback at latest by **April > > 10th**. > > > > Ciao > > Hannes & Kepeng > > > > PS: Regarding the recent proxy discussion it was our impression that > no > > changes to the charter text are necessary. The topic can (and > should) be > > covered as part of the requirements/use case discussion, which is > > already explicitly stated in the charter. > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > > > > --14dae94732b974ddbf04f64041bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

Read= ing the charter, I am confused about one thing:

There is menti= on of clients and resource server but no mention of resource constrained no= des or sensors. Why?

I don't think they are the clients. My guess is they are cons= idered part of the resource server.

I hope you can clarify.
Regards,

Behcet


On Fri, Apr 4, 2014 at 10:49 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Behcet,

thanks for your review. There are indeed a couple of editorial glitches
in the charter text. I have asked my co-worker Robert Taylor to do a
review to get those fixed. Will have an updated version on the Wiki in a few minutes.

Ciao
Hannes


On 04/04/2014 05:58 PM, Behcet Sarikaya wrote:
> Hi Hannes,
>
> I was reading the charter and noticed a few issues as follows:
>
>> How does the digital key communicate with the lock?
>
> I think there is something wrong with this sentence.
>
>> Both resource server and client may be resource constraint.
>
> I think it should be resource constrained.
>
> There are a few other typos also.
>
> Regards,
>
> Behcet
>
>
> On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
> =A0 =A0 Hi all,
>
> =A0 =A0 we have used the time after the IETF to discuss various open i= ssues and
> =A0 =A0 we believe that we have covered all topics raised.
>
> =A0 =A0 It is our impression that the current charter text reflects th= e views of
> =A0 =A0 the group. Here is the latest version distributed by Kepeng a = few =A0days
> =A0 =A0 ago:
> =A0 =A0 http://tools.ietf.org/wg/core/trac/wiki/ACE_charter#
>
> =A0 =A0 Before we forward the charter text to the IESG we want to issu= e a 'last
> =A0 =A0 call for comments'. Please provide your feedback at latest= by **April
> =A0 =A0 10th**.
>
> =A0 =A0 Ciao
> =A0 =A0 Hannes & Kepeng
>
> =A0 =A0 PS: Regarding the recent proxy discussion it was our impressio= n that no
> =A0 =A0 changes to the charter text are necessary. The topic can (and = should) be
> =A0 =A0 covered as part of the requirements/use case discussion, which= is
> =A0 =A0 already explicitly stated in the charter.
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 Ace mailing list
> =A0 =A0 Ace@ietf.org <mai= lto:Ace@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/ace
>
>


--14dae94732b974ddbf04f64041bb-- From nobody Fri Apr 4 21:22: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 1DEA61A007F for ; Fri, 4 Apr 2014 21:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 TrmMFEABT6rB for ; Fri, 4 Apr 2014 21:22:16 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 01B471A024C for ; Fri, 4 Apr 2014 21:22:15 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y10so4196356pdj.27 for ; Fri, 04 Apr 2014 21:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0wg98r9P68f1fg+jTsuWZcRTe8jwP85bmDAlkCnTOow=; b=TDbnCvMecNK/KcD6quhkYO6HHa7kaNvHxAoF1faAg4rTjTDhRqHQdGzs3blL+wafXO ZGeSsLqDmPOSPfeUlReBaF6eFBb09cKN1QbkscEjeUhpLsai1BT+nu9QWFii5lpVKjTY UIfzA5V7hEg91JIVWnsozESczOpOAghex7WP544wdAgILqVcjndHJzyFB1NYjpB83a/d 9csUVyNMrI/jIgwHzToFbqvkzqKshnbuPCr8Vgjv9nZJ4xPwoDMDvK62WJ8FYaaPoS7O f0sZFf16iI3KFqJcrhyYRokBhrAGWFD5ZK4vjcw/7Ay09ouskJQdS1g8s8aHcd6h57g6 nPOw== X-Received: by 10.67.8.102 with SMTP id dj6mr18880399pad.10.1396671731224; Fri, 04 Apr 2014 21:22:11 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Fri, 4 Apr 2014 21:21:51 -0700 (PDT) In-Reply-To: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> From: Thomas Watteyne Date: Fri, 4 Apr 2014 21:21:51 -0700 X-Google-Sender-Auth: Zs5A7WhlWVmEifgM9XhpzrevFvE Message-ID: To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=089e0158c0d468569504f643fa0b Archived-At: http://mailarchive.ietf.org/arch/msg/ace/eGGqyWOGzS_zqFWgbHrrquGk_h0 Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 05 Apr 2014 04:22:20 -0000 --089e0158c0d468569504f643fa0b Content-Type: text/plain; charset=ISO-8859-1 Hannes, Kepeng, Some quick editorial remarks: - [typo] But in constrained environment, -> But in constrained environments, - [suggestion] may not be available in existing protocols and for those cases -> may not be available in existing protocols; for those cases - [suggestion] will help to stimulate -> will help stimulate - [question] "Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of IoT devices offering increased security.". Do you mean that ".. with increased security", or "by offering solutions with increased security" - [suggestion] has been made the working group -> has been made, the working group - [suggestion] Furthermore, to guarantee smooth transition the integration -> Furthermore, to guarantee smooth transition, the integration - [suggestion] To be successful this working group -> To be successful, this working group - [suggestion] In the list of tasks, maybe use verbs, i.e. "Produce uses cases ..." and "Identify authorization ..." Thomas On Fri, Apr 4, 2014 at 4:55 PM, Behcet Sarikaya wrote: > Hi Hannes, > > Reading the charter, I am confused about one thing: > > There is mention of clients and resource server but no mention of resource > constrained nodes or sensors. Why? > > I don't think they are the clients. My guess is they are considered part > of the resource server. > > I hope you can clarify. > > Regards, > > Behcet > > > On Fri, Apr 4, 2014 at 10:49 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi Behcet, >> >> thanks for your review. There are indeed a couple of editorial glitches >> in the charter text. I have asked my co-worker Robert Taylor to do a >> review to get those fixed. Will have an updated version on the Wiki in a >> few minutes. >> >> Ciao >> Hannes >> >> >> On 04/04/2014 05:58 PM, Behcet Sarikaya wrote: >> > Hi Hannes, >> > >> > I was reading the charter and noticed a few issues as follows: >> > >> >> How does the digital key communicate with the lock? >> > >> > I think there is something wrong with this sentence. >> > >> >> Both resource server and client may be resource constraint. >> > >> > I think it should be resource constrained. >> > >> > There are a few other typos also. >> > >> > Regards, >> > >> > Behcet >> > >> > >> > On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig >> > > wrote: >> > >> > Hi all, >> > >> > we have used the time after the IETF to discuss various open issues >> and >> > we believe that we have covered all topics raised. >> > >> > It is our impression that the current charter text reflects the >> views of >> > the group. Here is the latest version distributed by Kepeng a few >> days >> > ago: >> > http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# >> > >> > Before we forward the charter text to the IESG we want to issue a >> 'last >> > call for comments'. Please provide your feedback at latest by >> **April >> > 10th**. >> > >> > Ciao >> > Hannes & Kepeng >> > >> > PS: Regarding the recent proxy discussion it was our impression >> that no >> > changes to the charter text are necessary. The topic can (and >> should) be >> > covered as part of the requirements/use case discussion, which is >> > already explicitly stated in the charter. >> > >> > >> > _______________________________________________ >> > 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 > > --089e0158c0d468569504f643fa0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hannes, Kepeng,

Some quick editorial re= marks:
  • [typo] But in constrained environment, =A0->=A0= But in constrained environments,=A0
  • [suggestion]=A0may not be a= vailable in existing protocols and for those cases ->=A0may not be avail= able in existing protocols; for those cases
  • [suggestion]=A0will help to stimulate ->=A0will help stimulate
    • <= li>[question] "Moreover, a standardized solution for federated authent= ication and authorization will help to stimulate the deployment of IoT devi= ces offering increased security.". Do you mean that ".. with incr= eased security", or "by offering solutions with increased securit= y"
  • [suggestion]=A0has been made the working group ->=A0has been made, t= he working group
  • [suggestion]=A0Furthermore, to guarantee smooth tr= ansition the integration ->=A0Furthermore, to guarantee smooth transitio= n, the integration
  • [suggestion]=A0To be successful this working group ->=A0To be succes= sful, this working group
  • [suggestion] In the list of tasks, maybe u= se verbs, i.e. "Produce uses cases ..." and "Identify author= ization ..."
Thomas


On Fri, Apr 4, 2014 at 4:55 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
Hi Hannes,

Reading the charter, I am confused about one thi= ng:

There is mention of clients and resource server but no mention of= resource constrained nodes or sensors. Why?

I don't think they are the clients. My guess is they are cons= idered part of the resource server.

I hope you can clarify.
Regards,

Behcet


On Fri, Apr 4, 2014 at 10:49 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Behcet,

thanks for your review. There are indeed a couple of editorial glitches
in the charter text. I have asked my co-worker Robert Taylor to do a
review to get those fixed. Will have an updated version on the Wiki in a few minutes.

Ciao
Hannes


On 04/04/2014 05:58 PM, Behcet Sarikaya wrote:
> Hi Hannes,
>
> I was reading the charter and noticed a few issues as follows:
>
>> How does the digital key communicate with the lock?
>
> I think there is something wrong with this sentence.
>
>> Both resource server and client may be resource constraint.
>
> I think it should be resource constrained.
>
> There are a few other typos also.
>
> Regards,
>
> Behcet
>
>
> On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> = wrote:
>
> =A0 =A0 Hi all,
>
> =A0 =A0 we have used the time after the IETF to discuss various open i= ssues and
> =A0 =A0 we believe that we have covered all topics raised.
>
> =A0 =A0 It is our impression that the current charter text reflects th= e views of
> =A0 =A0 the group. Here is the latest version distributed by Kepeng a = few =A0days
> =A0 =A0 ago:
> =A0 =A0 http://tools.ietf.org/wg/core/trac/wiki/ACE_charter#
>
> =A0 =A0 Before we forward the charter text to the IESG we want to issu= e a 'last
> =A0 =A0 call for comments'. Please provide your feedback at latest= by **April
> =A0 =A0 10th**.
>
> =A0 =A0 Ciao
> =A0 =A0 Hannes & Kepeng
>
> =A0 =A0 PS: Regarding the recent proxy discussion it was our impressio= n that no
> =A0 =A0 changes to the charter text are necessary. The topic can (and = should) be
> =A0 =A0 covered as part of the requirements/use case discussion, which= is
> =A0 =A0 already explicitly stated in the charter.
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 Ace mailing list
> =A0 =A0 Ace@ie= tf.org <mailto:Ace= @ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/ace
>
>



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


--089e0158c0d468569504f643fa0b-- From nobody Fri Apr 4 21:53: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 6F04A1A02B2 for ; Fri, 4 Apr 2014 21:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 z9HfaxIbbBKh for ; Fri, 4 Apr 2014 21:52:54 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A43131A00A9 for ; Fri, 4 Apr 2014 21:52:54 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so4361433pab.10 for ; Fri, 04 Apr 2014 21:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ygUQABg6UuxFuqxTGftuGv8tfiLy9pVU5V3T/dh8n3A=; b=dewZMguo7ODvX69/iammIwSFPNdqE/fbnVSsoHfqz30rbWFEeSsRQsHawKhpZLtn+b m1FB2DitJSlqCK7xlnA4CGwYsKyegRF2ubfKjqW964faFifsoYdddVCU0zLPV4vZNQCm q+D1VVsTcJnmhAVrC52vmIGXRQNwVIiEyYFLwlbXmkcvl11NpZA2VZfxMBpsmM6q3y+O nt4x8J7+Q19ZxtLJrLrM+UiAvrKBYNjn3ulKJlJomc2+KJCwd8mKuQk8XJh/1tp4z6i2 ypw1NtwlbCmzOh0csx01cAgPenFjvkI7K+tMrXlepFUHiMwEwMSDnOIAlPbkwzjYacWr F03A== X-Received: by 10.66.123.5 with SMTP id lw5mr18767343pab.83.1396673569979; Fri, 04 Apr 2014 21:52:49 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Fri, 4 Apr 2014 21:52:29 -0700 (PDT) In-Reply-To: <533EC002.2010506@gmx.net> References: <533EC002.2010506@gmx.net> From: Thomas Watteyne Date: Fri, 4 Apr 2014 21:52:29 -0700 X-Google-Sender-Auth: 6POMBIvX1drPlyZwwayYBVicCV0 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7bf0e7c80182f404f64468f6 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Feelh8qHIXpgM1tRz8xJIhOpsBA Cc: "ace@ietf.org" Subject: Re: [Ace] ABFAB Tutorial - April 22nd 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, 05 Apr 2014 04:53:07 -0000 --047d7bf0e7c80182f404f64468f6 Content-Type: text/plain; charset=ISO-8859-1 Hannes, Great! Could record the tutorial and post the recording to the ML? Thomas On Fri, Apr 4, 2014 at 7:21 AM, Hannes Tschofenig wrote: > Hi all, > > at the ACE BOF we promised to also schedule a tutorial about ABFAB. We > have been working with Margaret, Sam, and Rhys on the details and they > kindly offered to give us an overview of ABFAB and how it applies to the > IoT space. > > Date: Tuesday, April 22, 2014 > Time: 1:00 pm BST = 8am EDT = 8pm CST > > http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=22&hour=12&min=0&sec=0&p1=37&p2=136&p3=179&p4=33 > > Webex: > https://ietf.webex.com/ietf/j.php?MTID=md4e56d458aa66a2bbdfd2e1463dbc977 > > Meeting Number: 644 405 818 > Meeting Password: abfab > > Audio: > +1-650-479-3208 > Access code:644 405 818 > > Due to the IETF Webex configuration restrictions there are no other > dial-in codes available. > > Ciao > Hannes & Kepeng > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --047d7bf0e7c80182f404f64468f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hannes,
Great! Could record the tutorial and post the = recording to the ML?
Thomas


On Fri, Apr 4, 2014 at 7:21 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

at the ACE BOF we promised to also schedule a tutorial about ABFAB. We
have been working with Margaret, Sam, and Rhys on the details and they
kindly offered to give us an overview of ABFAB and how it applies to the IoT space.

Date: Tuesday, April 22, 2014
Time: 1:00 pm BST =3D 8am EDT =3D 8pm CST
http://w= ww.timeanddate.com/worldclock/meetingdetails.html?year=3D2014&month=3D4= &day=3D22&hour=3D12&min=3D0&sec=3D0&p1=3D37&p2=3D13= 6&p3=3D179&p4=3D33

Webex:
https://ietf.webex.com/ietf/j.php?MTID=3Dmd4e= 56d458aa66a2bbdfd2e1463dbc977

Meeting Number: 644 405 818
Meeting Password: abfab

Audio:
+1-650-479-3208
Access code:644 405 818

Due to the IETF Webex configuration restrictions there are no other
dial-in codes available.

Ciao
Hannes & Kepeng


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


--047d7bf0e7c80182f404f64468f6-- From nobody Sat Apr 5 01:44: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 124AF1A03B1 for ; Sat, 5 Apr 2014 01:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 1uZdFBKe5G6a for ; Sat, 5 Apr 2014 01:43:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E210E1A03AE for ; Sat, 5 Apr 2014 01:43:53 -0700 (PDT) Received: from [192.168.131.139] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LlqNY-1X5PyF20y8-00ZOra; Sat, 05 Apr 2014 10:43:47 +0200 Message-ID: <533FC1D8.5060305@gmx.net> Date: Sat, 05 Apr 2014 10:42:00 +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: Thomas Watteyne , sarikaya@ieee.org References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sGpsVBj3FuIc0D9WtNFraTbnqM93ILED4" X-Provags-ID: V03:K0:+aeKUkCo3jkyUSGBYwNkrCW1mp6+TowIz2nLjegrUfRYnx+rQBS 5vJeRkx5cglK9uDmQiEIXhkIG7jAJrZGoo5SDzgWJ0loD/1KL4aP3dru9IBJeNO8v4JFKSA U1JpVUVc/GlHpq9Hn+YO6FC89W2l/k6hEG4v8zygs3WF0f1hb/25b7tX3N50NRFW74XZFl9 u9FxxyItk9NtSUOtQF/Kw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/dzW4hJDoyRPO_Zb1mtr5YUOYHAU Cc: "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 05 Apr 2014 08:43:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sGpsVBj3FuIc0D9WtNFraTbnqM93ILED4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for taking a close look. I updated the charter text based on your feedback. Ciao Hannes On 04/05/2014 06:21 AM, Thomas Watteyne wrote: > Hannes, Kepeng, >=20 > Some quick editorial remarks: >=20 > * [typo] But in constrained environment, -> But in constrained > environments,=20 > * [suggestion] may not be available in existing protocols and for > those cases -> may not be available in existing protocols; for thos= e > cases > * [suggestion] will help to stimulate -> will help stimulate > * [question] "Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the > deployment of IoT devices offering increased security.". Do you mea= n > that ".. with increased security", or "by offering solutions with > increased security" > * [suggestion] has been made the working group -> has been made, the > working group > * [suggestion] Furthermore, to guarantee smooth transition the > integration -> Furthermore, to guarantee smooth transition, the > integration > * [suggestion] To be successful this working group -> To be > successful, this working group > * [suggestion] In the list of tasks, maybe use verbs, i.e. "Produce > uses cases ..." and "Identify authorization ..." >=20 > Thomas >=20 >=20 > On Fri, Apr 4, 2014 at 4:55 PM, Behcet Sarikaya > wrote: >=20 > Hi Hannes, >=20 > Reading the charter, I am confused about one thing: >=20 > There is mention of clients and resource server but no mention of > resource constrained nodes or sensors. Why? >=20 > I don't think they are the clients. My guess is they are considered= > part of the resource server. >=20 > I hope you can clarify. >=20 > Regards, >=20 > Behcet >=20 >=20 > On Fri, Apr 4, 2014 at 10:49 AM, Hannes Tschofenig > > wrot= e: >=20 > Hi Behcet, >=20 > thanks for your review. There are indeed a couple of editorial > glitches > in the charter text. I have asked my co-worker Robert Taylor to= do a > review to get those fixed. Will have an updated version on the > Wiki in a > few minutes. >=20 > Ciao > Hannes >=20 >=20 > On 04/04/2014 05:58 PM, Behcet Sarikaya wrote: > > Hi Hannes, > > > > I was reading the charter and noticed a few issues as follows= : > > > >> How does the digital key communicate with the lock? > > > > I think there is something wrong with this sentence. > > > >> Both resource server and client may be resource constraint. > > > > I think it should be resource constrained. > > > > There are a few other typos also. > > > > Regards, > > > > Behcet > > > > > > On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig > > = > >> wrote: > > > > Hi all, > > > > we have used the time after the IETF to discuss various > open issues and > > we believe that we have covered all topics raised. > > > > It is our impression that the current charter text > reflects the views of > > the group. Here is the latest version distributed by > Kepeng a few days > > ago: > > http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# > > > > Before we forward the charter text to the IESG we want to= > issue a 'last > > call for comments'. Please provide your feedback at lates= t > by **April > > 10th**. > > > > Ciao > > Hannes & Kepeng > > > > PS: Regarding the recent proxy discussion it was our > impression that no > > changes to the charter text are necessary. The topic can > (and should) be > > covered as part of the requirements/use case discussion, > which is > > already explicitly stated in the charter. > > > > > > _______________________________________________ > > 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 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --sGpsVBj3FuIc0D9WtNFraTbnqM93ILED4 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/ iQEcBAEBCgAGBQJTP8HYAAoJEGhJURNOOiAtDWUH/jADgN+XV00ABnmLuAAUwpY2 wm0Whs26NyjWwHy5XLhxZ7B7JkdnaxArWXyRqdxmgMqTrPq/KX1l+x6tJtjlTI/x 00LVRbjz12F2ngPdZUQ8xQhROr9IeVcdfKcLycqdYiHgwmE+QIgXICCLR4MTZ3o6 jq1z8vupA/b4LVnTwyBMy/n7GI7Vx9sgU9ptl+98sx4mr0JLac7nTEaiAeE/FABq uWl1CNWVD5Q5UZu28R07SFolEyHq20keG/uykEbWWcyaNr3Hf0sOlfKXjdNqSdAB gw95CW7mRz+33mTivmAaa1VL/vYmWMhiqolFcMwaezgREq73NBJpv+afyX9F+Ag= =xNqy -----END PGP SIGNATURE----- --sGpsVBj3FuIc0D9WtNFraTbnqM93ILED4-- From nobody Sat Apr 5 01:48: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 363F71A03B5 for ; Sat, 5 Apr 2014 01:48:22 -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 nwWFTf664AbG for ; Sat, 5 Apr 2014 01:48:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 99CBD1A03AB for ; Sat, 5 Apr 2014 01:48:17 -0700 (PDT) Received: from [192.168.131.139] ([80.92.122.106]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MBIAz-1WMDni1w5F-00AJFV; Sat, 05 Apr 2014 10:48:11 +0200 Message-ID: <533FC2DB.1040103@gmx.net> Date: Sat, 05 Apr 2014 10:46:19 +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: sarikaya@ieee.org References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xdEPJfSGwSnvmEf9E2L5NPHfxjPu4EV11" X-Provags-ID: V03:K0:2XoSOvPDyMR0BsT5zQQ83KvazR1x38PiVZ+jmCehnD96eJePTKo PrXRALlxws8Cu9Q9fF9gqOZbWLbM60HsAfuZJRovIy2tMf60phmz6JlKN01D9Bgj+YS5c0J usBtP4T5BbRvYoEArYZGCENTRhuzn8Y88cvqGIYjI9PRAirYYVOa9cCcwzj/zpmC4fsghtt ecJPxdhi1aXhUTVFgVXQw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3IASABqDj-BMJwWK63aCPlTxDMA Cc: "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 05 Apr 2014 08:48:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xdEPJfSGwSnvmEf9E2L5NPHfxjPu4EV11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Behcet, this is a terminology issue. Depending on the setup you might have a smart phone talking to a sensor or a sensor talking to some other device. We just call these client and resource server. The resource server hosts the protected resource and the client wants to access it. Who is, in the specific scenario, the constrained device depends on the setup but either the client or the resource server may be constrained. The authorization server, as we discussed on the list, is not constrained in the same way as the client and the resource server. It might be difficult to also capture these terminology aspects and use cases within the charter itself. For that purpose the interested reader will have to look at the documents. Does this explanation help? Ciao Hannes On 04/05/2014 01:55 AM, Behcet Sarikaya wrote: > Hi Hannes, >=20 > Reading the charter, I am confused about one thing: >=20 > There is mention of clients and resource server but no mention of > resource constrained nodes or sensors. Why? >=20 > I don't think they are the clients. My guess is they are considered par= t > of the resource server. >=20 > I hope you can clarify. >=20 > Regards, >=20 > Behcet >=20 >=20 > On Fri, Apr 4, 2014 at 10:49 AM, Hannes Tschofenig > > wrote: >=20 > Hi Behcet, >=20 > thanks for your review. There are indeed a couple of editorial glit= ches > in the charter text. I have asked my co-worker Robert Taylor to do = a > review to get those fixed. Will have an updated version on the Wiki= in a > few minutes. >=20 > Ciao > Hannes >=20 >=20 > On 04/04/2014 05:58 PM, Behcet Sarikaya wrote: > > Hi Hannes, > > > > I was reading the charter and noticed a few issues as follows: > > > >> How does the digital key communicate with the lock? > > > > I think there is something wrong with this sentence. > > > >> Both resource server and client may be resource constraint. > > > > I think it should be resource constrained. > > > > There are a few other typos also. > > > > Regards, > > > > Behcet > > > > > > On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig > > > >> wrote: > > > > Hi all, > > > > we have used the time after the IETF to discuss various open > issues and > > we believe that we have covered all topics raised. > > > > It is our impression that the current charter text reflects > the views of > > the group. Here is the latest version distributed by Kepeng a= > few days > > ago: > > http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# > > > > Before we forward the charter text to the IESG we want to > issue a 'last > > call for comments'. Please provide your feedback at latest by= > **April > > 10th**. > > > > Ciao > > Hannes & Kepeng > > > > PS: Regarding the recent proxy discussion it was our > impression that no > > changes to the charter text are necessary. The topic can (and= > should) be > > covered as part of the requirements/use case discussion, whic= h is > > already explicitly stated in the charter. > > > > > > _______________________________________________ > > 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 --xdEPJfSGwSnvmEf9E2L5NPHfxjPu4EV11 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/ iQEcBAEBCgAGBQJTP8LbAAoJEGhJURNOOiAtvusH/i4NwH6mgbAsee/n1v2rJqjR zzCV8vvADy088smHvhzkXOP4UpA7FWm0quyulp7ym+yy3Kt1kcEHbNmB08/8dj/y eH1PzLDceCBVedNAPnsSTF4V6e78cid6prXw1PwABM+aA+ZRhsCwis8mxIz2Vyec xU+XPjSBJsNYb4gJSRtIFzHBM9CgHgyKe0xQJeJ8tVAnVMyqtAHzKP20qbKwfPM1 X9OD+/qrb+YPQGHAnyGacBXpJdrArJ48b0jRIPcgT3n3Zqd/gQQT2zGgwD4cr2Wu v23KVRZnMMhqnBDuO+HGQ+MP3bFq3KhpJRlvzsSpxlTHYOBbWESkdxmPDO2mgZM= =ElW2 -----END PGP SIGNATURE----- --xdEPJfSGwSnvmEf9E2L5NPHfxjPu4EV11-- From nobody Mon Apr 7 09:36: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 64F4B1A0784 for ; Mon, 7 Apr 2014 09:36:16 -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 EvKDIQpvBhn5 for ; Mon, 7 Apr 2014 09:36:12 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id A24BC1A070E for ; Mon, 7 Apr 2014 09:36:11 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id q8so5129544lbi.28 for ; Mon, 07 Apr 2014 09:36:05 -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=SKclfyilmD8VDMUEyEUl+L3O/jZJZ5Fs2Mqen6CtskU=; b=MRYF0R4MbIpZC6iyDuG0LGgdTVq/dSDZOnTaT3Do6BOGcQWcNIGi+vW3um1a448cDC UBQC6+j8KIAOcdyFrfC3h2XyHb1oaT7F+cznOp2eMLWrvRZHAgktCHhzYTT7ubSPXAgl tz3sgm9YhGbb0kxwLJgDZmUvc+fU4DJVgmnTqvMEvJg2t23Xm8WAAXV+oVTS9cGq3EsZ Vg8jwVALU5Jg4suj0RUospZXp15vkRDq22+J+r/mpDGzr3i/JRN6zil55FyDx4e7u/c6 /73tIifyoBs5/mqVqqCF3j3q2DWgfTWPHeSIIefKkYnOTWX1St4siRxvfoueSp+9B7Xx OV/A== MIME-Version: 1.0 X-Received: by 10.112.150.233 with SMTP id ul9mr21137555lbb.2.1396888565338; Mon, 07 Apr 2014 09:36:05 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 7 Apr 2014 09:36:05 -0700 (PDT) In-Reply-To: <533FC2DB.1040103@gmx.net> References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@gmx.net> Date: Mon, 7 Apr 2014 11:36:05 -0500 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b342f6cba554304f6767654 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/5NLaK4ZUE2nDLXWfgv3OMzmhmFc Cc: "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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: Mon, 07 Apr 2014 16:36:16 -0000 --047d7b342f6cba554304f6767654 Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes, I am confused how the terminology would apply to this example from the charter: a door lock has to authorize the person seeking access using a "digital key". I don't we can authorize persons in IETF? Also I believe the charter should concentrate on authentication, currently it talks more about authorization. Authorization without AAA infrastructure is difficult I think. Maybe you can clarify a bit in this sentence: the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. Door lock representing the resource (resource server) with constrained node(s) authenticates the client which is the key representing the person with the help of an authentication server, etc. Is there an example whereby the client would be the constrained node? Maybe NFC use case? Regards, Behcet On Sat, Apr 5, 2014 at 3:46 AM, Hannes Tschofenig wrote: > Hi Behcet, > > this is a terminology issue. > > Depending on the setup you might have a smart phone talking to a sensor > or a sensor talking to some other device. > > We just call these client and resource server. The resource server hosts > the protected resource and the client wants to access it. > > Who is, in the specific scenario, the constrained device depends on the > setup but either the client or the resource server may be constrained. > The authorization server, as we discussed on the list, is not > constrained in the same way as the client and the resource server. > > It might be difficult to also capture these terminology aspects and use > cases within the charter itself. For that purpose the interested reader > will have to look at the documents. > > Does this explanation help? > > Ciao > Hannes > > > On 04/05/2014 01:55 AM, Behcet Sarikaya wrote: > > Hi Hannes, > > > > Reading the charter, I am confused about one thing: > > > > There is mention of clients and resource server but no mention of > > resource constrained nodes or sensors. Why? > > > > I don't think they are the clients. My guess is they are considered part > > of the resource server. > > > > I hope you can clarify. > > > > Regards, > > > > Behcet > > > > > > On Fri, Apr 4, 2014 at 10:49 AM, Hannes Tschofenig > > > wrote: > > > > Hi Behcet, > > > > thanks for your review. There are indeed a couple of editorial > glitches > > in the charter text. I have asked my co-worker Robert Taylor to do a > > review to get those fixed. Will have an updated version on the Wiki > in a > > few minutes. > > > > Ciao > > Hannes > > > > > > On 04/04/2014 05:58 PM, Behcet Sarikaya wrote: > > > Hi Hannes, > > > > > > I was reading the charter and noticed a few issues as follows: > > > > > >> How does the digital key communicate with the lock? > > > > > > I think there is something wrong with this sentence. > > > > > >> Both resource server and client may be resource constraint. > > > > > > I think it should be resource constrained. > > > > > > There are a few other typos also. > > > > > > Regards, > > > > > > Behcet > > > > > > > > > On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig > > > > > > >> wrote: > > > > > > Hi all, > > > > > > we have used the time after the IETF to discuss various open > > issues and > > > we believe that we have covered all topics raised. > > > > > > It is our impression that the current charter text reflects > > the views of > > > the group. Here is the latest version distributed by Kepeng a > > few days > > > ago: > > > http://tools.ietf.org/wg/core/trac/wiki/ACE_charter# > > > > > > Before we forward the charter text to the IESG we want to > > issue a 'last > > > call for comments'. Please provide your feedback at latest by > > **April > > > 10th**. > > > > > > Ciao > > > Hannes & Kepeng > > > > > > PS: Regarding the recent proxy discussion it was our > > impression that no > > > changes to the charter text are necessary. The topic can (and > > should) be > > > covered as part of the requirements/use case discussion, which > is > > > already explicitly stated in the charter. > > > > > > > > > _______________________________________________ > > > 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 > > > > --047d7b342f6cba554304f6767654 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

I am confused how the termino= logy would apply to this example
from the charter:

a door = lock has to authorize the person seeking access using a "digital key&q= uot;.

I don't= we can authorize persons in IETF?

= Also I believe the charter should concentrate on authentication, currently = it talks more about authorization.
Authorization without AAA infrastructure i= s difficult I think.

Maybe you can = clarify a bit in this sentence:
the need arises for a dynamic and fine g= rained access control mechanism, where clients and/or resource servers are = constrained.

Door lock representing the resource (r= esource server) with constrained node(s) authenticates the client which is = the key representing the person with the help of an authentication server, = etc.

Is there an example whereby the client= would be the constrained node? Maybe NFC use case?


Regards,

Behcet

On Sat, Apr 5, 2014 at 3:46= AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> w= rote:
Hi Behcet,

this is a terminology issue.

Depending on the setup you might have a smart phone talking to a sensor
or a sensor talking to some other device.

We just call these client and resource server. The resource server hosts the protected resource and the client wants to access it.

Who is, in the specific scenario, the constrained device depends on the
setup but either the client or the resource server may be constrained.
The authorization server, as we discussed on the list, is not
constrained in the same way as the client and the resource server.

It might be difficult to also capture these terminology aspects and use
cases within the charter itself. For that purpose the interested reader
will have to look at the documents.

Does this explanation help?

Ciao
Hannes


On 04/05/2014 01:55 AM, Behcet Sarikaya wrote:
> Hi Hannes,
>
> Reading the charter, I am confused about one thi= ng:
>
> There is mention of clients and resource server but no mention of
> resource constrained nodes or sensors. Why?
>
> I don't think they are the clients. My guess is they are considere= d part
> of the resource server.
>
> I hope you can clarify.
>
> Regards,
>
> Behcet
>
>
> On Fri, Apr 4, 2014 at 10:49 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
> =A0 =A0 Hi Behcet,
>
> =A0 =A0 thanks for your review. There are indeed a couple of editorial= glitches
> =A0 =A0 in the charter text. I have asked my co-worker Robert Taylor t= o do a
> =A0 =A0 review to get those fixed. Will have an updated version on the= Wiki in a
> =A0 =A0 few minutes.
>
> =A0 =A0 Ciao
> =A0 =A0 Hannes
>
>
> =A0 =A0 On 04/04/2014 05:58 PM, Behcet Sarikaya wrote:
> =A0 =A0 > Hi Hannes,
> =A0 =A0 >
> =A0 =A0 > I was reading the charter and noticed a few issues as fol= lows:
> =A0 =A0 >
> =A0 =A0 >> How does the digital key communicate with the lock? > =A0 =A0 >
> =A0 =A0 > I think there is something wrong with this sentence.
> =A0 =A0 >
> =A0 =A0 >> Both resource server and client may be resource const= raint.
> =A0 =A0 >
> =A0 =A0 > I think it should be resource constrained.
> =A0 =A0 >
> =A0 =A0 > There are a few other typos also.
> =A0 =A0 >
> =A0 =A0 > Regards,
> =A0 =A0 >
> =A0 =A0 > Behcet
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig
> =A0 =A0 > <hannes.t= schofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>
> =A0 =A0 <mailto:= hannes.tschofenig@gmx.net
> =A0 =A0 <mailto:hannes.tschofenig@gmx.net>>> wrote:
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Hi all,
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 we have used the time after the IETF to discuss v= arious open
> =A0 =A0 issues and
> =A0 =A0 > =A0 =A0 we believe that we have covered all topics raised= .
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 It is our impression that the current charter tex= t reflects
> =A0 =A0 the views of
> =A0 =A0 > =A0 =A0 the group. Here is the latest version distributed= by Kepeng a
> =A0 =A0 few =A0days
> =A0 =A0 > =A0 =A0 ago:
> =A0 =A0 > =A0 =A0 http://tools.ietf.org/wg/core/trac/wiki/A= CE_charter#
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Before we forward the charter text to the IESG we= want to
> =A0 =A0 issue a 'last
> =A0 =A0 > =A0 =A0 call for comments'. Please provide your feedb= ack at latest by
> =A0 =A0 **April
> =A0 =A0 > =A0 =A0 10th**.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Ciao
> =A0 =A0 > =A0 =A0 Hannes & Kepeng
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 PS: Regarding the recent proxy discussion it was = our
> =A0 =A0 impression that no
> =A0 =A0 > =A0 =A0 changes to the charter text are necessary. The to= pic can (and
> =A0 =A0 should) be
> =A0 =A0 > =A0 =A0 covered as part of the requirements/use case disc= ussion, which is
> =A0 =A0 > =A0 =A0 already explicitly stated in the charter.
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 _______________________________________________ > =A0 =A0 > =A0 =A0 Ace mailing list
> =A0 =A0 > =A0 =A0 Ace@i= etf.org <mailto:Ace@ietf.org>= <mailto:Ace@ietf.org
> =A0 =A0 <mailto:Ace= @ietf.org>>
> =A0 =A0 > =A0 =A0 https://www.ietf.org/mailman/listinfo/ace
> =A0 =A0 >
> =A0 =A0 >
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


--047d7b342f6cba554304f6767654-- From nobody Mon Apr 7 09:46: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 4F0E61A0476 for ; Mon, 7 Apr 2014 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 dfLMt-zvyjTQ for ; Mon, 7 Apr 2014 09:46:34 -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 815DF1A0473 for ; Mon, 7 Apr 2014 09:46:34 -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 s37GkHcV015696; Mon, 7 Apr 2014 18:46:17 +0200 (CEST) Received: from [134.102.117.228] (unknown [134.102.117.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E80265A6; Mon, 7 Apr 2014 18:46:16 +0200 (CEST) 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: Mon, 7 Apr 2014 18:46:15 +0200 X-Mao-Original-Outgoing-Id: 418581975.289881-dc3ee7498fe65ddc605e685249f1e36b Content-Transfer-Encoding: quoted-printable Message-Id: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@gmx.net> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/kYyK0xDcyEHBzZA3GVj6QXTZqbg Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 07 Apr 2014 16:46:39 -0000 On 07 Apr 2014, at 18:36, Behcet Sarikaya = wrote: > Hi Hannes, >=20 > I am confused how the terminology would apply to this example=20 > from the charter: >=20 > a door lock has to authorize the person seeking access using a = "digital key".=20 >=20 > I don't we can authorize persons in IETF? People are indeed authenticated; one typically authorizes a person for = specific actions only. (I read the existing text as a statement about authorizing an action, = =93the person seeking access=94; this could be clarified.) > Also I believe the charter should concentrate on authentication, That is the part for which we have enough protocols already. > currently it talks more about authorization. Which is exactly what it should do; authentication is ancillary to the = objective of authorization. > Authorization without AAA infrastructure is difficult I think. That statement depends so much on the definitions of =93AAA=94 and = =93infrastructure=94 that I don=92t know how assign a truth value to it. > Is there an example whereby the client would be the constrained node? = Maybe NFC use case? The client might be a light switch, and the server might be a lamp. Gr=FC=DFe, Carsten From nobody Mon Apr 7 11:40: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 636411A084D for ; Mon, 7 Apr 2014 11:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 lSv_ylgJZt5D for ; Mon, 7 Apr 2014 11:40:12 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B9F911A0705 for ; Mon, 7 Apr 2014 11:40:01 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ec20so5244956lab.29 for ; Mon, 07 Apr 2014 11:39:55 -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=ed+rVpsSjLVkrAcTZrZ86GpQ4OLVWBxvnJPv9MO2GJs=; b=DmmJuKOZSq84QpnfjSahFqLVMjpvHgU4dNaC9r/61Jd9yozLigmfGu7Rzs9MMusGPD Nf8JERDAruorKA6YqnW9tfSGhA1KqzW4y6F/jnLsdVtmkiBBxgyfJrLflxrrfihXPuSY RP7j7xpedhBh1CwgXoAU79f6Te/H+2lItkVVAj7KYNlubpxzpJJEEQl/ujzZxwV7FkZo 5nZ7eNEGpTdmYHt84+bvLiv83UWebjAu9kSZojdaxCnoYBgEeaehOIHGG19n6oDAOKc0 IMIjAzot5kNlanN+F9Sdea/z9yTqOqa1XPYFcs+kFs8TEEUANA8UigPxd0/i3d5lVarM 2u/Q== MIME-Version: 1.0 X-Received: by 10.152.116.43 with SMTP id jt11mr2508229lab.41.1396895995494; Mon, 07 Apr 2014 11:39:55 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 7 Apr 2014 11:39:55 -0700 (PDT) In-Reply-To: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@gmx.net> Date: Mon, 7 Apr 2014 13:39:55 -0500 Message-ID: From: Behcet Sarikaya To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c365689984d804f6783101 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/CeiNwN-Vsmb46Qs-6VZIeND6LuI Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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: Mon, 07 Apr 2014 18:40:17 -0000 --001a11c365689984d804f6783101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carsten, Thanks for your reply. No, I am not going away :-) Please see inline below. On Mon, Apr 7, 2014 at 11:46 AM, Carsten Bormann wrote: > On 07 Apr 2014, at 18:36, Behcet Sarikaya wrote: > > > Hi Hannes, > > > > I am confused how the terminology would apply to this example > > from the charter: > > > > a door lock has to authorize the person seeking access using a "digital > key". > > > > I don't we can authorize persons in IETF? > > People are indeed authenticated; one typically authorizes a person for > specific actions only. > (I read the existing text as a statement about authorizing an action, "th= e > person seeking access"; this could be clarified.) > > Yes, please. > > Also I believe the charter should concentrate on authentication, > > That is the part for which we have enough protocols already. > > > currently it talks more about authorization. > > Which is exactly what it should do; authentication is ancillary to the > objective of authorization. > > I don't think there is something called authorization protocol. Oauth talks about authorization grant not authorization protocol. Maybe an authorization protocol would be search in a database but none wants to do it. > > Authorization without AAA infrastructure is difficult I think. > > That statement depends so much on the definitions of "AAA" and > "infrastructure" that I don't know how assign a truth value to it. > > See above. I meant the use in an operator's domain. > > Is there an example whereby the client would be the constrained node? > Maybe NFC use case? > > The client might be a light switch, and the server might be a lamp. > > You mean light switch would be authorized to access the lamp? Regards, Behcet > Gr=FC=DFe, Carsten > > --001a11c365689984d804f6783101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

Thanks for your re= ply.

No, I am not going away :-)

Please see inlin= e below.


O= n Mon, Apr 7, 2014 at 11:46 AM, Carsten Bormann <cabo@tzi.org> wr= ote:
On 07 Apr 2014, at 18:36, Be= hcet Sarikaya <sarikaya2012@gm= ail.com> wrote:

> Hi Hannes,
>
> I am confused how the terminology would apply to this example
> from the charter:
>
> a door lock has to authorize the person seeking access using a "d= igital key".
>
> I don't we can authorize persons in IETF?

People are indeed authenticated; one typically authorizes a person fo= r specific actions only.
(I read the existing text as a statement about authorizing an action, &ldqu= o;the person seeking access”; this could be clarified.)


Yes, please.
=  
> Also I believe the charter should concentrate on authentication,

That is the part for which we have enough protocols already.

> currently it talks more about authorization.

Which is exactly what it should do; authentication is ancillary to th= e objective of authorization.


I don't thin= k there is something called authorization protocol.
Oauth tal= ks about authorization grant not authorization protocol.
Mayb= e an authorization protocol would be search in a database but none wants to= do it.
 
> Authorization without AAA infrastructure is difficult I think.

That statement depends so much on the definitions of “AAA&rdquo= ; and “infrastructure” that I don’t know how assign a tru= th value to it.


See above. I mea= nt the use in an operator's domain.
 
> Is there an example whereby the client would be the constrained node? = Maybe NFC use case?

The client might be a light switch, and the server might be a lamp.
You mean light switch would be authorized to access t= he lamp?

Regards,

Behcet
Gr=FC=DFe, Carsten


--001a11c365689984d804f6783101-- From nobody Tue Apr 8 06:08: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 9B6001A03AD for ; Tue, 8 Apr 2014 06:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 BJmuQeG2F_Wo for ; Tue, 8 Apr 2014 06:07:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5091A03B5 for ; Tue, 8 Apr 2014 06:07:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f3b8e0000006f1-f7-5343f4a50200 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 56.37.01777.5A4F3435; Tue, 8 Apr 2014 15:07:50 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Tue, 8 Apr 2014 15:07:49 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Carsten Bormann , "sarikaya@ieee.org" Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text Thread-Index: AQHPTwesnxCOmPukp0qz1DHybcYoEJsBfdCA///9lgCAAIfKgIAAlECAgAOn6oCAAALXgIABh5iA Date: Tue, 8 Apr 2014 13:07:49 +0000 Message-ID: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@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.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RnfZF+dgg5//uCy+f+thtjgy5S6r xdKd91gtZveeZnFg8Vi8aT+bx9MJB5k8liz5yeQxbVFmAEsUl01Kak5mWWqRvl0CV8a/xx8Y C+aJVGxYvYetgfG+QBcjJ4eEgInEhVe3mCBsMYkL99azdTFycQgJHGaUeLrvNguEs4hR4u+n ZcwgVWwCrhIHHrwD6xAR8JZ43b+dEcRmFgiSuHn9AliNsICtxIJ5D9ggauwkPvz8wg5hR0n0 3pwCNJSDg0VAReLCPCOQMK+AucTU9zNYIXY9Y5I4MectWC+ngLXEk+5pYPMZga77fmoNE8Qu cYlbT+ZDXS0gsWTPeWYIW1Ti5eN/rCC2qICexL1Hc1kg4koSPzZcYoHo1ZO4MXUKG4RtLXHg 3Emo+7Ulli18zQxxkKDEyZlPWCYwSsxCsm4WkvZZSNpnIWmfhaR9ASPrKkb23MTMnPRyo02M wJg8uOW36g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxeu7T a7eTck4G5Ph4vvc9Gb716XxlzhsODBeVj/+pcz/D9rlFvWQe74a1P/s7T5zP2LXX4eKtdg6D FU3HGX2T3oXO+WLWsUi4pHC3q9+xHrGM0J01/nPOHZSdVVk4adLr/h+rbqx6Vn9RckLdsevT 1T///lwX67F+3d1J3V7fWXv8uSaVbRV3UGIpzkg01GIuKk4EAIkwDVmXAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/4lQ0x6ReOrsIYGnWZo3tcw2NGFg Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 08 Apr 2014 13:07:58 -0000 On 07/04/14 18:46, "Carsten Bormann" wrote: >On 07 Apr 2014, at 18:36, Behcet Sarikaya wrote: > > >> Also I believe the charter should concentrate on authentication, > >That is the part for which we have enough protocols already. > >> currently it talks more about authorization. > >Which is exactly what it should do; authentication is ancillary to the >objective of authorization. I think there is one point here that should be clarified in the charter. The title of this proposed WG is "Authentication and authorisation in Constrained Environments=B2 (not "Authorisation in Constrained Environments=B2) and for a good reason. Authorisation depends on authentication, and we want to allow authentication and authorisation to be based on common trust roots (provisioned keys etc.) and common key management: - Clearly we don=B9t want one procedure for provisioning keys for verifying the integrity of authorisation information and a another procedure for provisioning keys for authentication of each client. - Also, to bind the authorisation of a client to a particular requesting client, the resource server must have access to a key representing the client identified in the authorisation information. - Moreover keys for authorisation needs to be managed, renewed at certain times, etc. just like keys for authentication. I would like to have a sentence or two in the charter clarifying this. How about the following: "A common key management solution for authentication and authorisation will be provided to optimise key provisioning in constrained devices." Put in context below: Existing authentication and authorization protocols will be used and re-applied for use in constrained environments where applicable. _A common key management solution for authentication and authorisation will be provided to optimise key provisioning in constrained devices._ This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols and thus new standardization efforts will be required. Leveraging existing work means the working 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 constrained devices that provide increased security. G=F6ran From nobody Tue Apr 8 09:29: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 9D22A1A04A6 for ; Tue, 8 Apr 2014 09:29:29 -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 JpUeQm0Ns7u7 for ; Tue, 8 Apr 2014 09:29:25 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B739E1A0484 for ; Tue, 8 Apr 2014 09:29:24 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id r7so748670bkg.12 for ; Tue, 08 Apr 2014 09:29:24 -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=mFg7iV3a7EJcaL3csgFirLaeTP3/Aqwo6fC1cyC/FtI=; b=IAkeZLUnRGmZLMKnAbWdae4vvoIXrEzIxr3CD29Hg6JjEqtdbSZXRGbOcRlevEEEyP y+iEFCA65hOxfCL9xgVftkRoeRPVBXiy9MHa2ImsZRlGV1XCIOIgCUMkR/kK3j78Lrza ZeQHEme1g8CWEuujiJXBwYHobD1v/Y520sZmrlcoIXu3sxGkoAegyoHDlqmhh4lrQxa7 iTRdT9YEe7tjNoBUFjNafzVXdPDgAS4zKMAgmIq/13spRnRJkH87BdIv4DHkOf4yUK2C xNZ4V3AwYFOTep1zdQyLRrUUQl5Grjo7tvar4Y7bw7bRyI/paradXnev9psIzzns5ecG +v4w== MIME-Version: 1.0 X-Received: by 10.152.2.131 with SMTP id 3mr3546715lau.20.1396974564063; Tue, 08 Apr 2014 09:29:24 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Tue, 8 Apr 2014 09:29:24 -0700 (PDT) In-Reply-To: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@gmx.net> Date: Tue, 8 Apr 2014 11:29:24 -0500 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?Q?G=F6ran_Selander?= Content-Type: multipart/alternative; boundary=089e013c674ca6bee804f68a7c3f Archived-At: http://mailarchive.ietf.org/arch/msg/ace/2p6j7bFLr15AT8RnBPHeuMt-ujQ Cc: Carsten Bormann , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 08 Apr 2014 16:29:29 -0000 --089e013c674ca6bee804f68a7c3f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 8, 2014 at 8:07 AM, G=F6ran Selander wrote: > > > On 07/04/14 18:46, "Carsten Bormann" wrote: > > >On 07 Apr 2014, at 18:36, Behcet Sarikaya wrote= : > > > > > >> Also I believe the charter should concentrate on authentication, > > > >That is the part for which we have enough protocols already. > > > >> currently it talks more about authorization. > > > >Which is exactly what it should do; authentication is ancillary to the > >objective of authorization. > > I think there is one point here that should be clarified in the charter. > The title of this proposed WG is "Authentication and authorisation in > Constrained Environments=B2 (not "Authorisation in Constrained > Environments=B2) and for a good reason. Authorisation depends on > authentication, and we want to allow authentication and authorisation to > be based on common trust roots (provisioned keys etc.) and common key > management: > > - Clearly we don=B9t want one procedure for provisioning keys for verifyi= ng > the integrity of authorisation information and a another procedure for > provisioning keys for authentication of each client. > > - Also, to bind the authorisation of a client to a particular requesting > client, the resource server must have access to a key representing the > client identified in the authorisation information. > > - Moreover keys for authorisation needs to be managed, renewed at certain > times, etc. just like keys for authentication. > > > I would like to have a sentence or two in the charter clarifying this. Ho= w > about the following: > > "A common key management solution for authentication and authorisation > will be provided to optimise key provisioning in constrained devices." > > > This sounds good but I am not sure if it applies to the case where the client is not a constrained device? Regards, Behcet --089e013c674ca6bee804f68a7c3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 8, 2014 at 8:07 AM, G=F6ran Selander = <goran.= selander@ericsson.com> wrote:


On 07/04/14 18:46, "Carsten Bormann" <cabo@tzi.org> wrote:

>On 07 Apr 2014, at 18:36, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
>
>
>> Also I believe the charter should concentrat= e on authentication,
>
>That is the part for which we have enough protocols already.
>
>> currently it talks more about authorization.
>
>Which is exactly what it should do; authentication is ancillary to the<= br> >objective of authorization.

I think there is one point here that should be clarified in the chart= er.
The title of this proposed WG is "Authentication and authorisation in<= br> Constrained Environments=B2 (not "Authorisation in Constrained
Environments=B2) and for a good reason. Authorisation depends on
authentication, and we want to allow authentication and authorisation to be based on common trust roots (provisioned keys etc.) and common key
management:

- Clearly we don=B9t want one procedure for provisioning keys for verifying=
the integrity of authorisation information and a another procedure for
provisioning keys for authentication of each client.

- Also, to bind the authorisation of a client to a particular requesting client, the resource server must have access to a key representing the
client identified in the authorisation information.

- Moreover keys for authorisation needs to be managed, renewed at certain times, etc. just like keys for authentication.


I would like to have a sentence or two in the charter clarifying this. How<= br> about the following:

"A common key management solution for authentication and authorisation=
will be provided to optimise key provisioning in constrained devices."=



This sounds good but I am not sure if it applies to the case wh= ere the client is not a constrained device?

Regards,

Behcet

--089e013c674ca6bee804f68a7c3f-- From nobody Tue Apr 8 13:16: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 14C481A026A for ; Tue, 8 Apr 2014 13:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 VO5MmBu0rJzU for ; Tue, 8 Apr 2014 13:16:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB421A0218 for ; Tue, 8 Apr 2014 13:16:30 -0700 (PDT) Received: from [192.168.37.138] ([209.133.115.210]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MN604-1WeC1E0ocS-006dlv; Tue, 08 Apr 2014 22:16:04 +0200 Message-ID: <53445901.6070602@gmx.net> Date: Tue, 08 Apr 2014 22:16:01 +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: sarikaya@ieee.org, =?ISO-8859-1?Q?G=F6ran_Selander?= References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2pl5RvQlPfoK1MxeKSskq4jWfT22LH0Ms" X-Provags-ID: V03:K0:XN82AWibxyyCHCUihoudYZe0705WevQo3z08HQXElPweBRuK3Ua 7d6A8dY26fjhmeuOuyGe0w4aolQCI6y/Li/+YF6R9siGHn+u5WRIKKpo868BWoDc1okQcKo tG57SfwIRNPTiYjMrFWcnKT/r9iLB9k7e2YzXg6/DpPg0pq2To24sWxN6HkVAqkVCrzei+1 zPTk/KCK7BXCmjNz6aufw== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/UOqKcWA4YVa_uSyt-bZ8yLSFoSM Cc: Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 08 Apr 2014 20:16:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2pl5RvQlPfoK1MxeKSskq4jWfT22LH0Ms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Behcet, Hi G=F6ran, Hi Carsten, thanks for the feedback. I am wondering whether we are stretching the concept of a charter text here a bit too much. I am saying that because the charter is a teaser for the reader to continue looking in the rest of the documents. It is not a replacement for actually reading the specs and it is also not a tutorial. Behcet, have you had a chance to look at the requirements / use case document that provider further background? Ciao Hannes On 04/08/2014 06:29 PM, Behcet Sarikaya wrote: >=20 >=20 >=20 > On Tue, Apr 8, 2014 at 8:07 AM, G=F6ran Selander > > wrot= e: >=20 >=20 >=20 > On 07/04/14 18:46, "Carsten Bormann" > wrote: >=20 > >On 07 Apr 2014, at 18:36, Behcet Sarikaya > wrote: > > > > > >> Also I believe the charter should concentrate on authentication,= > > > >That is the part for which we have enough protocols already. > > > >> currently it talks more about authorization. > > > >Which is exactly what it should do; authentication is ancillary to= the > >objective of authorization. >=20 > I think there is one point here that should be clarified in the cha= rter. > The title of this proposed WG is "Authentication and authorisation = in > Constrained Environments=B2 (not "Authorisation in Constrained > Environments=B2) and for a good reason. Authorisation depends on > authentication, and we want to allow authentication and authorisati= on to > be based on common trust roots (provisioned keys etc.) and common k= ey > management: >=20 > - Clearly we don=B9t want one procedure for provisioning keys for > verifying > the integrity of authorisation information and a another procedure = for > provisioning keys for authentication of each client. >=20 > - Also, to bind the authorisation of a client to a particular reque= sting > client, the resource server must have access to a key representing = the > client identified in the authorisation information. >=20 > - Moreover keys for authorisation needs to be managed, renewed at > certain > times, etc. just like keys for authentication. >=20 >=20 > I would like to have a sentence or two in the charter clarifying > this. How > about the following: >=20 > "A common key management solution for authentication and authorisat= ion > will be provided to optimise key provisioning in constrained device= s." >=20 >=20 >=20 > This sounds good but I am not sure if it applies to the case where the > client is not a constrained device? >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --2pl5RvQlPfoK1MxeKSskq4jWfT22LH0Ms 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/ iQEcBAEBCgAGBQJTRFkBAAoJEGhJURNOOiAtnsgH/2z0HgtZB49oEZkl80JNole0 O5V2eNLndePKJMuXjl8a5yRkCos1e6Ey+etLy4NwqPT+ifNkiS9BZ/Ujb+DrCPlX 5zQPLdkEBWN707ziAmtxwR+fTFkd+qxZE26qiB8CKaNKffk1v/l7jYptg/xfrpbA gSqgIzeWRLygbdEHkaNW4IAXWyRCbWWQHvE3Zf5MkQzOHmvFZAF5zbFJXreP7w4d QeJlgvEO1za10Cgmj9U26Jm/Kma0l23LBzYNvD661wm9v+KNbGUGaAeqxuUg8kZx N5LTmRqQqR383nLWoSc5t3UsjHanA1uMKf4BfHo+dsdcKKOl6P4jbq20HLc/FvI= =Irf5 -----END PGP SIGNATURE----- --2pl5RvQlPfoK1MxeKSskq4jWfT22LH0Ms-- From nobody Tue Apr 8 23:29: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 9975C1A011F for ; Tue, 8 Apr 2014 23:29:43 -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 ub87KZ5MjfUU for ; Tue, 8 Apr 2014 23:29:42 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id B7C491A0116 for ; Tue, 8 Apr 2014 23:29:41 -0700 (PDT) X-AuditID: c1b4fb31-b7f688e000003e64-d5-5344e8d168d8 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 05.F8.15972.1D8E4435; Wed, 9 Apr 2014 08:29:37 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 08:29:36 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Hannes Tschofenig , "sarikaya@ieee.org" Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text Thread-Index: AQHPTwesnxCOmPukp0qz1DHybcYoEJsBfdCA///9lgCAAIfKgIAAlECAgAOn6oCAAALXgIABh5iAgAAGCACAAD9QgIAA3bmA Date: Wed, 9 Apr 2014 06:29:35 +0000 Message-ID: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@gmx.net> <53445901.6070602@gmx.net> In-Reply-To: <53445901.6070602@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: <1389BF2E85D2C248BF42A16D06C105BE@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM+Jvje6lFy7BBqs/m1p8/9bDbHFkyl1W i6U777FazO49zeLA4rF40342j6cTDjJ5LFnyk8lj2qLMAJYoLpuU1JzMstQifbsErozZqyew FNzgrviyayFLA+MWzi5GTg4JAROJh52fGCFsMYkL99azgdhCAicZJe4eDeti5AKyFzFKnOk/ DlbEJuAqceDBOyYQW0QgRuLStAZWEJtZwFHi/L0eMFtYwFZiwbwHbBA1dhIffn5hh7DzJH60 /QOzWQRUJFaufA42k1fAXOJd50pGiGU/mCXe/Ia4iFNAXeL7kU1gQxmBrvt+ag0TxDJxiVtP 5jNBXC0gsWTPeWYIW1Ti5eN/YPWiAnoS9x7NZYGIK0k0LnkCdaiexI2pU9ggbGuJEyeXsEPY 2hLLFr5mhjhIUOLkzCcsExglZiFZNwtJ+ywk7bOQtM9C0r6AkXUVo2RxanFSbrqRoV5uem6J XmpRZnJxcX6eXnHqJkZg3B7c8ttwB+PEa/aHGKU5WJTEeRmmdwYJCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYPQo/Lgo1GahruX2h117kpzXTfmfbZ+0KmTRO35P5tlhDlM+Os6JY9yjNlU1 /8Dyx6d332BZ0HPpTITrBWeBqquzFrfEZAfznBcTnfvOTjh6vQAH/4ncnaYCAant7m4C844/ 3zJvZTXv3o6VYr9Ws5d/W3ik6t5diYiJL2rSTLPd/FvKD/rfO6DEUpyRaKjFXFScCADpJUf+ qQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/eGxslvWbheAzz-9P-yZ6xDghfh0 Cc: Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 09 Apr 2014 06:29:43 -0000 On 08/04/14 22:16, "Hannes Tschofenig" wrote: >Hi Behcet, Hi G=F6ran, Hi Carsten, > >thanks for the feedback. > >I am wondering whether we are stretching the concept of a charter text >here a bit too much. I am saying that because the charter is a teaser >for the reader to continue looking in the rest of the documents. It is >not a replacement for actually reading the specs and it is also not a >tutorial. In addition to be a teaser, isn=B9t another objective of the charter to clarify the work to be done? Currently there is no explanation how authentication and authorisation should work together. There are 15+ drafts on the list of existing work and in those very little guidance on this topic. You may call it obvious or a tutorial, to explicitly state that the solution should allow a common key management for authentication and authorisation. I can imagine people with a different mindset think of solutions which require you to provision to the resource server both (a) keys of the authorisation server(s), and (a) keys for each candidate client. For some use cases this is not a problem, but e.g. looking at the spontaneous change of access control policies, the authorisation of a client hitherto unknown to the resource server should not require making an out-of-band provisioning of client keys to the resource server. (And if it is obvious then there is little harm adding one sentence, right?) G=F6ran From nobody Tue Apr 8 23:31: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 37E3A1A0120 for ; Tue, 8 Apr 2014 23:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s1r8BDpPMdxo for ; Tue, 8 Apr 2014 23:31:26 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B83C41A011F for ; Tue, 8 Apr 2014 23:31:24 -0700 (PDT) X-AuditID: c1b4fb38-b7f518e000000889-3f-5344e93b94d8 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0C.E0.02185.B39E4435; Wed, 9 Apr 2014 08:31:23 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 08:31:22 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "sarikaya@ieee.org" Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text Thread-Index: AQHPTwesnxCOmPukp0qz1DHybcYoEJsBfdCA///9lgCAAIfKgIAAlECAgAOn6oCAAALXgIABh5iAgAAGCACAAR2IAA== Date: Wed, 9 Apr 2014 06:31:22 +0000 Message-ID: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@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.148] Content-Type: multipart/alternative; boundary="_000_CF6A74A7E5C1goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rtf6pUuwwdxvxhbfv/UwWxyZcpfV YunOe6wWs3tPsziweCzetJ/N4+mEg0weS5b8ZPKYtigzgCWKyyYlNSezLLVI3y6BK+P+7tKC b5IVt77/ZG5gnCvWxcjJISFgItG95hYThC0mceHeerYuRi4OIYGjjBK9h69COYsYJV493M0K UsUm4Cpx4ME7sA4RAW2JHYd2MILYzAJFEmum/waLCwvYSiyY94ANosZO4sPPL+wQdpbE2yN9 LCA2i4CKxPll/4F6OTh4BcwlTv/OgNh1m1niYuMDsJmcAoESm2fuBqtnBLru+6k1TBC7xCVu PZkPdbWAxJI955khbFGJl4//gd0pKqAnce/RXBaIuJJE45InrBC9MRKHZh8Gm88rIChxcuYT lgmMYrOQjJ2FpGwWkjKIuJ7EjalT2CBsbYllC18zQ9i6EjP+HQKq4QCyrSVa7xgiK1nAyLGK kaM4tTgpN93IYBMjMFIPbvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQW H2Jk4uCUagB6//qkd0+yLZv+3b0hHjfjhtyjCKGNR98V5fxX7prTm6M2ZfZXpo69zi/1DUV/ X3t7VWSCgLIE08aVlzycIzkKTzgfFlCe8HxKw69vIRyvXmadE5u0kyFu1/rP6q/OFCo+vjT9 bOayylsm+8yeqe57GX3tsZvBm58Vrw6n7fydK5DjGli5O5hTiaU4I9FQi7moOBEABV9r/6IC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/wtYMs8G_5eSOpdz8epyRxMQUr8Y Cc: Carsten Bormann , Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 09 Apr 2014 06:31:27 -0000 --_000_CF6A74A7E5C1goranselanderericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, From: Behcet Sarikaya > "A common key management solution for authentication and authorisation will be provided to optimise key provisioning in constrained devices." This sounds good but I am not sure if it applies to the case where the clie= nt is not a constrained device? I thought of this mainly from the point of view of a provisioning to constr= ained devices, but it should also apply in general. How about this: "A common key management solution for authentication and authorisation will be provided to optimise key provisioning." G=F6ran --_000_CF6A74A7E5C1goranselanderericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1BA8676DCF0B004FA7AD9022AB7FCA17@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Behcet, 

From: Behcet Sarikaya <sarikaya2012@gmail.com>


"A common key management solution for authentication and authorisation=
will be provided to optimise key provisioning in constrained devices."=



This sounds good but I am not sure if it applies to the case where the clie= nt is not a constrained device?

I thought of this mainly from the point of view of a provisioning to c= onstrained devices, but it should also apply in general. How about this:

"A common key management solution for authentication and authoris= ation
will be provided to optimise key provisioning."


G=F6ran
--_000_CF6A74A7E5C1goranselanderericssoncom_-- From nobody Tue Apr 8 23:32: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 725FE1A0116 for ; Tue, 8 Apr 2014 23:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 L5ahDxY4afVr for ; Tue, 8 Apr 2014 23:32:03 -0700 (PDT) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 677171A012B for ; Tue, 8 Apr 2014 23:32:03 -0700 (PDT) X-AuditID: c1b4fb28-b7fd58e000007bb5-6c-5344e9623081 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 01.49.31669.269E4435; Wed, 9 Apr 2014 08:32:02 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 08:32:01 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "sarikaya@ieee.org" , Carsten Bormann Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text Thread-Index: AQHPTwesnxCOmPukp0qz1DHybcYoEJsBfdCA///9lgCAAIfKgIAAlECAgAOn6oCAAALXgIAAH8KAgAKLlYA= Date: Wed, 9 Apr 2014 06:32:01 +0000 Message-ID: References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@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: multipart/alternative; boundary="_000_CF6A767DE5DEgoranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM+JvjW7SS5dgg+mnJSy+f+thtjgy5S6r xdKd91gtZveeZnFg8Vi8aT+bx9MJB5k8liz5yeQxbVFmAEsUl01Kak5mWWqRvl0CV8byq3/Z Cv4JVyy53cPUwDhDsIuRk0NCwESib9M5VghbTOLCvfVsXYxcHEICJxkl5l6dwAzhLGKUePti PRNIFZuAq8SBB++AbA4OEQFviZ4ZViBhZoEgiZvXLzCD2MICthIL5j1gA7FFBOwkPvz8wg5h J0m8n9YANoZFQEVi15zJYPW8AuYSG/4tg9q1llni5e7dYBdxCgRK7DryhRHEZgS67vupNUwQ y8Qlbj2ZzwRxtYDEkj3nmSFsUYmXj/+B9YoK6EncezSXBSKuJLFi+yVGkJuZBWIklvyQgtgr KHFy5hOWCYxis5BMnYVQNQtJFUSJnsSNqVPYIGxtiWULXzND2LoSM/4dYoFotZb4dosRWckC Ro5VjJLFqcXFuelGhnq56bkleqlFmcnFxfl5esWpmxiBkXxwy2+NHYzd1+wPMUpzsCiJ81bN 7AwSEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLj4P/NN3oMLU43+NU9MOa95xi/KqnTVp82q 5j2Zs1u2S+lPujd7b03+KnudWzO4BI5qbMwUfb4nkqGUbaJ/SvH+K5pTr2poaVY+flzTFMdt d8RfmGnni+fCR5XErM4vfj7j7/n/zUvfhEX7Xr3nOqH22fd9cvMv2r4ql1HdcC51+fQJilOY ZQ2VWIozEg21mIuKEwHgdbENsgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/sqoIjeZxSsXeLzEQ0was5FbPIAg Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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, 09 Apr 2014 06:32:04 -0000 --_000_CF6A767DE5DEgoranselanderericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Behcet Sarikaya > > Is there an example whereby the client would be the constrained node? May= be NFC use case? The client might be a light switch, and the server might be a lamp. You mean light switch would be authorized to access the lamp? Yes --_000_CF6A767DE5DEgoranselanderericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Behcet Sarikaya <sarikaya2012@gmail.com>

> Is there an example whereby the client would be the co= nstrained node? Maybe NFC use case?

The client might be a light switch, and the server might be a lamp.

You mean light switch would be authorized to access the lamp?

Yes


--_000_CF6A767DE5DEgoranselanderericssoncom_-- From nobody Wed Apr 9 00:11: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 6C4671A00B8 for ; Wed, 9 Apr 2014 00:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 r-kFdfzs7mOd for ; Wed, 9 Apr 2014 00:11:44 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan21.extendcp.co.uk [176.32.226.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB6E1A013B for ; Wed, 9 Apr 2014 00:11:40 -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 1WXmfY-0004ht-7j; Wed, 09 Apr 2014 08:11:36 +0100 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 1WXmfX-0006DX-NT; Wed, 09 Apr 2014 08:11:36 +0100 Received: from host86-177-244-230.range86-177.btcentralplus.com ([86.177.244.230] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WXmfU-0001US-RM; Wed, 09 Apr 2014 08:11:33 +0100 Message-ID: <5344F2E5.7010305@gridmerge.com> Date: Wed, 09 Apr 2014 08:12:37 +0100 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: Hannes Tschofenig , sarikaya@ieee.org, =?ISO-8859-1?Q?G=F6ran_Selander?= References: <533CFC50.3090801@gmx.net> <533ED496.8060608@gmx.net> <533FC2DB.1040103@gmx.net> <53445901.6070602@gmx.net> In-Reply-To: <53445901.6070602@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020503010403020909070104" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/CsRNgUj2rC2mEKnEGDmJNesUx24 Cc: Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] Last Call for Comments on ACE Charter Text 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: Wed, 09 Apr 2014 07:11:48 -0000 This is a cryptographically signed message in MIME format. --------------ms020503010403020909070104 Content-Type: multipart/alternative; boundary="------------000808050903020005040407" This is a multi-part message in MIME format. --------------000808050903020005040407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 - the charter should not start to focus on solutions. I think it is=20 good as it is. Robert On 08/04/2014 9:16 PM, Hannes Tschofenig wrote: > Hi Behcet, Hi G=F6ran, Hi Carsten, > > thanks for the feedback. > > I am wondering whether we are stretching the concept of a charter text > here a bit too much. I am saying that because the charter is a teaser > for the reader to continue looking in the rest of the documents. It is > not a replacement for actually reading the specs and it is also not a > tutorial. > > Behcet, have you had a chance to look at the requirements / use case > document that provider further background? > > Ciao > Hannes > > > On 04/08/2014 06:29 PM, Behcet Sarikaya wrote: >> >> >> On Tue, Apr 8, 2014 at 8:07 AM, G=F6ran Selander >> > wro= te: >> >> >> >> On 07/04/14 18:46, "Carsten Bormann" > > wrote: >> >> >On 07 Apr 2014, at 18:36, Behcet Sarikaya > > wrote: >> > >> > >> >> Also I believe the charter should concentrate on authenticatio= n, >> > >> >That is the part for which we have enough protocols already. >> > >> >> currently it talks more about authorization. >> > >> >Which is exactly what it should do; authentication is ancillary = to the >> >objective of authorization. >> >> I think there is one point here that should be clarified in the c= harter. >> The title of this proposed WG is "Authentication and authorisatio= n in >> Constrained Environments=B2 (not "Authorisation in Constrained >> Environments=B2) and for a good reason. Authorisation depends on >> authentication, and we want to allow authentication and authorisa= tion to >> be based on common trust roots (provisioned keys etc.) and common= key >> management: >> >> - Clearly we don=B9t want one procedure for provisioning keys for= >> verifying >> the integrity of authorisation information and a another procedur= e for >> provisioning keys for authentication of each client. >> >> - Also, to bind the authorisation of a client to a particular req= uesting >> client, the resource server must have access to a key representin= g the >> client identified in the authorisation information. >> >> - Moreover keys for authorisation needs to be managed, renewed at= >> certain >> times, etc. just like keys for authentication. >> >> >> I would like to have a sentence or two in the charter clarifying >> this. How >> about the following: >> >> "A common key management solution for authentication and authoris= ation >> will be provided to optimise key provisioning in constrained devi= ces." >> >> >> >> This sounds good but I am not sure if it applies to the case where the= >> client is not a constrained device? >> >> Regards, >> >> Behcet >> >> >> >> _______________________________________________ >> 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 --------------000808050903020005040407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 - the charter should not start to focus on solutions. I think it is good as it is.

Robert


On 08/04/2014 9:16 PM, Hannes Tschofenig wrote:
Hi Behcet, Hi Göran, Hi Carsten,

thanks for the feedback.

I am wondering whether we are stretching the concept of a charter text
here a bit too much. I am saying that because the charter is a teaser
for the reader to continue looking in the rest of the documents. It is
not a replacement for actually reading the specs and it is also not a
tutorial.

Behcet, have you had a chance to look at the requirements / use case
document that provider further background?

Ciao
Hannes


On 04/08/2014 06:29 PM, Behcet Sarikaya wrote:



On Tue, Apr 8, 2014 at 8:07 AM, Göran Selander
<goran.selander@ericsson.com <mailto:goran.selan=
der@ericsson.com>> wrote:



    On 07/04/14 18:46, "Carsten Bormann" <cabo@tzi.org
    <m=
ailto:cabo@tzi.org>> wrote:

    >On 07 Apr 2014, at 18:36, Behcet Sarikaya <sarikaya2012@gm=
ail.com
    <mailto:sarikaya2012@gmail.com>> wrote:
    >
    >
    >> Also I believe the charter should concentrate on authenticat=
ion,
    >
    >That is the part for which we have enough protocols already.
    >
    >> currently it talks more about authorization.
    >
    >Which is exactly what it should do; authentication is ancillary t=
o the
    >objective of authorization.

    I think there is one point here that should be clarified in the chart=
er.
    The title of this proposed WG is "Authentication and authorisation in=

    Constrained Environments² (not "Authorisation in Constrained
    Environments²) and for a good reason. Authorisation depends on
    authentication, and we want to allow authentication and authorisation=
 to
    be based on common trust roots (provisioned keys etc.) and common key=

    management:

    - Clearly we don¹t want one procedure for provisioning keys for
    verifying
    the integrity of authorisation information and a another procedure fo=
r
    provisioning keys for authentication of each client.

    - Also, to bind the authorisation of a client to a particular request=
ing
    client, the resource server must have access to a key representing th=
e
    client identified in the authorisation information.

    - Moreover keys for authorisation needs to be managed, renewed at
    certain
    times, etc. just like keys for authentication.


    I would like to have a sentence or two in the charter clarifying
    this. How
    about the following:

    "A common key management solution for authentication and authorisatio=
n
    will be provided to optimise key provisioning in constrained devices.=
"



This sounds good but I am not sure if it applies to the case where the
client is not a constrained device?

Regards,

Behcet



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



      

      

      

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


    

    

  


--------------000808050903020005040407--

--------------ms020503010403020909070104
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
Fw0xNDA0MDkwNzEyMzdaMCMGCSqGSIb3DQEJBDEWBBTK/jbq6xUPYTj9HtjuIu49tfZUuTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAHZMFuFV/3pPfZH2FN6FOxuwHSlhKiU8QK8+hgT9YLmyS9Kz
bmqrIOtQ54gipNPFO6BfqIToQAI61Fb3r2KCCgKF7QKT/v9oxwkTaAyZB75YFGT1fLHlTdnC
tSmYRXzO3UbdixhV/SFVU6oc+VbVIPHZn2J3ctScHb57MJOvVRrFY0lOotqMtoFVfUJnAzvJ
bknaDa1ajAWDndy6IKZeDfW5dZXBOdVag4Q6l5EkyogVDQgJ0Rg85XU2sD+7RScIr4QICjQK
rUOFdHgAC7OYsE1w/EgSDex6duN3wROM7UJ91e1WtC7YQSLIyWAutA3VXGqpIm1KdVwq+lLl
PKIVxxoAAAAAAAA=
--------------ms020503010403020909070104--


From nobody Wed Apr  9 02:37: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 BD4A91A01D6 for ; Wed,  9 Apr 2014 02:37:57 -0700 (PDT)
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 xGVL4fXa70ES for ; Wed,  9 Apr 2014 02:37:53 -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 4C6C11A07E2 for ; Wed,  9 Apr 2014 02:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1397036268; l=7752; 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=EtIBjL5QppXmxqBabPRyh+ll2Cw=; b=BdLJFdeZM84dwguTHxxO6f44c0gW5VYp7pyDreIb/diu6sUNo7Q6KzTtlzZxvgUsUrI GFbhtRaAfIe/+ckQzzucvFCnSHeYwarkndZNq8XNqnzgZUiUUU6e6TQByliUcJffmSrKs Iuj4uPtfcu+nnR6F948blvfWuqgOUOqUgTE=
X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSE4QdnNM=
X-RZG-CLASS-ID: mo00
Received: from mail-qa0-f51.google.com ([209.85.216.51]) by smtp.strato.de (RZmta 32.32 AUTH) with ESMTPSA id g014bbq399bjDRF (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, 9 Apr 2014 11:37:45 +0200 (CEST)
Received: by mail-qa0-f51.google.com with SMTP id j7so2150836qaq.24 for ; Wed, 09 Apr 2014 02:37:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.40.229 with SMTP id x92mr10338246qgx.13.1397036264375; Wed, 09 Apr 2014 02:37:44 -0700 (PDT)
Received: by 10.224.32.7 with HTTP; Wed, 9 Apr 2014 02:37:44 -0700 (PDT)
In-Reply-To: 
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>   
Date: Wed, 9 Apr 2014 11:37:44 +0200
Message-ID: 
From: Sandeep Kumar 
To: =?ISO-8859-1?Q?G=F6ran_Selander?= 
Content-Type: multipart/alternative; boundary=001a11c12b6e47012304f698da58
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/bKXP8eFPCEosiB6Wz2wnXKKG4LI
Cc: Carsten Bormann , Hannes Tschofenig , "sarikaya@ieee.org" , "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 09 Apr 2014 09:37:57 -0000

--001a11c12b6e47012304f698da58
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1.
I also second G=F6ran on including a single provisioning method for the
operational keys for both authentication and authorization. The final ACE
solution should be able to sketch how the key management can be performed.

regards
Sandeep


On Tue, Apr 8, 2014 at 3:07 PM, G=F6ran Selander
wrote:

>
>
> On 07/04/14 18:46, "Carsten Bormann"  wrote:
>
> >On 07 Apr 2014, at 18:36, Behcet Sarikaya  wrote=
:
> >
> >
> >> Also I believe the charter should concentrate on authentication,
> >
> >That is the part for which we have enough protocols already.
> >
> >> currently it talks more about authorization.
> >
> >Which is exactly what it should do; authentication is ancillary to the
> >objective of authorization.
>
> I think there is one point here that should be clarified in the charter.
> The title of this proposed WG is "Authentication and authorisation in
> Constrained Environments=B2 (not "Authorisation in Constrained
> Environments=B2) and for a good reason. Authorisation depends on
> authentication, and we want to allow authentication and authorisation to
> be based on common trust roots (provisioned keys etc.) and common key
> management:
>
> - Clearly we don=B9t want one procedure for provisioning keys for verifyi=
ng
> the integrity of authorisation information and a another procedure for
> provisioning keys for authentication of each client.
>
> - Also, to bind the authorisation of a client to a particular requesting
> client, the resource server must have access to a key representing the
> client identified in the authorisation information.
>
> - Moreover keys for authorisation needs to be managed, renewed at certain
> times, etc. just like keys for authentication.
>
>
> I would like to have a sentence or two in the charter clarifying this. Ho=
w
> about the following:
>
> "A common key management solution for authentication and authorisation
> will be provided to optimise key provisioning in constrained devices."
>
>
>
> Put in context below:
>
> Existing authentication and authorization protocols will be used and
> re-applied for use in constrained environments where applicable. _A commo=
n
> key management solution for authentication and authorisation will be
> provided to optimise key provisioning in constrained devices._
> This requires relevant specifications to be reviewed for suitability,
> selecting a subset of them and restricting the options within each of
> the specifications. Some functionality, however, may not be available in
>  existing protocols and thus new standardization efforts will be
> required. Leveraging existing work means the working 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 constrained
> devices that provide increased security.
>
>
>
>
> G=F6ran
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>

--001a11c12b6e47012304f698da58
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1. 
I also second G=F6ran on inc=
luding a single provisioning method for the operational keys for both authe=
ntication and authorization. The final ACE solution should be able to sketc=
h how the key management can be performed.


regards
Sandeep=A0 


On Tue, Apr 8, =
2014 at 3:07 PM, G=F6ran Selander <goran.selander@ericsson.com> wrote:






On 07/04/14 18:46, "Carsten Bormann" <cabo@tzi.org> wrote:



>On 07 Apr 2014, at 18:36, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

>

>


>> Also I believe the charter should concentrat=
e on authentication,

>

>That is the part for which we have enough protocols already.

>

>> currently it talks more about authorization.

>

>Which is exactly what it should do; authentication is ancillary to the<=
br>
>objective of authorization.




I think there is one point here that should be clarified in the chart=
er.

The title of this proposed WG is "Authentication and authorisation in<=
br>
Constrained Environments=B2 (not "Authorisation in Constrained

Environments=B2) and for a good reason. Authorisation depends on

authentication, and we want to allow authentication and authorisation to
be based on common trust roots (provisioned keys etc.) and common key

management:



- Clearly we don=B9t want one procedure for provisioning keys for verifying=


the integrity of authorisation information and a another procedure for

provisioning keys for authentication of each client.



- Also, to bind the authorisation of a client to a particular requesting
client, the resource server must have access to a key representing the

client identified in the authorisation information.



- Moreover keys for authorisation needs to be managed, renewed at certain
times, etc. just like keys for authentication.





I would like to have a sentence or two in the charter clarifying this. How<=
br>
about the following:



"A common key management solution for authentication and authorisation=


will be provided to optimise key provisioning in constrained devices."=








Put in context below:



Existing authentication and authorization protocols will be used and

re-applied for use in constrained environments where applicable. _A common<=
br>
key management solution for authentication and authorisation will be

provided to optimise key provisioning in constrained devices._

This requires relevant specifications to be reviewed for suitability,

selecting a subset of them and restricting the options within each of

the specifications. Some functionality, however, may not be available in
=A0existing protocols and thus new standardization efforts will be

required. Leveraging existing work means the working group benefits from
=A0available security analysis, implementation, and deployment experience.<=
br>

=A0Moreover, a standardized solution for federated authenti=
cation and


authorization will help to stimulate the deployment of constrained
devices that provide increased security.









G=F6ran




_______________________________________________

Ace mailing list

Ace@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/ace





--001a11c12b6e47012304f698da58--


From nobody Wed Apr  9 03: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 363981A01E8 for ; Wed,  9 Apr 2014 03:22: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 WljuIqJYO7Qt for ; Wed,  9 Apr 2014 03:22:53 -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 D9F0C1A01CC for ; Wed,  9 Apr 2014 03:22:52 -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 s39AMfWR027249; Wed, 9 Apr 2014 12:22:41 +0200 (CEST)
Received: from eduroam-pool7-1762.wlan.uni-bremen.de (eduroam-pool7-1762.wlan.uni-bremen.de [134.102.118.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E36AC12BE; Wed,  9 Apr 2014 12:22:40 +0200 (CEST)
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: Wed, 9 Apr 2014 12:22:39 +0200
X-Mao-Original-Outgoing-Id: 418731758.042461-eac3136a8fced5070e5fd456b0f7cd3a
Content-Transfer-Encoding: quoted-printable
Message-Id: <02EEFCF5-08A9-4E4D-9954-EE11381131AD@tzi.org>
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>    
To: Sandeep Kumar 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/iE6rx5H4BaOur1NdgA9CFg9X15o
Cc: Hannes Tschofenig , "sarikaya@ieee.org" , =?windows-1252?Q?G=F6ran_Selander?= , "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 09 Apr 2014 10:22:57 -0000

On 09 Apr 2014, at 11:37, Sandeep Kumar  wrote:

> single provisioning method

I don=92t think viewing authorization as a =93provisioning=94 problem =
yields a complete view of the problem.
(But this is in solution space again...)

Gr=FC=DFe, Carsten


From nobody Wed Apr  9 03:35: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 BCDB71A01CB for ; Wed,  9 Apr 2014 03:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.17
X-Spam-Level: 
X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 dDLTpkDx3VDP for ; Wed,  9 Apr 2014 03:35:11 -0700 (PDT)
Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB751A01D2 for ; Wed,  9 Apr 2014 03:35:10 -0700 (PDT)
Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA for ; ace@ietf.org
Message-ID: <5345225C.1060701@ifi.uzh.ch>
Date: Wed, 09 Apr 2014 12:35:08 +0200
From: Corinna Schmitt 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: ace@ietf.org
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>    
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020103070702090809060004"
X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/bl8N8V0N5o2m0NTdChHfUpIhdAU
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 09 Apr 2014 10:35:16 -0000

This is a multi-part message in MIME format.
--------------020103070702090809060004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I agree Sandeep that we also have to look on how the key management can 
be performed.
Furthermore we have to take care of all authorization facets at the same 
time. Here limitation to "provisioning" method is not constructive.

Regards,
Corinna


Am 09.04.14 11:37, schrieb Sandeep Kumar:
> +1.
> I also second Göran on including a single provisioning method for the 
> operational keys for both authentication and authorization. The final 
> ACE solution should be able to sketch how the key management can be 
> performed.
>
> regards
> Sandeep
>
>
> On Tue, Apr 8, 2014 at 3:07 PM, Göran Selander 
> > wrote:
>
>
>
>     On 07/04/14 18:46, "Carsten Bormann"      > wrote:
>
>     >On 07 Apr 2014, at 18:36, Behcet Sarikaya      > wrote:
>     >
>     >
>     >> Also I believe the charter should concentrate on authentication,
>     >
>     >That is the part for which we have enough protocols already.
>     >
>     >> currently it talks more about authorization.
>     >
>     >Which is exactly what it should do; authentication is ancillary
>     to the
>     >objective of authorization.
>
>     I think there is one point here that should be clarified in the
>     charter.
>     The title of this proposed WG is "Authentication and authorisation in
>     Constrained Environments² (not "Authorisation in Constrained
>     Environments²) and for a good reason. Authorisation depends on
>     authentication, and we want to allow authentication and
>     authorisation to
>     be based on common trust roots (provisioned keys etc.) and common key
>     management:
>
>     - Clearly we don¹t want one procedure for provisioning keys for
>     verifying
>     the integrity of authorisation information and a another procedure for
>     provisioning keys for authentication of each client.
>
>     - Also, to bind the authorisation of a client to a particular
>     requesting
>     client, the resource server must have access to a key representing the
>     client identified in the authorisation information.
>
>     - Moreover keys for authorisation needs to be managed, renewed at
>     certain
>     times, etc. just like keys for authentication.
>
>
>     I would like to have a sentence or two in the charter clarifying
>     this. How
>     about the following:
>
>     "A common key management solution for authentication and authorisation
>     will be provided to optimise key provisioning in constrained devices."
>
>
>
>     Put in context below:
>
>     Existing authentication and authorization protocols will be used and
>     re-applied for use in constrained environments where applicable.
>     _A common
>     key management solution for authentication and authorisation will be
>     provided to optimise key provisioning in constrained devices._
>     This requires relevant specifications to be reviewed for suitability,
>     selecting a subset of them and restricting the options within each of
>     the specifications. Some functionality, however, may not be
>     available in
>      existing protocols and thus new standardization efforts will be
>     required. Leveraging existing work means the working 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 constrained
>     devices that provide increased security.
>
>
>
>
>     Göran
>
>     _______________________________________________
>     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


-- 

--------------020103070702090809060004
Content-Type: multipart/related;
 boundary="------------020706020007080106070909"


--------------020706020007080106070909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I agree Sandeep that we also have to
      look on how the key management can be performed.

      Furthermore we have to take care of all authorization facets at
      the same time. Here limitation to "provisioning" method is not
      constructive.

      

      Regards,

      Corinna

      

      

      Am 09.04.14 11:37, schrieb Sandeep Kumar:

    

    

      

        
+1. 

          I also second Göran on including a single
            provisioning method for the operational keys for both
            authentication and authorization. The final ACE solution
            should be able to sketch how the key management can be
            performed.

            

          

        regards

          Sandeep  

        

      


        

        
On Tue, Apr 8, 2014 at 3:07 PM, Göran
          Selander <goran.selander@ericsson.com>
          wrote:

          

            


              

              On 07/04/14 18:46, "Carsten Bormann" <cabo@tzi.org>
              wrote:

              

              >On 07 Apr 2014, at 18:36, Behcet Sarikaya <sarikaya2012@gmail.com>
              wrote:

              >

              >

            

            
>> Also I believe the charter should
              concentrate on authentication,

              >

              >That is the part for which we have enough protocols
              already.

              >

              >> currently it talks more about authorization.

              >

              >Which is exactly what it should do; authentication is
              ancillary to the

              >objective of authorization.

              

            

            I think there is one point here that should be clarified in
            the charter.

            The title of this proposed WG is "Authentication and
            authorisation in

            Constrained Environments² (not "Authorisation in Constrained

            Environments²) and for a good reason. Authorisation depends
            on

            authentication, and we want to allow authentication and
            authorisation to

            be based on common trust roots (provisioned keys etc.) and
            common key

            management:

            

            - Clearly we don¹t want one procedure for provisioning keys
            for verifying

            the integrity of authorisation information and a another
            procedure for

            provisioning keys for authentication of each client.

            

            - Also, to bind the authorisation of a client to a
            particular requesting

            client, the resource server must have access to a key
            representing the

            client identified in the authorisation information.

            

            - Moreover keys for authorisation needs to be managed,
            renewed at certain

            times, etc. just like keys for authentication.

            

            

            I would like to have a sentence or two in the charter
            clarifying this. How

            about the following:

            

            "A common key management solution for authentication and
            authorisation

            will be provided to optimise key provisioning in constrained
            devices."

            

            

            

            Put in context below:

            

            Existing authentication and authorization protocols will be
            used and

            re-applied for use in constrained environments where
            applicable. _A common

            key management solution for authentication and authorisation
            will be

            provided to optimise key provisioning in constrained
            devices._

            This requires relevant specifications to be reviewed for
            suitability,

            selecting a subset of them and restricting the options
            within each of

            the specifications. Some functionality, however, may not be
            available in

             existing protocols and thus new standardization efforts
            will be

            required. Leveraging existing work means the working 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
            constrained

            devices that provide increased security.

            

                

                

                

                Göran

              
            

              


                _______________________________________________

                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


    

    

    

    
-- 

      

  


--------------020706020007080106070909
Content-Type: image/png; x-mac-type="0"; x-mac-creator="0";
 name="visitenkarte.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="visitenkarte.png"

iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B
AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA
buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I
R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm
5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR
q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9
+/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze
MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP
nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU
M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx
xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l
egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3
ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1
no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d
WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0
qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw
YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8
zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam
SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW
rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi
5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57
du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69
e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ
aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK
5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8
/kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN
m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c
nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q
379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs
3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8
LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr
X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7
jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi
Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb
1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg
48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS
U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37
9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9
nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL
3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk
ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379
XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W
tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF
Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+
8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx
Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE
HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT
Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N
2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z
ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl
5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61//
OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq
PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP
PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154
ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9
e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL
B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo
j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx
9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz
iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN
/PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2
baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On
Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl
ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX
qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d
u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy
NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v
Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj
8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc
861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73
se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn
7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+
0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf//
9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7
7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778
mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z
bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy
5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+
1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c
udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv
mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF
vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/
S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/
+x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19
/n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8
rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0
+R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP
HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c
HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH
X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx
x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3
LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK
pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr
FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF
xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr
165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t
mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40
GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP
Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz
DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP
VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO
aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/
cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q
ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv
bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF
ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw
/kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e
vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv
f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s
dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr
1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk
kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1
RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun
L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv
brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq
jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT
4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky
YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh
2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u
S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw
Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV
KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ
aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq
e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh
Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF
QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG
f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM
Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO
RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb
6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z
GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o
sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL
hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora
x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv
qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep
alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z
N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf
tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq
Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD
z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r
Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ
wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4
W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR
nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN
Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk
rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM
1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA
ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi
q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ
P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX
fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u
3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5
oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH
OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga
61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a
AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo
115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH
AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ
alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap
fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV
ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN
zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS
zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx
/vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF
HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior
BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5
ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP
OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h
RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG
mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3
3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m
ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc
SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM
DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ
woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb
yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo
RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH
DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D
l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX
cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc
lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb
XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm
jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk
ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV
s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC
DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN
hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ
4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM
WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh
XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L
qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy
87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD
m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a
XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU
JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD
Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy
d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR
9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn
1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197
zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr
HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf
Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs
KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg
lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw
7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv
rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg
9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1
y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77
8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN
mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y
5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX
trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk
QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2
SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq
aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU
gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1
a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb
IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno
sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk
yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL
FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2
6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki
ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP
jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd
Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd
huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek
OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5
eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh
yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5
i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ
QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ
qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp
nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy
qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX
F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W
m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP
uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac
ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55
htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu
OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z
S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy
XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir
nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx
O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH
M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx
413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR
o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm
ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN
0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol
K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW
l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf
RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P
r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe
dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc
VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg
wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9
Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR
EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ
HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H
dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V
ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT
Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8
RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl
SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy
K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2
7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV
MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz
ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b
t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl
ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw
wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8
Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN
FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI
wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg
IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3
atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r
CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d
ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj
acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn
ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE
7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf
17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe
SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw
VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec
jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA
GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F
7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs
tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk
dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO
xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at
7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M
cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+
JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX
Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4
EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs
YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw
rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL
Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA
RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8
PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L
9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH
Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9
AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF
AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2
jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj
oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa
4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW
/iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP
gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB
OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA
SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ
/Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e
zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp
UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb
zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S
uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq
wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+
KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC
J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq
dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz
lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0
5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl
pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9
Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq
zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo
9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f
Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm
IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl
IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1
eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo
JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip
QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7
jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP
HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln
ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz
FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz
5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H
B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY
foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu
wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX
EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ
evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU
0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI
SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1
53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb
K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY
1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq
z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3
vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS
TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi
I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh
rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi
JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT
jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc
JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH
xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA
H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D
vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm
CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK
oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb
SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv
mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5
40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz
XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF
IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF
n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k
ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn
B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep
h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC
vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9
JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um
7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU
tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk
1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y
ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4
bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK
FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc
sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU
4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW
NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf
/6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex
ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx
mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3
hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER
Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl
EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI
kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+
bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi
xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI
nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R
PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx
Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM
eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS
W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd
xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT
sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY
U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS
pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4
wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz
nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5
tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR
r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs
QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061
BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ
dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB
+EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb
tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X
Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT
oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd
J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV
r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK
bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg
RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC
jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz
ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn
egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc
JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO
OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq
la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder
oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx
RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw
/jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB
4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO
Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL
FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX
TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA
DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x
Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly
5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM
Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw
uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV
uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n
PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+
Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4
qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I
/qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr
dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG
lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR
O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B
diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO
0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw
W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM
eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC
LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS
ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k
m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh
vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1
68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG
kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8
pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn
+RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18
0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd
/sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM
bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV
pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e
TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo
8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl
ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1
bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT
GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY
UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3
ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8
Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ
FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk
gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp
U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM
B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt
K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ
A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX
MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY
Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn
nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME
vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI
viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D
lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS
73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY
voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW
GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX
N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU
IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2
mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv
3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR
52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB
GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D
o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp
VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ
1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz
4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV
2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX
tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ
nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e
Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu
rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2
NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz
nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp
m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg
n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R
h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54
NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi
qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk
DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o
DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna
k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k
/JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc
ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT
UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR
4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0
WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ
AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY
TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp
pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW
nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB
xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL
c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i
5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1
dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi
PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL
IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y
q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6
YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3
S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl
eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj
FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa
+n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p
9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2
pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA
Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR
L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO
RK5CYII=
--------------020706020007080106070909--

--------------020103070702090809060004--


From nobody Wed Apr  9 09:18: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 14BFE1A0380 for ; Wed,  9 Apr 2014 09:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.878
X-Spam-Level: 
X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272] 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 T8GukBlZsDxv for ; Wed,  9 Apr 2014 09:18:07 -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 3618C1A032E for ; Wed,  9 Apr 2014 09:18:07 -0700 (PDT)
Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s39GF6Sq015783 for ; Wed, 9 Apr 2014 18:18:05 +0200
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jr6aajr7y-1 for ; Wed, 09 Apr 2014 18:18:05 +0200
Received: from [10.240.32.231] (unknown [213.179.18.114]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id BEA3E40116 for ; Wed,  9 Apr 2014 18:18:05 +0200 (CEST)
Message-ID: <534572BD.9070308@sics.se>
Date: Wed, 09 Apr 2014 18:18:05 +0200
From: Ludwig Seitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: ace@ietf.org
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>     <5345225C.1060701@ifi.uzh.ch>
In-Reply-To: <5345225C.1060701@ifi.uzh.ch>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080505010904080703030002"
X-Proofpoint-Spam-Reason: safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-04-09_03:2014-04-09,2014-04-09,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/XcPc3wdIhunWYKguNx4yMrtW-P4
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 09 Apr 2014 16:18:12 -0000

This is a cryptographically signed message in MIME format.

--------------ms080505010904080703030002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/09/2014 12:35 PM, Corinna Schmitt wrote:
> I agree Sandeep that we also have to look on how the key management can=

> be performed.
> Furthermore we have to take care of all authorization facets at the sam=
e
> time. Here limitation to "provisioning" method is not constructive.
>
> Regards,
> Corinna
>

I think there is some misunderstanding here about what G=F6ran means. The=
=20
idea is not to limit our work to provisioning, but provisioning will=20
need to be a part of a solution, and then we want to make sure the=20
provisioning methods we use for authentication can be reused for=20
authorization.

/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


--------------ms080505010904080703030002
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
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MDkxNjE4MDVaMCMGCSqGSIb3DQEJBDEW
BBQSoYla/pGkZfxptZjXi8zvkVtQJjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE
ggEAGh7f8a+Yf91KX758ivdHEZLETNHEhrHqmp+dM+MmBS4Y3H9btRx5jocNHAj0+jFX8B+e
9guEcrxBcesaoJ5EUZug+BswncUcNe/MMfif02yq/57jRHTglFUZ4UeWGqwEp38ijHzlUK1w
oCfoFaWyBDmWWbwMnOsH2uWW2cC9lIIie15U6sDJXdSIFssNsVjV0cCCltFv2M6M5Txf2d5O
H+DC98CTqVcX5BpqhSSKl/NwaEP/GEbHhDodTpy44xY9L6Vn1Oa2oCNPl8fT9pCza+IbdPSk
o7FEFbN19J/eo/9JJmtqyvVCCs3oKFZDC+4JnlwfE78gx2CZloN5ppcjIQAAAAAAAA==
--------------ms080505010904080703030002--


From nobody Wed Apr  9 11:18: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 C5F7F1A0409 for ; Wed,  9 Apr 2014 11:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.527
X-Spam-Level: 
X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, 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 MVTdazG-SnZo for ; Wed,  9 Apr 2014 11:18:43 -0700 (PDT)
Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA8E1A03C4 for ; Wed,  9 Apr 2014 11:18:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id B719BC51B; Wed,  9 Apr 2014 20:18:41 +0200 (CEST)
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 n1d5jAhZNp3o; Wed,  9 Apr 2014 20:18:41 +0200 (CEST)
Received: from inf-205-85.inf.um.es (inf-205-85.inf.um.es [155.54.205.85]) (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 4E503C51A; Wed,  9 Apr 2014 20:18:40 +0200 (CEST)
From: Rafa Marin Lopez 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 9 Apr 2014 20:18:38 +0200
Message-Id: <348D480C-316F-4B8B-954E-78573247955E@um.es>
To: ace@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Nqf6nP1xFbdifqY3hIVcgaT_7Ow
Cc: Rafa Marin Lopez 
Subject: [Ace] Integrating AAA and CoAP
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, 09 Apr 2014 18:18:47 -0000

Dear all

As promised, we have written the following (and modest) I-D to explain =
our ongoing work about an EAP-based authentication service for CoAP that =
involves an AAA infrastructure.=20

http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-00

Hope this helps somehow to ACE.

Best Regards.

-------------------------------------------------------
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 Wed Apr  9 11:58: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 391E71A0436 for ; Wed,  9 Apr 2014 11:58:10 -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 c-cs-nx4XcsQ for ; Wed,  9 Apr 2014 11:58:06 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 105C21A0273 for ; Wed,  9 Apr 2014 11:58:05 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id e16so1502607lan.16 for ; Wed, 09 Apr 2014 11:58:04 -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=o0gdcwHrKxnKFAPJ/ietKChA1MCTmPEOKXpUUqtc0ms=; b=C8X4giaCxvagLgGP/dHUT/AvX7QjovwBtrBrC6gbbmmKpcOrRrMRG2ThIcCBt8swrw dlzWL4YsQpWL6n1oHRP9kpE5Y9wJ9FgnkZCMSbkbZ+x3DOxGB+/5OMOEqV8VZtY9hQh8 XCpWA1a+LGbMSxxGmU/96onVK5X7eXxnmIzzglC2z1+ItYJv0xK6aQJP4SUO5qrhErty 5H+tTG2ZdMtz19EvyULa/SvYo+WU++GLHIArfeF1TpuPLruKqHCtkycOv6RV/ZTbguxE WCjLTIMEcZk/cT0+CQk427cSRapqoCYt3eyh82mGbzG9l6Q2BldeHf+F1bu3w7xyLCJg 9wnA==
MIME-Version: 1.0
X-Received: by 10.112.143.99 with SMTP id sd3mr8141043lbb.11.1397069884847; Wed, 09 Apr 2014 11:58:04 -0700 (PDT)
Received: by 10.114.70.165 with HTTP; Wed, 9 Apr 2014 11:58:04 -0700 (PDT)
In-Reply-To: <348D480C-316F-4B8B-954E-78573247955E@um.es>
References: <348D480C-316F-4B8B-954E-78573247955E@um.es>
Date: Wed, 9 Apr 2014 13:58:04 -0500
Message-ID: 
From: Behcet Sarikaya 
To: Rafa Marin Lopez 
Content-Type: multipart/alternative; boundary=089e01160478367aa604f6a0aefb
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/hKPsObCzzM20BKhpILova_I7lb8
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Integrating AAA and CoAP
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: Wed, 09 Apr 2014 18:58:10 -0000

--089e01160478367aa604f6a0aefb
Content-Type: text/plain; charset=ISO-8859-1

Hi Rafa,

I was reading your draft. I think using COAP as EAP transport is an
interesting idea.

However, I could not see anywhere in your document what is the problem you
are trying to solve.

Hopefully you can related the problem with the problem ace is trying to
solve.

Regards,

Behcet


On Wed, Apr 9, 2014 at 1:18 PM, Rafa Marin Lopez  wrote:

> Dear all
>
> As promised, we have written the following (and modest) I-D to explain our
> ongoing work about an EAP-based authentication service for CoAP that
> involves an AAA infrastructure.
>
> http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-00
>
> Hope this helps somehow to ACE.
>
> Best Regards.
>
> -------------------------------------------------------
> 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
>

--089e01160478367aa604f6a0aefb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Rafa,

I was readi=
ng your draft. I think using COAP as EAP transport is an interesting idea.<=
br>
However, I could not see anywhere in your document what is the=
 problem you are trying to solve.


Hopefully you can related the problem with the problem ace is try=
ing to solve.

Regards,

Behcet 
=



On =
Wed, Apr 9, 2014 at 1:18 PM, Rafa Marin Lopez <rafa@um.es> wrote:

Dear all



As promised, we have written the following (and modest) I-D to explain our =
ongoing work about an EAP-based authentication service for CoAP that involv=
es an AAA infrastructure.



http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-00<=
br>


Hope this helps somehow to ACE.



Best Regards.



-------------------------------------------------------

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





--089e01160478367aa604f6a0aefb--


From nobody Wed Apr  9 22:51: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 C9A661A0100 for ; Wed,  9 Apr 2014 22:51:10 -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 eXPI9VMFedFG for ; Wed,  9 Apr 2014 22:51:09 -0700 (PDT)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 628AA1A00D1 for ; Wed,  9 Apr 2014 22:51:08 -0700 (PDT)
X-AuditID: c1b4fb32-b7fe98e0000034f3-7b-5346314bc7e9
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 3C.B6.13555.B4136435; Thu, 10 Apr 2014 07:51:07 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Thu, 10 Apr 2014 07:51:06 +0200
From: =?iso-8859-1?Q?G=F6ran_Selander?= 
To: Ludwig Seitz , "ace@ietf.org" 
Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text
Thread-Index: AQHPTwesnxCOmPukp0qz1DHybcYoEJsBfdCA///9lgCAAIfKgIAAlECAgAOn6oCAAALXgIABh5iAgAElWACAABAJAIAAX9KAgAEEq4A=
Date: Thu, 10 Apr 2014 05:51:05 +0000
Message-ID: 
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>     <5345225C.1060701@ifi.uzh.ch> <534572BD.9070308@sics.se>
In-Reply-To: <534572BD.9070308@sics.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
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+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja63oVuwwawuZYvv33qYLV613mF2 YPJYsuQnk0fvsd9sAUxRXDYpqTmZZalF+nYJXBk3v+1lLVjMW/H/t0ID4zWuLkZODgkBE4mV J08yQ9hiEhfurWfrYuTiEBI4ySjxbfJ3VpCEkMBiRon1r/lBbDYBV4kDD94xgdgiAg4S7xae AbOFBWwlFsx7wAYRt5P48PMLO4RdJtH1FWIBi4CqxOR/d8HqeQXMJV69W8QIsWwai8TVq7OB mjk4OAXUJba3FoDUMAId9P3UGrB6ZgFxiVtP5jNBHCogsWTPeaijRSVePv4HdqeogJ7Eu+Mw NUoSi25/hurVk7gxdQobhG0tsbvrMSuErS2xbOFrZoh7BCVOznzCMoFRfBaSdbOQtM9C0j4L SfssJO0LGFlXMUoWpxYX56YbGejlpueW6KUWZSYXF+fn6RWnbmIERt3BLb+NdjCe3GN/iFGa g0VJnPc6a02QkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYZ717eaPHJe2cps0o87/KGmX6r 4i7MPHrMTeHP7DWhstuttzKxbzzA2nxNiNWn4rOJ/0b5ac8ef/siGrLEY3Vk1RyedQ/zFetv /Ojdk9ejXukco1t3MSGs4OXX4tW5Ly7FHyqUZM7wunRbuGpr4dXaplXmEXu3+pzzrMmREWG5 IymkOW++Xp8SS3FGoqEWc1FxIgDCKf9/iAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/F7qg1BSjp2TP7e3sZ5_5dP_SdCM
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 10 Apr 2014 05:51:10 -0000

On 09/04/14 18:18, "Ludwig Seitz"  wrote:

>On 04/09/2014 12:35 PM, Corinna Schmitt wrote:
>> I agree Sandeep that we also have to look on how the key management can
>> be performed.
>> Furthermore we have to take care of all authorization facets at the same
>> time. Here limitation to "provisioning" method is not constructive.
>>
>> Regards,
>> Corinna
>>
>
>I think there is some misunderstanding here about what G=F6ran means. The
>idea is not to limit our work to provisioning, but provisioning will
>need to be a part of a solution, and then we want to make sure the
>provisioning methods we use for authentication can be reused for
>authorization.

Something like that, let me try again:

In some (probably many) use cases, when a device leaves the factory it
does not know who will be its owner, authorisation server, authorised
clients (if it is a resource server) etc.

In some of those cases, there is a provisioning procedure after
manufacture whereby keys are established in the device.

In some of those cases, the device is intended to be fully operational
thereafter, in particular that a device can authenticate and authorise
requests with keys derived through a common key management scheme using
the established keys, without any further provisioning.

My hope is that a solution produced in ACE will support this setting as an
option, and that such a key management scheme is specified. IMHO this is
not removing any desirable solutions from the solution space. Simplifying
the proposed text even further:

"A common key management solution for authentication and authorisation
will be specified."




G=F6ran





From nobody Wed Apr  9 23:25: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 EFF991A0102 for ; Wed,  9 Apr 2014 23:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.624
X-Spam-Level: 
X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, UNPARSEABLE_RELAY=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 IhUnBS-aTMBq for ; Wed,  9 Apr 2014 23:25:22 -0700 (PDT)
Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id 945A61A00EF for ; Wed,  9 Apr 2014 23:25:21 -0700 (PDT)
Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA for <065957FC8C>; ace@ietf.org
Message-ID: <5346394B.9060500@ifi.uzh.ch>
Date: Thu, 10 Apr 2014 08:25:15 +0200
From: Corinna Schmitt 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: ace@ietf.org
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>     <5345225C.1060701@ifi.uzh.ch> <534572BD.9070308@sics.se>
In-Reply-To: <534572BD.9070308@sics.se>
Content-Type: multipart/alternative; boundary="------------050204090808070008040108"
X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/wMkD6AAgwgbAOfWJH4kUFUQ0d_E
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 10 Apr 2014 06:25:26 -0000

This is a multi-part message in MIME format.
--------------050204090808070008040108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Ludwig for clarification.
That makes more sense to me and fits to our draft idea.

Regards,
Corinna

Am 09.04.14 18:18, schrieb Ludwig Seitz:
> On 04/09/2014 12:35 PM, Corinna Schmitt wrote:
>> I agree Sandeep that we also have to look on how the key management can
>> be performed.
>> Furthermore we have to take care of all authorization facets at the same
>> time. Here limitation to "provisioning" method is not constructive.
>>
>> Regards,
>> Corinna
>>
>
> I think there is some misunderstanding here about what Göran means. 
> The idea is not to limit our work to provisioning, but provisioning 
> will need to be a part of a solution, and then we want to make sure 
> the provisioning methods we use for authentication can be reused for 
> authorization.
>
> /Ludwig
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace


-- 

--------------050204090808070008040108
Content-Type: multipart/related;
 boundary="------------040003010400010804080402"


--------------040003010400010804080402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Thanks Ludwig for clarification.

      That makes more sense to me and fits to our draft idea.

      

      Regards,

      Corinna

      

      Am 09.04.14 18:18, schrieb Ludwig Seitz:

    

    
On
      04/09/2014 12:35 PM, Corinna Schmitt wrote:
      

      
I agree Sandeep that we also have to look
        on how the key management can
        

        be performed.
        

        Furthermore we have to take care of all authorization facets at
        the same
        

        time. Here limitation to "provisioning" method is not
        constructive.
        

        

        Regards,
        

        Corinna
        

        

      

      

      I think there is some misunderstanding here about what Göran
      means. The idea is not to limit our work to provisioning, but
      provisioning will need to be a part of a solution, and then we
      want to make sure the provisioning methods we use for
      authentication can be reused for authorization.
      

      

      /Ludwig
      

      

      

      

      

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


    

    

    

    
-- 

      

  


--------------040003010400010804080402
Content-Type: image/png; x-mac-type="0"; x-mac-creator="0";
 name="visitenkarte.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="visitenkarte.png"

iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B
AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA
buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I
R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm
5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR
q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9
+/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze
MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP
nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU
M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx
xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l
egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3
ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1
no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d
WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0
qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw
YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8
zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam
SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW
rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi
5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57
du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69
e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ
aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK
5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8
/kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN
m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c
nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q
379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs
3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8
LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr
X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7
jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi
Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb
1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg
48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS
U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37
9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9
nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL
3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk
ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379
XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W
tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF
Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+
8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx
Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE
HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT
Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N
2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z
ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl
5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61//
OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq
PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP
PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154
ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9
e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL
B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo
j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx
9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz
iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN
/PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2
baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On
Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl
ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX
qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d
u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy
NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v
Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj
8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc
861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73
se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn
7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+
0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf//
9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7
7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778
mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z
bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy
5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+
1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c
udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv
mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF
vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/
S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/
+x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19
/n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8
rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0
+R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP
HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c
HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH
X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx
x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3
LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK
pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr
FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF
xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr
165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t
mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40
GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP
Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz
DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP
VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO
aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/
cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q
ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv
bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF
ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw
/kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e
vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv
f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s
dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr
1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk
kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1
RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun
L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv
brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq
jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT
4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky
YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh
2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u
S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw
Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV
KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ
aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq
e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh
Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF
QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG
f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM
Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO
RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb
6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z
GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o
sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL
hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora
x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv
qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep
alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z
N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf
tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq
Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD
z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r
Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ
wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4
W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR
nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN
Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk
rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM
1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA
ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi
q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ
P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX
fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u
3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5
oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH
OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga
61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a
AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo
115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH
AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ
alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap
fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV
ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN
zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS
zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx
/vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF
HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior
BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5
ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP
OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h
RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG
mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3
3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m
ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc
SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM
DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ
woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb
yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo
RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH
DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D
l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX
cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc
lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb
XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm
jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk
ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV
s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC
DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN
hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ
4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM
WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh
XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L
qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy
87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD
m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a
XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU
JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD
Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy
d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR
9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn
1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197
zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr
HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf
Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs
KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg
lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw
7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv
rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg
9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1
y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77
8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN
mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y
5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX
trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk
QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2
SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq
aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU
gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1
a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb
IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno
sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk
yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL
FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2
6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki
ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP
jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd
Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd
huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek
OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5
eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh
yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5
i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ
QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ
qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp
nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy
qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX
F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W
m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP
uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac
ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55
htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu
OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z
S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy
XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir
nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx
O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH
M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx
413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR
o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm
ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN
0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol
K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW
l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf
RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P
r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe
dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc
VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg
wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9
Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR
EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ
HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H
dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V
ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT
Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8
RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl
SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy
K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2
7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV
MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz
ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b
t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl
ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw
wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8
Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN
FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI
wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg
IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3
atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r
CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d
ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj
acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn
ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE
7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf
17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe
SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw
VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec
jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA
GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F
7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs
tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk
dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO
xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at
7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M
cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+
JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX
Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4
EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs
YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw
rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL
Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA
RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8
PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L
9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH
Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9
AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF
AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2
jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj
oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa
4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW
/iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP
gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB
OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA
SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ
/Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e
zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp
UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb
zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S
uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq
wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+
KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC
J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq
dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz
lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0
5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl
pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9
Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq
zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo
9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f
Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm
IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl
IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1
eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo
JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip
QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7
jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP
HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln
ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz
FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz
5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H
B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY
foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu
wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX
EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ
evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU
0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI
SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1
53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb
K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY
1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq
z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3
vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS
TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi
I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh
rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi
JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT
jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc
JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH
xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA
H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D
vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm
CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK
oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb
SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv
mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5
40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz
XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF
IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF
n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k
ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn
B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep
h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC
vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9
JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um
7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU
tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk
1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y
ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4
bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK
FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc
sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU
4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW
NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf
/6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex
ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx
mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3
hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER
Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl
EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI
kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+
bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi
xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI
nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R
PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx
Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM
eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS
W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd
xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT
sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY
U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS
pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4
wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz
nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5
tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR
r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs
QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061
BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ
dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB
+EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb
tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X
Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT
oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd
J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV
r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK
bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg
RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC
jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz
ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn
egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc
JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO
OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq
la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder
oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx
RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw
/jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB
4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO
Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL
FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX
TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA
DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x
Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly
5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM
Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw
uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV
uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n
PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+
Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4
qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I
/qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr
dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG
lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR
O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B
diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO
0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw
W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM
eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC
LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS
ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k
m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh
vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1
68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG
kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8
pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn
+RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18
0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd
/sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM
bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV
pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e
TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo
8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl
ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1
bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT
GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY
UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3
ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8
Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ
FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk
gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp
U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM
B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt
K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ
A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX
MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY
Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn
nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME
vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI
viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D
lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS
73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY
voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW
GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX
N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU
IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2
mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv
3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR
52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB
GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D
o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp
VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ
1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz
4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV
2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX
tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ
nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e
Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu
rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2
NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz
nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp
m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg
n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R
h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54
NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi
qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk
DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o
DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna
k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k
/JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc
ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT
UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR
4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0
WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ
AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY
TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp
pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW
nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB
xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL
c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i
5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1
dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi
PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL
IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y
q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6
YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3
S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl
eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj
FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa
+n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p
9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2
pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA
Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR
L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO
RK5CYII=
--------------040003010400010804080402--

--------------050204090808070008040108--


From nobody Wed Apr  9 23:27:29 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 4BB151A027F for ; Wed,  9 Apr 2014 23:27:28 -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 pOK-eDqO-Uqq for ; Wed,  9 Apr 2014 23:27:27 -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 E10081A0115 for ; Wed,  9 Apr 2014 23:27:26 -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 s3A6RGs2013509; Thu, 10 Apr 2014 08:27:16 +0200 (CEST)
Received: from [192.168.217.105] (p54892687.dip0.t-ipconnect.de [84.137.38.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E6C8D1677; Thu, 10 Apr 2014 08:27:15 +0200 (CEST)
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: Thu, 10 Apr 2014 08:27:13 +0200
X-Mao-Original-Outgoing-Id: 418804033.615682-5163ebf8664a5a668172cd01d7a27070
Content-Transfer-Encoding: quoted-printable
Message-Id: <65E351B5-B34D-48E5-9C09-7DE13FF50600@tzi.org>
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>     <5345225C.1060701@ifi.uzh.ch> <534572BD.9070308@sics.se> 
To: =?windows-1252?Q?G=F6ran_Selander?= 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/c0zNeSL_uoq87EfnjtBnhJfHTyw
Cc: Ludwig Seitz , "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 10 Apr 2014 06:27:28 -0000

On 10 Apr 2014, at 07:51, G=F6ran Selander  =
wrote:

> In some of those cases, the device is intended to be fully operational
> thereafter, in particular that a device can authenticate and authorise
> requests with keys derived through a common key management scheme =
using
> the established keys, without any further provisioning.

Yes, but the end of =93provisioning" doesn=92t mean there is no further =
communication about establishing authenticated authorization.

> "A common key management solution for authentication and authorisation
> will be specified."

I=92m afraid that sentence says something different, approximately =93all =
of authentication and authorization will be based on a common =91key =
management=92=94.  (I don=92t know what =91key management=92 is, but =
this sentence also invites all the worst interpretations.)

Gr=FC=DFe, Carsten


From nobody Thu Apr 10 00:03: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 0C7441A0457 for ; Thu, 10 Apr 2014 00:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.1
X-Spam-Level: *
X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  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 YlpHJyryZbYg for ; Thu, 10 Apr 2014 00:03:09 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan14.extendcp.co.uk [79.170.45.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61F1A0461 for ; Thu, 10 Apr 2014 00:03:08 -0700 (PDT)
Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WY90r-0003jg-6T; Thu, 10 Apr 2014 08:03:05 +0100
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 1WY90p-0002Dd-Lz; Thu, 10 Apr 2014 08:03:05 +0100
Received: from host86-177-244-230.range86-177.btcentralplus.com ([86.177.244.230] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WY90m-0006xP-6l; Thu, 10 Apr 2014 08:03:00 +0100
Message-ID: <53464263.1000607@gridmerge.com>
Date: Thu, 10 Apr 2014 08:04:03 +0100
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: Carsten Bormann , =?windows-1252?Q?G=F6ran_Selander?= 
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>     <5345225C.1060701@ifi.uzh.ch> <534572BD.9070308@sics.se>  <65E351B5-B34D-48E5-9C09-7DE13FF50600@tzi.org>
In-Reply-To: <65E351B5-B34D-48E5-9C09-7DE13FF50600@tzi.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000803010508000809020100"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/6O5GznXJj4UGMZNP_Bof2gxddUM
Cc: Ludwig Seitz , "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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: Thu, 10 Apr 2014 07:03:16 -0000

This is a cryptographically signed message in MIME format.

--------------ms000803010508000809020100
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

I completely agree with Carsten. What is a "key management solution"? I=20
would rather not see the word "key" used in the charter (and I don't=20
count "digital key" as that is a generalisation in the context of a door =

lock) or any language which attempts to constrain the possible=20
solutions. All the charter should do is set the context and identify the =

tasks and products, which is does.

Robert

On 10/04/2014 7:27 AM, Carsten Bormann wrote:
> On 10 Apr 2014, at 07:51, G=F6ran Selander  wrote:
>
>> In some of those cases, the device is intended to be fully operational=

>> thereafter, in particular that a device can authenticate and authorise=

>> requests with keys derived through a common key management scheme usin=
g
>> the established keys, without any further provisioning.
> Yes, but the end of =93provisioning" doesn=92t mean there is no further=
 communication about establishing authenticated authorization.
>
>> "A common key management solution for authentication and authorisation=

>> will be specified."
> I=92m afraid that sentence says something different, approximately =93a=
ll of authentication and authorization will be based on a common =91key m=
anagement=92=94.  (I don=92t know what =91key management=92 is, but this =
sentence also invites all the worst interpretations.)
>
> Gr=FC=DFe, Carsten
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>



--------------ms000803010508000809020100
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
Fw0xNDA0MTAwNzA0MDNaMCMGCSqGSIb3DQEJBDEWBBRFoslqHMZPCrHqCnkS2+HucY4B6TBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAC/2kxfJ9bUI+t0Pfo3hDRvQXTsHQ0GLVW6Mv91v86i7EZBN
5glKPt4TsH8OQ4CM3VT2HeG522WCxe++x6GKEm8+zHeKJgsJ6fg49xNev5yWSDexZ9FAzuQk
JacSfaf9x40vKNS3XCdy6aD4+hz9o08aPo6W8oYK0z4F9ufzguYGTSWmEn7rNrYFN3P7zcim
pS5CCUnSxQinnUJ6CKFl4ZP5sgAUg+xcJjfE8Tw7IZmw1pl7pqUuaYJ6gFoMyOvFoc77FGc0
WTfUyCZMuLFRomsr2vyPdJDFc7sVxEq2jxrJxd/UcfTvD5mpcxmyuP1g7DBGReYlEPO6zy37
TGrUdWUAAAAAAAA=
--------------ms000803010508000809020100--


From nobody Thu Apr 10 05:10: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 CCD3D1A021D for ; Thu, 10 Apr 2014 05:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.472
X-Spam-Level: 
X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 N5ylAD8vzoNb for ; Thu, 10 Apr 2014 05:10:36 -0700 (PDT)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3263F1A01CB for ; Thu, 10 Apr 2014 05:10:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 4D7BDCD8B; Thu, 10 Apr 2014 14:10:32 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KlwE5QvspfKE; Thu, 10 Apr 2014 14:10:32 +0200 (CEST)
Received: from inf-205-85.inf.um.es (inf-205-85.inf.um.es [155.54.205.85]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 38EF9B06F; Thu, 10 Apr 2014 14:10:28 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_76FB84FB-0019-434C-8070-833BE690ABAF"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Rafa Marin Lopez 
In-Reply-To: 
Date: Thu, 10 Apr 2014 14:10:27 +0200
Message-Id: <15E6B56E-7040-4470-92E8-6A676227C862@um.es>
References: <348D480C-316F-4B8B-954E-78573247955E@um.es> 
To: sarikaya@ieee.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/c-t5_coqSTcdQt38EITIw-ZPdBI
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Integrating AAA and CoAP
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, 10 Apr 2014 12:10:40 -0000

--Apple-Mail=_76FB84FB-0019-434C-8070-833BE690ABAF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Behcet:

First of all, thanks for reading the draft. Please see my comments =
inline.

El 09/04/2014, a las 20:58, Behcet Sarikaya  =
escribi=F3:

> Hi Rafa,
>=20
> I was reading your draft. I think using COAP as EAP transport is an =
interesting idea.

Many thanks for your time.

>=20
> However, I could not see anywhere in your document what is the problem =
you are trying to solve.
>=20
> Hopefully you can related the problem with the problem ace is trying =
to solve.

As I mentioned in the previous e-mail, the idea of doing EAP over CoAP =
is previous to ACE. Initially, it was conceived to allow
only authenticated and authorized constrained nodes (EAP peer) to =
send/receive through the EAP authenticator (like a pure network access =
control model where the EAP authenticator was a gateway).=20

Then, it also evolved to a service that allows a controller (EAP =
authenticator) to authenticate and authorize constrained nodes assuming =
a backend AAA infrastructure and to bootstrap a security association =
between two CoAP endpoints. When somebody deploys the constrained =
device, the controller needs to be authenticated and authorized to send, =
for example, temperature measurements. Also, the constrained node only =
allows the controller to enforce, for example, some configuration =
information.=20

In any case, I agree with you on this. In fact, that is something we are =
discussing internally in order to relate our work with the uses cases =
I-D and the context of ACE. We hope to reflect our analysis in a next =
version of our document.

Best Regards.

>=20
> Regards,
>=20
> Behcet=20
>=20
>=20
> On Wed, Apr 9, 2014 at 1:18 PM, Rafa Marin Lopez  wrote:
> Dear all
>=20
> As promised, we have written the following (and modest) I-D to explain =
our ongoing work about an EAP-based authentication service for CoAP that =
involves an AAA infrastructure.
>=20
> http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-00
>=20
> Hope this helps somehow to ACE.
>=20
> Best Regards.
>=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
>=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
-------------------------------------------------------





--Apple-Mail=_76FB84FB-0019-434C-8070-833BE690ABAF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Hi =
Behcet:

First of all, thanks for reading the draft. =
Please see my comments inline.

El 09/04/2014, a =
las 20:58, Behcet Sarikaya <sarikaya2012@gmail.com> =
escribi=F3:

Hi =
Rafa,

I was reading your draft. I think using COAP as EAP =
transport is an interesting =
idea.

Many =
thanks for your time.


However, I could not see =
anywhere in your document what is the problem you are trying to =
solve.


Hopefully you can related the problem with the problem ace is =
trying to =
solve.

As I =
mentioned in the previous e-mail, the idea of doing EAP over CoAP is =
previous to ACE. Initially, it was conceived to allow
only =
authenticated and authorized constrained nodes (EAP peer) to =
send/receive through the EAP authenticator (like a pure network access =
control model where the EAP authenticator was a =
gateway). 

Then, it also evolved to a =
service that allows a controller (EAP authenticator) to authenticate and =
authorize constrained nodes assuming a backend AAA infrastructure and to =
bootstrap a security association between two CoAP endpoints. When =
somebody deploys the constrained device, the controller needs to be =
authenticated and authorized to send, for example, temperature =
measurements. Also, the constrained node only allows the controller to =
enforce, for example, some configuration =
information. 

In any case, I agree with =
you on this. In fact, that is something we are discussing internally in =
order to relate our work with the uses cases I-D and the context of ACE. =
We hope to reflect our analysis in a next version of our =
document.

Best Regards.


Regards,

Behcet =



On =
Wed, Apr 9, 2014 at 1:18 PM, Rafa Marin Lopez <rafa@um.es> =
wrote:


Dear all



As promised, we have written the following (and modest) I-D to explain =
our ongoing work about an EAP-based authentication service for CoAP that =
involves an AAA infrastructure.



http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-0=
0



Hope this helps somehow to ACE.



Best Regards.



-------------------------------------------------------

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=_76FB84FB-0019-434C-8070-833BE690ABAF--


From nobody Thu Apr 10 14:59: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 3CBCB1A0228 for ; Thu, 10 Apr 2014 14:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level: 
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 dlt9F7D-1aTw for ; Thu, 10 Apr 2014 14:58:52 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 71D371A01AF for ; Thu, 10 Apr 2014 14:58:52 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id m1so5158231oag.7 for ; Thu, 10 Apr 2014 14:58:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=LrRGBQnw2ZenhLN+o/zmUqh89EJ9sVfpfHpEOVs0uUc=; b=pzuMsVjvxD+RDA/U9FB9AlTsfmq4fM8Q0kvCqgBmcshy4CvabIt88r8VVZg9d/UP1P S842A8mQ+T7Iaod+tTXmde2dzxfnlBdC0sWLHEB09RSARJaAd5aMDGt8Ep20E/M3yvDS pStYPOhT1U6lX6FJm6BZgsRn56Hke1T71uHvOhjCCE+MlGZ+hs/qjTRsNNEuyOJkfxkp LqgFYw3vxU2uixkgc6K0eM2W+KZ6dTlsLMkfftgiuGPhO8vhtLoU92frcYCQbnsZJ0Ap uUuQzG2VazItrSf1Pc1DaQaGChKiKfVSgg6pOZgzv68K68WKpYimIfbo+/v9U2C5zI+e cE+Q==
X-Received: by 10.60.229.228 with SMTP id st4mr16127186oec.16.1397167131392; Thu, 10 Apr 2014 14:58:51 -0700 (PDT)
Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id pv6sm9075803obb.1.2014.04.10.14.58.48 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 14:58:50 -0700 (PDT)
Message-ID: <53471413.5070207@gmail.com>
Date: Thu, 10 Apr 2014 17:58:43 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Hannes Tschofenig ,  "ace@ietf.org" 
References: <533CFC50.3090801@gmx.net>
In-Reply-To: <533CFC50.3090801@gmx.net>
Content-Type: multipart/alternative; boundary="------------040102040701090201080302"
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/87_BcQCxp1d1ze-9r0icLbcOHaM
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 10 Apr 2014 21:58:57 -0000

This is a multi-part message in MIME format.
--------------040102040701090201080302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Hannes:

I had a look at the charter text. I do agree with the two tasks 
identified in the charter.

I do have some some comments on the (rather lengthy) prelude to the 
enumeration of these two tasks. These comments do not matter if the 
group agrees that the charter does not try and steer into a particular 
solution direction (as some comments on the list have indeed suggested 
to be the case). My comments are worded in case this is not so.

Small comments:
a) 2nd para, l. 3: replace "authorization decisions" by "authorization 
criteria" or "authorization policy". After all, decisions are not 
stored, but acted upon.
b) 2nd para, l. -1: replace "resource server" by "resource owner", 
"resource holder", or similar. This would make it clearer that the 
"server" is the device that actually stores the info the client is 
soliciting.
c) 4th para, l.. -1: not sure what the exact context of "consent of the 
user" is. Aren't we talking about device-to-device communications, where 
user may only be involved with configuration decisions (and, perhaps, 
even only remotely).
d) 6th para, l. 4: replace "will be required" by "may be required".

Main comments:
a) 3rd para: This whole para seems to presort solutions, by suggesting 
that one wishes to look at three-party protocols. Moreover, why would 
one care whether IETF had a "tradition" to develop something (for a 
completely different setting than constrained devices and networks)? The 
example protocols are a disparate set, where Kerberos and AAA require 
inline third parties and, e.g., authenticated public-key based key 
agreement only uses a CA as offline third party (or does the word "PKI" 
imply here OCSP, CRLs, etc, as well?). In all cases, it is not entirely 
clear whether these all serve to provide authentication and fine-grained 
authorization objectives. I would suggest scrapping this whole para.
b) 4th para: I would scrap any hint at suitability of solutions and go 
into this effort with an open mind (i.e., scrap "suitability of existing 
work, such as OAuth", etc.).
c) 5th para: by stipulating that client and server are constrained, but 
authorization server is not, one rules out any implementation where the 
authorization server coincides with client or server. This seems 
imprudent, since authorization decisions on client request by the server 
can be based on (1) locally maintained info (access control list style); 
(2) information included with the client request message flow; (3) info 
obtained from a third-party helper device that assists the server with 
this decision. The way things are currently phrased seems to be steer 
this into direction #3. Again, please keep an open mind and do not 
pre-bake solution directions in the charter.
d) 6th para: I would not over-estimate the existing "deployment 
experience", nor "available security analysis" (there is quite some 
crypto and security literature that IETF never tapped and some of the 
security properties of widely used IETF protocols is being heavily 
disccussed/criticized on other lists (tls list)). In my mind, referring 
to "IETF tradition" and "benefit of security analysis", etc., could 
therefore be somewhat dangerous.
e) 7th para: I would suggest scrapping the entire para, since much too 
ambitious (one can easily recharter to take on more work or refocus at a 
later stage). This is especially so, since expertise with security, 
privacy, and good understanding of usability (as alluded to in the 8th 
para) is in rather short supply (one may of course disagree here).

*Draft Charter V0.9a - Authentication and Authorization for Constrained 
Environment (ACE)*

The IETF has recently developed protocols for use in constrained 
environments, where network nodes are limited in CPU, memory and power. 
It has been 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 environments. An example of 
such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions 
also arise in constrained environments. 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 temporarily granted 
to other persons? How can access be revoked? These types of questions 
have been answered by existing protocols for use cases outside 
constrained environments, however in constrained environments, 
additional and different requirements pose challenges for the use of 
various security protocols. In particular, the need arises for a dynamic 
and fine grained access control mechanism, where clients and/or resource 
servers are constrained.

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 result from the 
main deployment use cases they were designed for respectively.

Requirements derived from use cases indicate the suitability of existing 
work, such as OAuth, as a solution for constrained environments. These 
protocols, however, were 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 resource access request due to intermittent 
connectivity, etc.

This working group therefore aims to produce 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 at a resource server by a 
client device takes place using CoAP and is protected by DTLS. Both 
resource server and client may be constrained. This access will be 
mediated by an authorization server, which is not considered to be 
constrained.

Existing authentication and authorization protocols will be used and 
re-applied for use in constrained environments where applicable. This 
requires relevant specifications to be reviewed for suitability, 
selecting a subset of them and restricting the options within each of 
the specifications. Some functionality, however, may not be available in 
existing protocols and thus new standardization efforts will be 
required. Leveraging existing work means the working 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 constrained 
devices that provide increased security.

Once progress in identifying suitable candidate solutions has been made, 
the working group will verify whether the same mechanisms 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 deployments will be studied, particularly 
concerning the use of protocol translation proxies.

To be successful, this working group requires expertise in security, 
privacy, and a good understanding of usability in constrained 
environments. 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:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for 
resource access in constrained environments.

Milestones:

  * Jul 2014 Submit "Use cases and Requirements" as a WG item.
  * Dec 2014 Submit "Authentication and Authorization Solution" as a WG
    item.
  * Jul 2015 Submit "Use cases and Requirements" document to the IESG
    for publication as an Informational RFC.
  * Jul 2016 Submit "Authentication and Authorization Solution"
    specification to the IESG for publication as a Proposed Standard.



On 4/3/2014 2:14 AM, Hannes Tschofenig wrote:
> Hi all,
>
> we have used the time after the IETF to discuss various open issues and
> we believe that we have covered all topics raised.
>
> It is our impression that the current charter text reflects the views of
> the group. Here is the latest version distributed by Kepeng a few  days
> ago:
> http://tools.ietf.org/wg/core/trac/wiki/ACE_charter#
>
> Before we forward the charter text to the IESG we want to issue a 'last
> call for comments'. Please provide your feedback at latest by **April
> 10th**.
>
> Ciao
> Hannes & Kepeng
>
> PS: Regarding the recent proxy discussion it was our impression that no
> changes to the charter text are necessary. The topic can (and should) be
> covered as part of the requirements/use case discussion, which is
> already explicitly stated in the charter.
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--------------040102040701090201080302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Hannes:

      

      I had a look at the charter text. I do agree with the two tasks
      identified in the charter.

      

      I do have some some comments on the (rather lengthy) prelude to
      the enumeration of these two tasks. These comments do not matter
      if the group agrees that the charter does not try and steer into a
      particular solution direction (as some comments on the list have
      indeed suggested to be the case). My comments are worded in case
      this is not so.

      

      Small comments:

      a) 2nd para, l. 3: replace "authorization decisions" by
      "authorization criteria" or "authorization policy". After all,
      decisions are not stored, but acted upon.

      b) 2nd para, l. -1: replace "resource server" by "resource owner",
      "resource holder", or similar. This would make it clearer that the
      "server" is the device that actually stores the info the client is
      soliciting.

      c) 4th para, l.. -1: not sure what the exact context of "consent
      of the user" is. Aren't we talking about device-to-device
      communications, where user may only be involved with configuration
      decisions (and, perhaps, even only remotely).

      d) 6th para, l. 4: replace "will be required" by "may be
      required".

      

      Main comments:

      a) 3rd para: This whole para seems to presort solutions, by
      suggesting that one wishes to look at three-party protocols.
      Moreover, why would one care whether IETF had a "tradition" to
      develop something (for a completely different setting than
      constrained devices and networks)? The example protocols are a
      disparate set, where Kerberos and AAA require inline third parties
      and, e.g., authenticated public-key based key agreement only uses
      a CA as offline third party (or does the word "PKI" imply here
      OCSP, CRLs, etc, as well?). In all cases, it is not entirely clear
      whether these all serve to provide authentication and fine-grained
      authorization objectives. I would suggest scrapping this whole
      para.

      b) 4th para: I would scrap any hint at suitability of solutions
      and go into this effort with an open mind (i.e., scrap
      "suitability of existing work, such as OAuth", etc.).

      c) 5th para: by stipulating that client and server are
      constrained, but authorization server is not, one rules out any
      implementation where the authorization server coincides with
      client or server. This seems imprudent, since authorization
      decisions on client request by the server can be based on (1)
      locally maintained info (access control list style); (2)
      information included with the client request message flow; (3)
      info obtained from a third-party helper device that assists the
      server with this decision. The way things are currently phrased
      seems to be steer this into direction #3. Again, please keep an
      open mind and do not pre-bake solution directions in the charter.

      d) 6th para: I would not over-estimate the existing "deployment
      experience", nor "available security analysis" (there is quite
      some crypto and security literature that IETF never tapped and
      some of the security properties of widely used IETF protocols is
      being heavily disccussed/criticized on other lists (tls list)). In
      my mind, referring to "IETF tradition" and "benefit of security
      analysis", etc., could therefore be somewhat dangerous.

      e) 7th para: I would suggest scrapping the entire para, since much
      too ambitious (one can easily recharter to take on more work or
      refocus at a later stage). This is especially so, since expertise
      with security, privacy, and good understanding of usability (as
      alluded to in the 8th para) is in rather short supply (one may of
      course disagree here).

       

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

      
The IETF has recently
        developed protocols for use in constrained environments, where
        network nodes are limited in CPU, memory and power. It has been
        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
        environments. An example of such a protocol is the Constrained
        Application Protocol (CoAP).

      
As in other environments,
        authentication and authorization questions also arise in
        constrained environments. 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 temporarily granted to other persons? How can
        access be revoked? These types of questions have been answered
        by existing protocols for use cases outside constrained
        environments, however in constrained environments, additional
        and different requirements pose challenges for the use of
        various security protocols. In particular, the need arises for a
        dynamic and fine grained access control mechanism, where clients
        and/or resource servers are constrained.

      
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 result from the
        main deployment use cases they were designed for respectively.

      
Requirements derived from
        use cases indicate the suitability of existing work, such as
        OAuth, as a solution for constrained environments. These
        protocols, however, were 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 resource
        access request due to intermittent connectivity, etc.

      
This working group
        therefore aims to produce 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 at a resource
        server by a client device takes place using CoAP and is
        protected by DTLS. Both resource server and client may be
        constrained. This access will be mediated by an authorization
        server, which is not considered to be constrained.

      
Existing authentication
        and authorization protocols will be used and re-applied for use
        in constrained environments where applicable. This requires
        relevant specifications to be reviewed for suitability,
        selecting a subset of them and restricting the options within
        each of the specifications. Some functionality, however, may not
        be available in existing protocols and thus new standardization
        efforts will be required. Leveraging existing work means the
        working 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
        constrained devices that provide increased security.

      
Once progress in
        identifying suitable candidate solutions has been made, the
        working group will verify whether the same mechanisms 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 deployments
        will be studied, particularly concerning the use of protocol
        translation proxies.

      
To be successful, this
        working group requires expertise in security, privacy, and a
        good understanding of usability in constrained environments.
        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:

      
1) Produce use cases and
        requirements

      
2) Identify
        authentication and authorization mechanisms suitable for
        resource access in constrained environments.

      
Milestones:

      
    
        
  • Jul 2014 Submit “Use cases and Requirements” as a WG item.
    • 
        
  • Dec 2014 Submit “Authentication and Authorization Solution”
          as a WG item.
    • 
        
  • Jul 2015 Submit “Use cases and Requirements” document to the
          IESG for publication as an Informational RFC.
    • 
        
  • Jul 2016 Submit “Authentication and Authorization Solution”
          specification to the IESG for publication as a Proposed
          Standard.
    • 
      

      

      

      On 4/3/2014 2:14 AM, Hannes Tschofenig wrote:

    

    

      
Hi all,

we have used the time after the IETF to discuss various open issues and
we believe that we have covered all topics raised.

It is our impression that the current charter text reflects the views of
the group. Here is the latest version distributed by Kepeng a few  days
ago:
http://tools.ietf.org/wg/core/trac/wiki/ACE_charter#

Before we forward the charter text to the IESG we want to issue a 'last
call for comments'. Please provide your feedback at latest by **April
10th**.

Ciao
Hannes & Kepeng

PS: Regarding the recent proxy discussion it was our impression that no
changes to the charter text are necessary. The topic can (and should) be
covered as part of the requirements/use case discussion, which is
already explicitly stated in the charter.



      

      

      

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


    

    

    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

  


--------------040102040701090201080302--


From nobody Thu Apr 10 16:48: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 2DBCB1A0346 for ; Thu, 10 Apr 2014 16:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.12
X-Spam-Level: **
X-Spam-Status: No, score=2.12 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 4ruTJ6-AcouL for ; Thu, 10 Apr 2014 16:48:18 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id C513A1A030F for ; Thu, 10 Apr 2014 16:48:15 -0700 (PDT)
Received: from [192.168.37.142] ([64.134.222.118]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MFuWk-1WjvXm3qEQ-00ErR2 for ; Fri, 11 Apr 2014 01:48:13 +0200
Message-ID: <5346E0CB.3010906@gmx.net>
Date: Thu, 10 Apr 2014 11:19:55 -0700
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: "ace@ietf.org" 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ij2cKSFUBDP98F8NrJJ6KOepLsii748PP"
X-Provags-ID: V03:K0:aV6uKx1/wLVlbi+RpGgMKwEPBb1TlkAhmhoE7iAAFrwWr8shQq4 YzYGZx2fXS+tDW9WumCw5dbZFOfaIhKSITJloEdv8/gvh8YNyPAA5uP3hleSdl/B9NdQq5m pf8pSlCuIWm9YURaCtO0aAggwxZE/nI8Phyfuu50dMRfBFG3i4bHgYLJdMZa6RVNAIQB/ff TsQdCt6oSnRPlXpBB1v4w==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/qTiXA0a-lfGMoXMpDcGNyl2dWTQ
Subject: [Ace] Authentication, Authorization and Key Distribution
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, 10 Apr 2014 23:48:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ij2cKSFUBDP98F8NrJJ6KOepLsii748PP
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi all,

based on the recent discussion I believe it is useful to clarify the
relationship between authentication, authorization, and key
distribution/key establishment.

There are various sources of literature but there is nothing that is
universally accepted. Needless to say that this typically causes a lot
of confusion in every identity management conversation. I am re-using
terminology text from the "Handbook of Applied Cryptography" and from
"Who goes there? Authentication Through the Lens of Privacy".

In a simplistic view what we are trying to accomplish is to allow a
client to access a protected resource and he gets access granted when he
is authorized to do so.

Authorization is the process of deciding what an entity ought to be
allowed to do. Authorization is distinct from authentication (which
establishes what an individual =93is=94 rather than what the individual =93=
is
allowed.=94). Authorization policies determine how authorization decision=
s
are made. Authorization policies base decision making on a variety of
factors, including identifiers (such as names) and attributes.

Hence, authentication and authorization are separate steps but they are
obviously related to each other.

At this point the story becomes more complex.

Many deployments involve a centralized or trusted party, for either or
both initial system setup and on-line actions (i.e., involving real-time
participation). This party is referred to by a variety of names
depending on the role played, including: trusted third party, trusted
server, authentication server, key distribution center (KDC), key
translation center (KTC), and certification authority (CA).

So, we are not just talking about a two-party environment but about a
multi-party environment.

Earlier this year we discussed this topic on the ACE mailing list and we
said that we want to work with solutions that involve such a trusted
party (as I tried to explain in Section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00).

When you have a trusted third party you can use that party to develop a
more scalable way to manage authorization policies. Better management
comes with the price of having that additional party in the game.

Hence, instead of having the client to authenticate to the relying party
directly the exchange involves the trusted third party to which the
client is authenticated instead. To provide confidence to the relying
party that this step has indeed happened some information (in a
protected form) needs to be communicated from the trusted party to the
relying party (the resource server). This is where key establishment
comes into the picture.

Key establishment is a process or protocol whereby a shared secret
becomes  available to two or more parties, for subsequent cryptographic
use. Of course there are differences in the details depending on the use
of symmetric vs. asymmetric keys. (We don't want to go into any of these
details but if you look at Section 2 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 then you can
see how existing protocols have dealt with this issue.)

I hope that this clarification helps to convince you that it is a bit
difficult to capture this and the necessary background in the charter.

Ciao
Hannes


--Ij2cKSFUBDP98F8NrJJ6KOepLsii748PP
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/

iQEcBAEBCgAGBQJTRuDLAAoJEGhJURNOOiAtSEIH/38ZkdwgDkEhMJSsEGBSvIW0
e2E0mcf6yfKyygMSUggo33VJ534rFyEk0TCCFkXkceB+uE8fsUfh4eHb81tRtU9p
695/8hVp03KFpPJrrUt6Nb3biTJSecTKGBqbTDX++SFxB80758IlWGxp4V9NWeMw
QxkqQTOT2LJAsNjNZCdI9t0SLG8UxSqONGO80UF4+qzriPtXjZmplyVfCUEvUHcZ
hlSCvOH/m1LcLHupi1crhic6zWS2BbqHPtB/nQpHs9dY0nMh5AmfCjf0NNKuQ3od
Q27haS11wjHlwogAwP9bbDChpehfnljZhkP470BqMSpjwl3yV+JzFoT5Ic+xBeY=
=p+To
-----END PGP SIGNATURE-----

--Ij2cKSFUBDP98F8NrJJ6KOepLsii748PP--


From nobody Thu Apr 10 17:37:29 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 D9C401A03B5 for ; Thu, 10 Apr 2014 17:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level: 
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 MXaYePeAVAyz for ; Thu, 10 Apr 2014 17:37:19 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 179191A0397 for ; Thu, 10 Apr 2014 17:37:18 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id n15so2952545lbi.13 for ; Thu, 10 Apr 2014 17:37:17 -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=9kwxinL08vjJa/JvlzCnk3Q+Clrnab3kn51zPuMw4UA=; b=u8JzxFD0bsexhaQTNNguDKyzIWllaN6sYp6cDln3x6J1QaYK9B/mPhIbpTqSHuX1X3 yz5Qsyc9IXEdPaKa1r7l+FZ+Aw//j2wI4BG24SPf0k+m9PSYTYugO151k+a4XI8r1hB/ OEHJJ++dlN81lZDnJ5TFIJqY33vmOFuSMaPLuB4rHvE9PtT6KXhqW9W5nnfoCOeQgZX+ 5D5GIx6zvmzrgD7o10av2r9+n611UDBkSBKIW1mx9FPnM6kI4XyljI+PMRfrjxC6hm0c WtunqV+bE6587sLipFQqAmBYVvqTs/CXJXMIXcAZo105XWBmfW91/t8200I++FF5nz0m xxuw==
MIME-Version: 1.0
X-Received: by 10.112.135.106 with SMTP id pr10mr13429523lbb.24.1397176637332;  Thu, 10 Apr 2014 17:37:17 -0700 (PDT)
Received: by 10.114.67.82 with HTTP; Thu, 10 Apr 2014 17:37:17 -0700 (PDT)
Received: by 10.114.67.82 with HTTP; Thu, 10 Apr 2014 17:37:17 -0700 (PDT)
In-Reply-To: <5346E0CB.3010906@gmx.net>
References: <5346E0CB.3010906@gmx.net>
Date: Fri, 11 Apr 2014 02:37:17 +0200
Message-ID: 
From: Rene Struik 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=089e012292f8281f2404f6b989dd
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/5usuU74EcQyYlM7XZncMUR4ME7E
Cc: ace@ietf.org
Subject: Re: [Ace] Authentication, Authorization and Key Distribution
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, 11 Apr 2014 00:37:25 -0000

--089e012292f8281f2404f6b989dd
Content-Type: text/plain; charset=ISO-8859-1

Hi Hannes:

I am not sure the assertion that protocols that involve three parties are
more scalable is necessarily justified at this point. In my mind,
pre-sorting for this solution direction in the charter is unjustified (we
may end up there, but should cast the net wider with the SoW). Do you have
any supporting evidence for your assertion? What if, for example, the
communication channel is spotty, with relatively sparse (in time)
opportunities to communicate?

Glad you consulted the Handbook, though.

Rene

Traveling right now...
On Apr 10, 2014 7:48 PM, "Hannes Tschofenig" 
wrote:

> Hi all,
>
> based on the recent discussion I believe it is useful to clarify the
> relationship between authentication, authorization, and key
> distribution/key establishment.
>
> There are various sources of literature but there is nothing that is
> universally accepted. Needless to say that this typically causes a lot
> of confusion in every identity management conversation. I am re-using
> terminology text from the "Handbook of Applied Cryptography" and from
> "Who goes there? Authentication Through the Lens of Privacy".
>
> In a simplistic view what we are trying to accomplish is to allow a
> client to access a protected resource and he gets access granted when he
> is authorized to do so.
>
> Authorization is the process of deciding what an entity ought to be
> allowed to do. Authorization is distinct from authentication (which
> establishes what an individual "is" rather than what the individual "is
> allowed."). Authorization policies determine how authorization decisions
> are made. Authorization policies base decision making on a variety of
> factors, including identifiers (such as names) and attributes.
>
> Hence, authentication and authorization are separate steps but they are
> obviously related to each other.
>
> At this point the story becomes more complex.
>
> Many deployments involve a centralized or trusted party, for either or
> both initial system setup and on-line actions (i.e., involving real-time
> participation). This party is referred to by a variety of names
> depending on the role played, including: trusted third party, trusted
> server, authentication server, key distribution center (KDC), key
> translation center (KTC), and certification authority (CA).
>
> So, we are not just talking about a two-party environment but about a
> multi-party environment.
>
> Earlier this year we discussed this topic on the ACE mailing list and we
> said that we want to work with solutions that involve such a trusted
> party (as I tried to explain in Section 1 of
> http://tools.ietf.org/html/draft-tschofenig-ace-overview-00).
>
> When you have a trusted third party you can use that party to develop a
> more scalable way to manage authorization policies. Better management
> comes with the price of having that additional party in the game.
>
> Hence, instead of having the client to authenticate to the relying party
> directly the exchange involves the trusted third party to which the
> client is authenticated instead. To provide confidence to the relying
> party that this step has indeed happened some information (in a
> protected form) needs to be communicated from the trusted party to the
> relying party (the resource server). This is where key establishment
> comes into the picture.
>
> Key establishment is a process or protocol whereby a shared secret
> becomes  available to two or more parties, for subsequent cryptographic
> use. Of course there are differences in the details depending on the use
> of symmetric vs. asymmetric keys. (We don't want to go into any of these
> details but if you look at Section 2 of
> http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 then you can
> see how existing protocols have dealt with this issue.)
>
> I hope that this clarification helps to convince you that it is a bit
> difficult to capture this and the necessary background in the charter.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>

--089e012292f8281f2404f6b989dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Hannes:


I am not sure the assertion that protocols that involve thre=
e parties are more scalable is necessarily justified at this point. In my m=
ind, pre-sorting for this solution direction in the charter is unjustified =
(we may end up there, but should cast the net wider with the SoW). Do you h=
ave any supporting evidence for your assertion? What if, for example, the c=
ommunication channel is spotty, with relatively sparse (in time) opportunit=
ies to communicate?



Glad you consulted the Handbook, though.


Rene


Traveling right now...


On Apr 10, 2014 7:48 PM, "Hannes Tschofenig=
" <hannes.tschofenig@g=
mx.net> wrote:
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00<=
/a>).



When you have a trusted third party you can use that party to develop a

more scalable way to manage authorization policies. Better management

comes with the price of having that additional party in the game.



Hence, instead of having the client to authenticate to the relying party
directly the exchange involves the trusted third party to which the

client is authenticated instead. To provide confidence to the relying

party that this step has indeed happened some information (in a

protected form) needs to be communicated from the trusted party to the

relying party (the resource server). This is where key establishment

comes into the picture.



Key establishment is a process or protocol whereby a shared secret

becomes  available to two or more parties, for subsequent cryptographi=
c

use. Of course there are differences in the details depending on the use
of symmetric vs. asymmetric keys. (We don't want to go into any of thes=
e

details but if you look at Section 2 of

http://tools.ietf.org/html/draft-tschofenig-ace-overview-00<=
/a> then you can

see how existing protocols have dealt with this issue.)



I hope that this clarification helps to convince you that it is a bit

difficult to capture this and the necessary background in the charter.



Ciao

Hannes




_______________________________________________

Ace mailing list

Ace@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/ace




--089e012292f8281f2404f6b989dd--


From nobody Thu Apr 10 22:23: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 0D0891A02CB for ; Thu, 10 Apr 2014 22:23:35 -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 dmOo7IJRAIRg for ; Thu, 10 Apr 2014 22:23:30 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3E1A0280 for ; Thu, 10 Apr 2014 22:23:29 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f328e0000012ab-c3-53477c4f9a70
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A7.98.04779.F4C77435; Fri, 11 Apr 2014 07:23:27 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Fri, 11 Apr 2014 07:23:27 +0200
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= 
To: "robert.cragie@gridmerge.com" , "Carsten Bormann" 
Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text
Thread-Index: AQHPVGQwmTBwDmssLEivIjwWBwpK/ZsKQYKAgAAKSoCAAZe/AA==
Date: Fri, 11 Apr 2014 05:23:27 +0000
Message-ID: 
References: <533CFC50.3090801@gmx.net>  <533ED496.8060608@gmx.net>  <533FC2DB.1040103@gmx.net>     <5345225C.1060701@ifi.uzh.ch> <534572BD.9070308@sics.se>  <65E351B5-B34D-48E5-9C09-7DE13FF50600@tzi.org> <53464263.1000607@gridmerge.com>
In-Reply-To: <53464263.1000607@gridmerge.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-ID: <32B587EEFBD8DC47868F4B92440A20FE@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja5/jXuwwdHHxhbfv/UwWxyZcpfV 4ua+e8wOzB53/jxj9liy5CeTx7RFmQHMUVw2Kak5mWWpRfp2CVwZvXeb2QpeiVR0vWtjamBc ItLFyMEhIWAi8eyZRRcjJ5ApJnHh3nq2LkYuDiGBw4wS12+sZYZwFjNKnPr5mBmkik3AReJB wyMmEFtEIFli9uNZbCA2s4CixLo5fWBxYQFbiQXzHrBB1NhJfPj5hR3CdpI40nOHEcRmEVCV mPPnH9hMXgFzielTGpggls1glVjxphmsiFNAV+L9qxUsIDYj0HnfT61hglgmLnHryXwmiLMF JJbsOc8MYYtKvHz8jxXEFhXQk3h3HKZGSaJxyRNWkI+ZBTQl1u/ShxhjLTHz4Rx2mPundD9k h7hHUOLkzCcsExglZiHZNguhexaS7llIumch6V7AyLqKkT03MTMnvdxwEyMw9g5u+a27g/HU OZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJRdWeBvpx7cNqVs2nsL e7edi2de9863aZNn5lI+dmj+xpT3fiEau03+PNm4vz6zed46fY+KJp7mdVuTGF9kOAu6WD7X vdns15iiu6vcuPiscPHbFe4zZ5icPMw02bhxqZV+l9/7dQKJy/p18iO/J8Sbam1ZPinp8Fbp eofrZnmbtt5aGdMjpMRSnJFoqMVcVJwIACWDqzWLAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/xl3h0AuV0olUMtp5RRTkqoEqRRo
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 11 Apr 2014 05:23:35 -0000

SGkgQ2Fyc3RlbiwgUm9iZXJ0LA0KDQpIYW5uZXMga2luZGx5IHByb3ZpZGVkIHRoZSBjb250ZXh0
IGluIGEgcmVjZW50IG1haWwuIEkgZ2V0IHRoZSBwYXJ0IHRoYXQNCnRoaXMgaXMgcGVyaGFwcyBu
b3Qgc28gZWFzeSB0byBmb3JtdWxhdGUgaW4gYSBzZW50ZW5jZSwgYW5kIHNheWluZyBtb3JlDQp3
b3VsZCBwcm9iYWJseSBnbyB0b28gbXVjaCBpbnRvIGRldGFpbHMuIEhvd2V2ZXIsIEkgbWFpbnRh
aW4gdGhhdCB0aGUNCmV4YW1wbGUgaXMgcmVsZXZhbnQgYW5kIHdpbGwgcmV0dXJuIHRvIHRoYXQg
aW4gdGhlIHJlcXVpcmVtZW50cyBkaXNjdXNzaW9uLg0KDQoNCkfDtnJhbg0KDQoNCk9uIDEwLzA0
LzE0IDA5OjA0LCAiUm9iZXJ0IENyYWdpZSIgPHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbT4g
d3JvdGU6DQoNCj5JIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCBDYXJzdGVuLiBXaGF0IGlzIGEgImtl
eSBtYW5hZ2VtZW50IHNvbHV0aW9uIj8gSQ0KPndvdWxkIHJhdGhlciBub3Qgc2VlIHRoZSB3b3Jk
ICJrZXkiIHVzZWQgaW4gdGhlIGNoYXJ0ZXIgKGFuZCBJIGRvbid0DQo+Y291bnQgImRpZ2l0YWwg
a2V5IiBhcyB0aGF0IGlzIGEgZ2VuZXJhbGlzYXRpb24gaW4gdGhlIGNvbnRleHQgb2YgYSBkb29y
DQo+bG9jaykgb3IgYW55IGxhbmd1YWdlIHdoaWNoIGF0dGVtcHRzIHRvIGNvbnN0cmFpbiB0aGUg
cG9zc2libGUNCj5zb2x1dGlvbnMuIEFsbCB0aGUgY2hhcnRlciBzaG91bGQgZG8gaXMgc2V0IHRo
ZSBjb250ZXh0IGFuZCBpZGVudGlmeSB0aGUNCj50YXNrcyBhbmQgcHJvZHVjdHMsIHdoaWNoIGlz
IGRvZXMuDQo+DQo+Um9iZXJ0DQo+DQo+T24gMTAvMDQvMjAxNCA3OjI3IEFNLCBDYXJzdGVuIEJv
cm1hbm4gd3JvdGU6DQo+PiBPbiAxMCBBcHIgMjAxNCwgYXQgMDc6NTEsIEfDtnJhbiBTZWxhbmRl
ciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPg0KPj53cm90ZToNCj4+DQo+Pj4gSW4gc29t
ZSBvZiB0aG9zZSBjYXNlcywgdGhlIGRldmljZSBpcyBpbnRlbmRlZCB0byBiZSBmdWxseSBvcGVy
YXRpb25hbA0KPj4+IHRoZXJlYWZ0ZXIsIGluIHBhcnRpY3VsYXIgdGhhdCBhIGRldmljZSBjYW4g
YXV0aGVudGljYXRlIGFuZCBhdXRob3Jpc2UNCj4+PiByZXF1ZXN0cyB3aXRoIGtleXMgZGVyaXZl
ZCB0aHJvdWdoIGEgY29tbW9uIGtleSBtYW5hZ2VtZW50IHNjaGVtZSB1c2luZw0KPj4+IHRoZSBl
c3RhYmxpc2hlZCBrZXlzLCB3aXRob3V0IGFueSBmdXJ0aGVyIHByb3Zpc2lvbmluZy4NCj4+IFll
cywgYnV0IHRoZSBlbmQgb2YgwrNwcm92aXNpb25pbmciIGRvZXNuwrl0IG1lYW4gdGhlcmUgaXMg
bm8gZnVydGhlcg0KPj5jb21tdW5pY2F0aW9uIGFib3V0IGVzdGFibGlzaGluZyBhdXRoZW50aWNh
dGVkIGF1dGhvcml6YXRpb24uDQo+Pg0KPj4+ICJBIGNvbW1vbiBrZXkgbWFuYWdlbWVudCBzb2x1
dGlvbiBmb3IgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcmlzYXRpb24NCj4+PiB3aWxsIGJlIHNw
ZWNpZmllZC4iDQo+PiBJwrltIGFmcmFpZCB0aGF0IHNlbnRlbmNlIHNheXMgc29tZXRoaW5nIGRp
ZmZlcmVudCwgYXBwcm94aW1hdGVseSDCs2FsbA0KPj5vZiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0
aG9yaXphdGlvbiB3aWxsIGJlIGJhc2VkIG9uIGEgY29tbW9uIMKMa2V5DQo+Pm1hbmFnZW1lbnTC
ucKyLiAgKEkgZG9uwrl0IGtub3cgd2hhdCDCjGtleSBtYW5hZ2VtZW50wrkgaXMsIGJ1dCB0aGlz
IHNlbnRlbmNlDQo+PmFsc28gaW52aXRlcyBhbGwgdGhlIHdvcnN0IGludGVycHJldGF0aW9ucy4p
DQo+Pg0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBY2UgbWFpbGluZyBsaXN0DQo+PiBBY2VAaWV0
Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+Pg0K
Pg0KPg0KDQo=


From nobody Thu Apr 10 22:51: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 222601A03C3 for ; Thu, 10 Apr 2014 22:51:49 -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 s7ujD6PXhEkL for ; Thu, 10 Apr 2014 22:51:46 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 97D541A00B0 for ; Thu, 10 Apr 2014 22:51:45 -0700 (PDT)
X-AuditID: c1b4fb25-b7f3b8e0000006f1-04-534782ef909c
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C1.9C.01777.FE287435; Fri, 11 Apr 2014 07:51:43 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Fri, 11 Apr 2014 07:51:42 +0200
From: =?Windows-1252?Q?G=F6ran_Selander?= 
To: Rene Struik , Hannes Tschofenig 
Thread-Topic: [Ace] Authentication, Authorization and Key Distribution
Thread-Index: AQHPVRdbaezPnsWFWU+r52Own87v0JsLcKuAgAB5X4A=
Date: Fri, 11 Apr 2014 05:51:42 +0000
Message-ID: 
References: <5346E0CB.3010906@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.4.1.140326
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_CF6D3066E8A3goranselanderericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rvd9k3uwwYbXRhbfv/UwWyzdeY/V YvWN5ywOzB47Z91l91i8aT+bx5IlP5kCmKO4bFJSczLLUov07RK4Ms5+WM5U0J1dcfLUV5YG xn1RXYycHBICJhJLtmxlgrDFJC7cW8/WxcjFISRwmFHi14ttzCAJIYHFjBJbdiiD2GwC7hKP ezaygNgiAhESm1afBWtmFlCUWDenD8wWFnCVeNE0hxWixk3i5NPrjBC2lcTvj4vAelkEVCUu LbzODmLzCphLXD3YyASxK1di+v6zbCA2p0CgxMfu2WBzGIGO+35qDdQucYlbT+ZDHS0gsWTP eWYIW1Ti5eN/YPWiAnoS747D1ChJNC55wgrRGyNxYs1TVoi9ghInZz5hmcAoNgvJ2FlIymYh KYOIG0i8PzefGcLWlli28DWUrS+x8ctZRgjbWuLZxQZGZDULGDlWMbLnJmbmpJcbbWIExuXB Lb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYz500J/Cc6M 7jJ9yrul5bBYaPzxsMdPyx4rp0447yrZyxOXvIHD1SN24mz+fZsTjsiVHl8cVsvx69OdVd9D Tnseq3YpV3JkEdlifkG9usArQsryyf1+vbZLUSw2s0KimF4I7nm+9h77iuAOsztLmbdqeNdv dOmtL3uxZGMjk/vmsOi+P9/Le5RYijMSDbWYi4oTAVAUH5qZAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/O3LUG0YPlyc5T5_gQ5tgGHZFdy0
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Authentication, Authorization and Key Distribution
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, 11 Apr 2014 05:51:49 -0000

--_000_CF6D3066E8A3goranselanderericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi Rene

The TTP is also assumed to support authorisation decision and/or manage aut=
horisation policies for which the relying party may be too constrained. Whe=
n communication security context is available in client and relying party, =
and when relying party has an applicable and valid authorisation decision/p=
olicy cached, it should not be necessary to involve the TTP.

My understanding of the case where both client and relying party has no com=
munication channel with the TTP, and when there is no applicable authorisat=
ion decision/policy cached at the relying party, it is acceptable that the =
client is not granted access even though it being authorised (according to =
policy). For the same reason immediate revocation may be impossible.


G=F6ran

(As a side remark in light of this pre-sorting discussion, I find the most =
restrictive assumption in the current charter to insist on the main securit=
y protocol being DTLS.)


From: Rene Struik >
Date: Friday 11 April 2014 02:37
To: Hannes Tschofenig >
Cc: "ace@ietf.org" >
Subject: Re: [Ace] Authentication, Authorization and Key Distribution


Hi Hannes:

I am not sure the assertion that protocols that involve three parties are m=
ore scalable is necessarily justified at this point. In my mind, pre-sortin=
g for this solution direction in the charter is unjustified (we may end up =
there, but should cast the net wider with the SoW). Do you have any support=
ing evidence for your assertion? What if, for example, the communication ch=
annel is spotty, with relatively sparse (in time) opportunities to communic=
ate?

Glad you consulted the Handbook, though.

Rene

Traveling right now...

On Apr 10, 2014 7:48 PM, "Hannes Tschofenig" > wrote:
Hi all,

based on the recent discussion I believe it is useful to clarify the
relationship between authentication, authorization, and key
distribution/key establishment.

There are various sources of literature but there is nothing that is
universally accepted. Needless to say that this typically causes a lot
of confusion in every identity management conversation. I am re-using
terminology text from the "Handbook of Applied Cryptography" and from
"Who goes there? Authentication Through the Lens of Privacy".

In a simplistic view what we are trying to accomplish is to allow a
client to access a protected resource and he gets access granted when he
is authorized to do so.

Authorization is the process of deciding what an entity ought to be
allowed to do. Authorization is distinct from authentication (which
establishes what an individual =93is=94 rather than what the individual =93=
is
allowed.=94). Authorization policies determine how authorization decisions
are made. Authorization policies base decision making on a variety of
factors, including identifiers (such as names) and attributes.

Hence, authentication and authorization are separate steps but they are
obviously related to each other.

At this point the story becomes more complex.

Many deployments involve a centralized or trusted party, for either or
both initial system setup and on-line actions (i.e., involving real-time
participation). This party is referred to by a variety of names
depending on the role played, including: trusted third party, trusted
server, authentication server, key distribution center (KDC), key
translation center (KTC), and certification authority (CA).

So, we are not just talking about a two-party environment but about a
multi-party environment.

Earlier this year we discussed this topic on the ACE mailing list and we
said that we want to work with solutions that involve such a trusted
party (as I tried to explain in Section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00).

When you have a trusted third party you can use that party to develop a
more scalable way to manage authorization policies. Better management
comes with the price of having that additional party in the game.

Hence, instead of having the client to authenticate to the relying party
directly the exchange involves the trusted third party to which the
client is authenticated instead. To provide confidence to the relying
party that this step has indeed happened some information (in a
protected form) needs to be communicated from the trusted party to the
relying party (the resource server). This is where key establishment
comes into the picture.

Key establishment is a process or protocol whereby a shared secret
becomes  available to two or more parties, for subsequent cryptographic
use. Of course there are differences in the details depending on the use
of symmetric vs. asymmetric keys. (We don't want to go into any of these
details but if you look at Section 2 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 then you can
see how existing protocols have dealt with this issue.)

I hope that this clarification helps to convince you that it is a bit
difficult to capture this and the necessary background in the charter.

Ciao
Hannes


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


--_000_CF6D3066E8A3goranselanderericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable












Hi Rene







The TTP is also assumed to support authorisation decision and/or manag=
e authorisation policies for which the relying party may be too constr=
ained. When communication security context is available in client and relyi=
ng party, and when relying party has
 an applicable and valid authorisation decision/policy cached, it should no=
t be necessary to involve the TTP.







My understanding of the case where both client and relying party has n=
o communication channel with the TTP, and when there is no applicable autho=
risation decision/policy cached at the relying party, it is acceptable that=
 the client is not granted access
 even though it being authorised (according to policy). For the same reason=
 immediate revocation may be impossible.














G=F6ran









(As a side remark in light of this pre-sorting discussion, I find the =
most restrictive assumption in the current charter to insist on the main se=
curity protocol being DTLS.)














From: Rene Struik <rstruik.ext@gmail.com>

Date: Friday 11 April 2014 02:37
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

Cc: "ace@ietf.org" <ace@ietf.=
org>

Subject: Re: [Ace] Authentication, =
Authorization and Key Distribution















Hi Hannes:


I am not sure the assertion that protocols that involve thre=
e parties are more scalable is necessarily justified at this point. In my m=
ind, pre-sorting for this solution direction in the charter is unjustified =
(we may end up there, but should cast
 the net wider with the SoW). Do you have any supporting evidence for your =
assertion? What if, for example, the communication channel is spotty, with =
relatively sparse (in time) opportunities to communicate?


Glad you consulted the Handbook, though.


Rene


Traveling right now...


On Apr 10, 2014 7:48 PM, "Hannes Tschofenig=
" <hannes.tschofenig@g=
mx.net> wrote:



Hi all,



based on the recent discussion I believe it is useful to clarify the

relationship between authentication, authorization, and key

distribution/key establishment.



There are various sources of literature but there is nothing that is

universally accepted. Needless to say that this typically causes a lot

of confusion in every identity management conversation. I am re-using

terminology text from the "Handbook of Applied Cryptography" and =
from

"Who goes there? Authentication Through the Lens of Privacy".



In a simplistic view what we are trying to accomplish is to allow a

client to access a protected resource and he gets access granted when he
is authorized to do so.



Authorization is the process of deciding what an entity ought to be

allowed to do. Authorization is distinct from authentication (which

establishes what an individual =93is=94 rather than what the individual =93=
is

allowed.=94). Authorization policies determine how authorization decisions<=
br>
are made. Authorization policies base decision making on a variety of

factors, including identifiers (such as names) and attributes.



Hence, authentication and authorization are separate steps but they are

obviously related to each other.



At this point the story becomes more complex.



Many deployments involve a centralized or trusted party, for either or

both initial system setup and on-line actions (i.e., involving real-time
participation). This party is referred to by a variety of names

depending on the role played, including: trusted third party, trusted

server, authentication server, key distribution center (KDC), key

translation center (KTC), and certification authority (CA).



So, we are not just talking about a two-party environment but about a

multi-party environment.



Earlier this year we discussed this topic on the ACE mailing list and we
said that we want to work with solutions that involve such a trusted

party (as I tried to explain in Section 1 of

http://tools.ietf.org/html/draft-tschofenig-ace-overview-00<=
/a>).



When you have a trusted third party you can use that party to develop a

more scalable way to manage authorization policies. Better management

comes with the price of having that additional party in the game.



Hence, instead of having the client to authenticate to the relying party
directly the exchange involves the trusted third party to which the

client is authenticated instead. To provide confidence to the relying

party that this step has indeed happened some information (in a

protected form) needs to be communicated from the trusted party to the

relying party (the resource server). This is where key establishment

comes into the picture.



Key establishment is a process or protocol whereby a shared secret

becomes  available to two or more parties, for subsequent cryptographi=
c

use. Of course there are differences in the details depending on the use
of symmetric vs. asymmetric keys. (We don't want to go into any of these
details but if you look at Section 2 of

http://tools.ietf.org/html/draft-tschofenig-ace-overview-00<=
/a> then you can

see how existing protocols have dealt with this issue.)



I hope that this clarification helps to convince you that it is a bit

difficult to capture this and the necessary background in the charter.



Ciao

Hannes





_______________________________________________

Ace mailing list

Ace@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/ace

















--_000_CF6D3066E8A3goranselanderericssoncom_--


From nobody Thu Apr 10 23:19: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 CE95D1A03CD for ; Thu, 10 Apr 2014 23:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.348
X-Spam-Level: 
X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 uzmi6VqDoka8 for ; Thu, 10 Apr 2014 23:19:37 -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 2428F1A00B0 for ; Thu, 10 Apr 2014 23:19:36 -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 s3B6JW1c017156; Fri, 11 Apr 2014 08:19:32 +0200 (CEST)
Received: from [192.168.217.105] (p54892812.dip0.t-ipconnect.de [84.137.40.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 209BA1CAB; Fri, 11 Apr 2014 08:19:31 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Carsten Bormann 
In-Reply-To: <5346E0CB.3010906@gmx.net>
Date: Fri, 11 Apr 2014 08:19:29 +0200
X-Mao-Original-Outgoing-Id: 418889969.386726-4a2a17816a4c35382ebcd6c8ff875545
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5346E0CB.3010906@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/owKWWp7aEG_1TB457wMDUjDLSlE
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Authentication, Authorization and Key Distribution
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, 11 Apr 2014 06:19:39 -0000

Hi Hannes,

thanks for writing this up.

One point maybe merits mention here:

On 10 Apr 2014, at 20:19, Hannes Tschofenig  =
wrote:

> Hence, instead of having the client to authenticate to the relying =
party
> directly the exchange involves the trusted third party to which the
> client is authenticated instead.

In the Berlin model, the (resource) client never authenticates to the =
authorization server of the (resource) server either.
(How would it?  The two don=92t know anything about each other.)
Similarly, the resource server cannot authenticate the client as an =
entity, but of course it needs to authenticate its authorization.
(That=92s why it is useful to point out that it is not necessarily an =
identity that is being authenticated, see RFC 4949:

   $ authenticate
      (I) Verify (i.e., establish the truth of) an attribute value
      claimed by or for a system entity or system resource. (See:
      authentication, validate vs. verify, "relationship between data
      integrity service and authentication services" under "data
      integrity service=94.)

Obviously, even for identity attributes, the term =93truth=94 here is =
suboptimal: You can use my passport to authenticate that the State of =
Germany authorized me to claim that I=92m German citizen Carsten =
Bormann, but you=92ll never find out the =93truth" from that passport.)

As a terminology comment, I=92d like to replace =93A is trusted=94 (or, =
more specifically =93B trusts A=94) with =93B has authorized A to speak =
for X=94, where X is something specific and not a nebulous, =
all-encompassing concept of =93trust=94.  (The latter works nicely in =
the mother-duckling model, but in general is too limited.)

Gr=FC=DFe, Carsten


From nobody Fri Apr 11 00:04: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 BE48F1A012F for ; Fri, 11 Apr 2014 00:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.077
X-Spam-Level: 
X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272] 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 bK8nzODtaget for ; Fri, 11 Apr 2014 00:04:21 -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 D788E1A00EF for ; Fri, 11 Apr 2014 00:04:20 -0700 (PDT)
Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s3B6xqPk000874 for ; Fri, 11 Apr 2014 09:04:18 +0200
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1k59wu3y6f-1 for ; Fri, 11 Apr 2014 09:04:18 +0200
Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id C755C40116 for ; Fri, 11 Apr 2014 09:04:18 +0200 (CEST)
Message-ID: <534793EB.1020101@sics.se>
Date: Fri, 11 Apr 2014 09:04:11 +0200
From: Ludwig Seitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: ace@ietf.org
References: <533CFC50.3090801@gmx.net> <53471413.5070207@gmail.com>
In-Reply-To: <53471413.5070207@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090706070502010904080303"
X-Proofpoint-Spam-Reason: safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-04-11_03:2014-04-11,2014-04-11,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/deWrBbcauXptGwix7JZZuvEBzbU
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 11 Apr 2014 07:04:26 -0000

This is a cryptographically signed message in MIME format.

--------------ms090706070502010904080303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/10/2014 11:58 PM, Rene Struik wrote:
> Hi Hannes:
>
> I had a look at the charter text. I do agree with the two tasks
> identified in the charter.
>
> I do have some some comments on the (rather lengthy) prelude to the
> enumeration of these two tasks.

I tried to raise attention to the "rather lengthy" aspect of the charter =

descriptive text earlier. I still maintain it would be more accessible=20
and inviting if it was shorter, but I won't insist if the majority=20
thinks the "wall of text" approach is the way to go.

=2E..
> c) 5th para: by stipulating that client and server are constrained, but=

> authorization server is not, one rules out any implementation where the=

> authorization server coincides with client or server. This seems
> imprudent, since authorization decisions on client request by the serve=
r
> can be based on (1) locally maintained info (access control list style)=
;
> (2) information included with the client request message flow; (3) info=

> obtained from a third-party helper device that assists the server with
> this decision. The way things are currently phrased seems to be steer
> this into direction #3. Again, please keep an open mind and do not
> pre-bake solution directions in the charter.

I'd actually like to put (1) out of scope for this WG, since that would=20
be duplicating work by OMA-LW-M2M (or worse, proposing a competing=20
incompatible approach). If someone thinks it would be useful to redo=20
this, please explain.

/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


--------------ms090706070502010904080303
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
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MTEwNzA0MTFaMCMGCSqGSIb3DQEJBDEW
BBQno1Sf35U0jwjF4TvI5NWUkCaruzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE
ggEATlCnDNhC7oUvFHk0CDDUu1eXUXtYwvgpA+9NcPrvFx2tyz2xMVk+cVVFNx6kAimiZXm4
w3job8rRNGTH4itUXJbzTaYoI1IT5w5LRu4ks6N2GX3zRuSWpwqHbQz1QfsYklhyinyCnIwW
a8+GPB2S3y868/djbwiVlXE1rE4AdAY6S0yArwIfXUD3Qk533VsjrBZCIybPYmC+GlijsKPx
wW2qe08bsv6LWDUCly+mWxWXJjYazVJmMpLQzw8j7RNxUT84MkpEEb0GCLbvpIVtVRJ4Hl5n
CVCGCRzTaq4w6vhx7qT58v+N3j1Ek5M6vM41WRQVIyB7BqXjW77sTom+rAAAAAAAAA==
--------------ms090706070502010904080303--


From nobody Fri Apr 11 06:10: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 4FBD61A025A for ; Fri, 11 Apr 2014 06:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.472
X-Spam-Level: 
X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 LuQb-6K6xxHH for ; Fri, 11 Apr 2014 06:10:36 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AB0491A0250 for ; Fri, 11 Apr 2014 06:10:35 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 46F362260035; Fri, 11 Apr 2014 09:10:34 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1C6911F0813; Fri, 11 Apr 2014 09:10:34 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Fri, 11 Apr 2014 09:10:33 -0400
From: "Natale, Bob" 
To: Hannes Tschofenig 
Thread-Topic: [Ace] Authentication, Authorization and Key Distribution
Thread-Index: AQHPVRdaQLTtnkQcNki1aUDtvMz30psMYv9w
Date: Fri, 11 Apr 2014 13:10:33 +0000
Message-ID: 
References: <5346E0CB.3010906@gmx.net>
In-Reply-To: <5346E0CB.3010906@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.83.31.58]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/61zh4AusfO7MMnhCiNONCtjCwww
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Authentication, Authorization and Key Distribution
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, 11 Apr 2014 13:10:40 -0000

Hi Hannes,

Agreed ... and I would recommend also distinguishing between "Authorization=
" and "Access Control", using definitions similar to the ones below:

Authentication:	 The process of establishing confidence in the identity of =
users or information systems.=20

Authorization:  The processes of granting or denying the right to access sp=
ecific resources (systems, services, data, facilities, etc.). Authorization=
 grant/deny decisions are the purview of the business process and/or resour=
ce owner.

Access Control:  The process of granting or denying requests to access spec=
ific resources (systems, services, data, facilities, etc.). Access control =
evaluates entity authentication and authorization attributes, resource acce=
ss requirements, and relevant contextual information to make instance-speci=
fic grant/deny access decisions. In sum, access control enables authorized =
access and prevents unauthorized access.

Avanti,
BobN

-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 10, 2014 2:20 PM
To: ace@ietf.org
Subject: [Ace] Authentication, Authorization and Key Distribution

Hi all,

based on the recent discussion I believe it is useful to clarify the
relationship between authentication, authorization, and key
distribution/key establishment.

There are various sources of literature but there is nothing that is
universally accepted. Needless to say that this typically causes a lot
of confusion in every identity management conversation. I am re-using
terminology text from the "Handbook of Applied Cryptography" and from
"Who goes there? Authentication Through the Lens of Privacy".

In a simplistic view what we are trying to accomplish is to allow a
client to access a protected resource and he gets access granted when he
is authorized to do so.

Authorization is the process of deciding what an entity ought to be
allowed to do. Authorization is distinct from authentication (which
establishes what an individual "is" rather than what the individual "is
allowed."). Authorization policies determine how authorization decisions
are made. Authorization policies base decision making on a variety of
factors, including identifiers (such as names) and attributes.

Hence, authentication and authorization are separate steps but they are
obviously related to each other.

At this point the story becomes more complex.

Many deployments involve a centralized or trusted party, for either or
both initial system setup and on-line actions (i.e., involving real-time
participation). This party is referred to by a variety of names
depending on the role played, including: trusted third party, trusted
server, authentication server, key distribution center (KDC), key
translation center (KTC), and certification authority (CA).

So, we are not just talking about a two-party environment but about a
multi-party environment.

Earlier this year we discussed this topic on the ACE mailing list and we
said that we want to work with solutions that involve such a trusted
party (as I tried to explain in Section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00).

When you have a trusted third party you can use that party to develop a
more scalable way to manage authorization policies. Better management
comes with the price of having that additional party in the game.

Hence, instead of having the client to authenticate to the relying party
directly the exchange involves the trusted third party to which the
client is authenticated instead. To provide confidence to the relying
party that this step has indeed happened some information (in a
protected form) needs to be communicated from the trusted party to the
relying party (the resource server). This is where key establishment
comes into the picture.

Key establishment is a process or protocol whereby a shared secret
becomes  available to two or more parties, for subsequent cryptographic
use. Of course there are differences in the details depending on the use
of symmetric vs. asymmetric keys. (We don't want to go into any of these
details but if you look at Section 2 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 then you can
see how existing protocols have dealt with this issue.)

I hope that this clarification helps to convince you that it is a bit
difficult to capture this and the necessary background in the charter.

Ciao
Hannes


From nobody Mon Apr 14 01:56: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 681481A02D3 for ; Mon, 14 Apr 2014 01:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.878
X-Spam-Level: 
X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272] 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 kyt9_o-xyjGy for ; Mon, 14 Apr 2014 01:56:00 -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 95BE51A0106 for ; Mon, 14 Apr 2014 01:55:59 -0700 (PDT)
Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s3E8ifqF024098 for ; Mon, 14 Apr 2014 10:55:56 +0200
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1k59wue9tf-1 for ; Mon, 14 Apr 2014 10:55:56 +0200
Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 3DE6740116 for ; Mon, 14 Apr 2014 10:55:56 +0200 (CEST)
Message-ID: <534BA29B.703@sics.se>
Date: Mon, 14 Apr 2014 10:55:55 +0200
From: Ludwig Seitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: ace@ietf.org
References: <5346E0CB.3010906@gmx.net> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070603040107010801000001"
X-Proofpoint-Spam-Reason: safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-04-13_03:2014-04-11,2014-04-13,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/TaEUjQhETccVMIrvt1JTpFDOt6k
Subject: Re: [Ace] Authentication, Authorization and Key Distribution
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, 14 Apr 2014 08:56:04 -0000

This is a cryptographically signed message in MIME format.

--------------ms070603040107010801000001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/11/2014 03:10 PM, Natale, Bob wrote:
> Hi Hannes,
>
> Agreed ... and I would recommend also distinguishing between "Authoriza=
tion" and "Access Control", using definitions similar to the ones below:
>
> Authentication:	 The process of establishing confidence in the identity=
 of users or information systems.
>

We already had this discussion several times, and came to the conclusion =

that this is a far too restrictive definition of authentication. Have a=20
look at the mailing list archives. Short version: You can authenticate a =

lot of things besides identity.

> Authorization:  The processes of granting or denying the right to acces=
s specific resources (systems, services, data, facilities, etc.). Authori=
zation grant/deny decisions are the purview of the business process and/o=
r resource owner.
>
> Access Control:  The process of granting or denying requests to access =
specific resources (systems, services, data, facilities, etc.). Access co=
ntrol evaluates entity authentication and authorization attributes, resou=
rce access requirements, and relevant contextual information to make inst=
ance-specific grant/deny access decisions. In sum, access control enables=
 authorized access and prevents unauthorized access.
>

Trying to define the meaning and difference of 'authorization' and=20
'access control' is not something that this WG should attempt to do. I=20
think most of us can agree on the first sentence in both of your=20
definitions, and that's good enough for me.

/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


--------------ms070603040107010801000001
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
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MTQwODU1NTVaMCMGCSqGSIb3DQEJBDEW
BBRtSgpJFOdfSkLtzVDRf4SEAWGvBTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE
ggEAYE9cM6rkxV25sS42Sc9pwc9AD5a3uDbGUMMm/aONp8w+CvmTbStH81NBHTE6zhoc9Y13
Z4puA2XkdL6cV2k6BrMUsZb9I6vgAeB2NHBfC+6VdFzOAKV6IYCLG/7qZy+l9rezriym1Rf6
QaC6AgBG8WJHO1MjKoDcFELLcStSHljVktqVrY+gj6NNVGFTg5UOSZkY35gOz9Leo9uK+cg4
HEXMfRStmTQbBVujOkjmYCHFhbPXTiqNyDI+CZO/0o7U79BkkDO5rkkhUQgiFvrWGN2xDW6g
DayTm+J3jLj/4Hm3Mg5YvtVsbi3DBRK2xzHtQRvE5xXke8g0kvZGDoLU1wAAAAAAAA==
--------------ms070603040107010801000001--


From nobody Mon Apr 14 03:46: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 5E7851A02B2 for ; Mon, 14 Apr 2014 03:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.528
X-Spam-Level: 
X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 mymcnJQXYOSh for ; Mon, 14 Apr 2014 03:46:02 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D7EB51A0185 for ; Mon, 14 Apr 2014 03:46:01 -0700 (PDT)
Received: from [217.140.96.21] by 3capp-gmx-bs23 with HTTP; Mon, 14 Apr 2014 12:45:57 +0200
MIME-Version: 1.0
Message-ID: 
From: "Hannes Tschofenig" 
To: "ace@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Date: Mon, 14 Apr 2014 12:45:57 +0200
Importance: normal
Sensitivity: Normal
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-Provags-ID: V03:K0:eg/ggHG5VMjd0J26GZDoU+hkCwKOJk8jRIvJuaX+m5s 63hy7fhk9RggbOa3eLzNpZeFmhkiR9xSI5eUNox6gmcYXLPzjK afnWJo2XPGUIHWkcKghD5E9O4IIXmdZ/gUBDvuTt3ek6rVfgNL Os00PFXEakoBbRg6JtCJyXAalM2u78pj2F9LtjIlvyr4jk6NBv BELOw2EgDtt7XtVNfJerg+q2AYPus+GblDbJGYqGYZLknJOcUN Rd42qhC5JdXmDoLMgLF6wUkfbLY5a47qJtyiXu7zZN9KK6RYWZ ijBZxs=
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/MAiTJtT1iR3zuMUkR0V4mkqqrb8
Subject: [Ace] Concluding the Charter Discussions (?)
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, 14 Apr 2014 10:46:03 -0000

Hi all,=C2=A0
=C2=A0
in a recent mail I tried to highlight the complexity regarding authenticat=
ion, authorization, and key distribution:=C2=A0
http://www.ietf.org/mail-archive/web/ace/current/msg00518.html
=C2=A0
As Carsten, Rene,=C2=A0G=C3=B6ran, and Ludwig correctly noticed (a) there =
are details missing in my (already long) description and (b) this does not =
quite fit on the charter page.=C2=A0
=C2=A0
In fact, the purpose of my write-up was to point out that this is a too lo=
ng topic to cover on the charter page. An interested reader will have to go=
 beyond the content of the charter page and take a look at the documents of=
 the group.=C2=A0
=C2=A0
Having said that I was wondering whether we could omit a description from =
the charter page. I think we don't do the topic justice if we condense it d=
own to a single sentence.=C2=A0
=C2=A0
Ciao
Hannes

PS: I will still have to take the review comments from Rene into account; =
I will send a separate mail about it.=20


From nobody Mon Apr 14 04:00: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 AE8611A03D3 for ; Mon, 14 Apr 2014 04:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.528
X-Spam-Level: 
X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 k1fcFcwZZvV4 for ; Mon, 14 Apr 2014 04:00:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id AEDFE1A03C2 for ; Mon, 14 Apr 2014 04:00:37 -0700 (PDT)
Received: from [217.140.96.21] by 3capp-gmx-bs23 with HTTP; Mon, 14 Apr 2014 13:00:34 +0200
MIME-Version: 1.0
Message-ID: 
From: "Hannes Tschofenig" 
To: "ace@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Date: Mon, 14 Apr 2014 13:00:34 +0200
Importance: normal
Sensitivity: Normal
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-Provags-ID: V03:K0:mjZtQeBNqkNEeF2PTJ35R+1yIRZMYN9fgB3n+1sM284 51Oh7srEIXKZXJYjaM3Kzb5bcreSrxkRTwsvA1skGeDRzlxFU7 1OZTgPv/SHhwfcl6opfTFPn3r0saLXybYTzc9MyfJOwdbpneJg rjADeTYxhSjwkA51bF93cWyD21N6+ZC9/mQjBZEQVOnAKZQaLf AvV5XVFVoO6b94o6qMziKmKBUrqFqTtTNixZpVCOzUQx2/f4IW iPrEzTf4od6wFZHeJxvS4acU5L6TEeFFEaSk9W2lz8XyRes44I DtuMI8=
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/q1X3z275RgVMlC92d20XxwDqIEQ
Subject: [Ace] Identity
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, 14 Apr 2014 11:00:47 -0000

Since this issue came up as well in a mail exchange between Ludwig and Bob.=
=C2=A0
=C2=A0
Bob re-used authentication terminology from NIST SP 800-63
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf
=C2=A0
In the classical authentication literature the term authentication is ofte=
n tied to humans since there is a step in the process where you use identit=
y proofing of a person to link it to the credentials used in the electronic=
 system.
=C2=A0
This is quite useful for many identity systems but SP 800-63 is focused on=
 a subset of identity information (namely authentication information relate=
d to humans).=C2=A0RFC 6973=C2=A0defines the term identity as:=C2=A0
=C2=A0
   $ Identity:  Any subset of an individual's attributes, including
      names, that identifies the individual within a given context.
      Individuals usually have multiple identities for use in different
      contexts.

As you can see identity is a fairly broad concept and authentication relat=
ed information might only be a small piece of it.=C2=A0
=C2=A0
In the ACE work we are talking about a slightly different scope even thoug=
h humans also show up in the system since they own devices and play a role =
in authorization policies.=C2=A0
=C2=A0
I am suggesting to omit this description/discussion from the charter text =
since it would be somewhat confusing for a reader.=C2=A0
=C2=A0
Ciao
Hannes
=C2=A0


From nobody Mon Apr 14 05:25: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 F1D141A0402 for ; Mon, 14 Apr 2014 05:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.528
X-Spam-Level: 
X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 Mzi0LfNd7Ae6 for ; Mon, 14 Apr 2014 05:25:21 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id C52F01A01D4 for ; Mon, 14 Apr 2014 05:25:20 -0700 (PDT)
Received: from [217.140.96.21] by 3capp-gmx-bs42 with HTTP; Mon, 14 Apr 2014 14:25:16 +0200
MIME-Version: 1.0
Message-ID: 
From: "Hannes Tschofenig" 
To: "Rene Struik" 
Content-Type: text/plain; charset=UTF-8
Date: Mon, 14 Apr 2014 14:25:16 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <53471413.5070207@gmail.com>
References: <533CFC50.3090801@gmx.net>, <53471413.5070207@gmail.com>
Content-Transfer-Encoding: quoted-printable
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K0:/i/01sdGjpWbKGJgXhTJw3m8iiLCzSJqNPdfMe6Ozke W9hNi5+lO9zJ8s37Pakg/ZpPG8/huzaSpglH3ZNFxDJ+69d859 TUOg7AREmWKZXddnC2YldDrVJFZanXymbMNUp+5zna/VvZCNHX FcY2HpHzfS3FRtaCi8utgY+7QY4rMzO7e4hmivFCwPwBcbzsqD 2myxobKFY69qUENPGMXEaSOqyMjkghoYQr/mCEPp9XgOpU3y1t 15IM7htB5zy9PKUCjdaY8N/NYVCTeLidVme4C6KwmW0Z04WF+C TuoEvg=
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/WOAEKNv343sblC6V3tYbuV4paO0
Cc: Hannes Tschofenig , "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 14 Apr 2014 12:25:23 -0000

Hi Rene,=C2=A0
=C2=A0
thanks for the review comments. I have updated the charter text accordingl=
y.
=C2=A0
A few remarks inline:=C2=A0
=C2=A0

Gesendet:=C2=A0Donnerstag, 10. April 2014 um 22:58 Uhr
Von:=C2=A0"Rene Struik" 
An:=C2=A0"Hannes Tschofenig" , "ace@ietf.org" <=
ace@ietf.org>
Betreff:=C2=A0Re: [Ace] Last Call for Comments on ACE Charter Text

Hi Hannes:

I had a look at the charter text. I do agree with the two tasks identified=
 in the charter.

I do have some some comments on the (rather lengthy) prelude to the enumer=
ation of these two tasks. These comments do not matter if the group agrees =
that the charter does not try and steer into a particular solution directio=
n (as some comments on the list have indeed suggested to be the case). My c=
omments are worded in case this is not so.

Small comments:
a) 2nd para, l. 3: replace "authorization decisions" by "authorization cri=
teria" or "authorization policy". After all, decisions are not stored, but =
acted upon.
=C2=A0
[hannes] Fixed.
=C2=A0
b) 2nd para, l. -1: replace "resource server" by "resource owner", "resour=
ce holder", or similar. This would make it clearer that the "server" is the=
 device that actually stores the info the client is soliciting.

[hannes] I changed the wording to make clear that we are talking about the=
 server that is holding the resource.=20

c) 4th para, l.. -1: not sure what the exact context of "consent of the us=
er" is. Aren't we talking about device-to-device communications, where user=
 may only be involved with configuration decisions (and, perhaps, even only=
 remotely).

[hannes] I removed the consent part to avoid the need to talk about it. Ju=
st referring to user interface limitations of many of these IoT devices is =
sufficient. ;


d) 6th para, l. 4: replace "will be required" by "may be required".

[hannes] Fixed.=20

Main comments:
a) 3rd para: This whole para seems to presort solutions, by suggesting tha=
t one wishes to look at three-party protocols. Moreover, why would one care=
 whether IETF had a "tradition" to develop something (for a completely diff=
erent setting than constrained devices and networks)? The example protocols=
 are a disparate set, where Kerberos and AAA require inline third parties a=
nd, e.g., authenticated public-key based key agreement only uses a CA as of=
fline third party (or does the word "PKI" imply here OCSP, CRLs, etc, as we=
ll?). In all cases, it is not entirely clear whether these all serve to pro=
vide authentication and fine-grained authorization objectives. I would sugg=
est scrapping this whole para.

[hannes] With a recent charter text change the text does not talk about tr=
adition anymore. So, that concern is gone. Overall, the idea of the paragra=
ph is to highlight that there is some work the group will take a look at. O=
f course, the different approaches offer different properties. Which of tho=
se mechanisms is suitable depends heavily on the work on the use cases and =
the requirements; hence, it is a bit premature to dismiss some of them alre=
ady now.=20



b) 4th para: I would scrap any hint at suitability of solutions and go int=
o this effort with an open mind (i.e., scrap "suitability of existing work,=
 such as OAuth", etc.).

[hannes] I remoted the explicit mentioning of OAuth in the charter text.=
=20


c) 5th para: by stipulating that client and server are constrained, but au=
thorization server is not, one rules out any implementation where the autho=
rization server coincides with client or server. This seems imprudent, sinc=
e authorization decisions on client request by the server can be based on (=
1) locally maintained info (access control list style); (2) information inc=
luded with the client request message flow; (3) info obtained from a third-=
party helper device that assists the server with this decision. The way thi=
ngs are currently phrased seems to be steer this into direction #3. Again, =
please keep an open mind and do not pre-bake solution directions in the cha=
rter.
d) 6th para: I would not over-estimate the existing "deployment experience=
", nor "available security analysis" (there is quite some crypto and securi=
ty literature that IETF never tapped and some of the security properties of=
 widely used IETF protocols is being heavily disccussed/criticized on other=
 lists (tls list)). In my mind, referring to "IETF tradition" and "benefit =
of security analysis", etc., could therefore be somewhat dangerous.

[hannes] I am following the feedback from the group on the issue of the co=
nstrained nature of the authorization server not being constrained in the s=
ame way as the client or the resource server. If you have use cases where t=
he authorization server is co-located with the client and/or the resource s=
erver please bring them forward. Note that I believe nobody says anything a=
bout the potential caching of information at the client or the server-side.=
=20

Regarding the deployment experience and the security analysis: Of course, =
different persons have various preferences regarding the re-use of existing=
 technology. Some people may want to re-use their existing code, they want =
to integrate with existing deployments, they want to benefit from available=
 open source, re-use existing building blocks. There will be others who wan=
t to start from scratch. I believe that this issue will be resolved in the =
requirements discussion and in the work on the actual solutions.=20


e) 7th para: I would suggest scrapping the entire para, since much too amb=
itious (one can easily recharter to take on more work or refocus at a later=
 stage). This is especially so, since expertise with security, privacy, and=
 good understanding of usability (as alluded to in the 8th para) is in rath=
er short supply (one may of course disagree here).

[hannes] I deleted the first sentence since it did not constrain the work =
in any way. However, the second sentence does reflect the intention of the =
group with shaping the work: "This work does not make the assumption that t=
he party offering application layer services is always the same party offer=
ing network access services."=20
=C2=A0

Ciao
Hannes


From nobody Tue Apr 15 08:52: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 01EE71A049E for ; Tue, 15 Apr 2014 08:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 BqfWkdeEz7os for ; Tue, 15 Apr 2014 08:52:39 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan20.extendcp.co.uk [176.32.226.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24F1A0552 for ; Tue, 15 Apr 2014 08:52:31 -0700 (PDT)
Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Wa5es-0003Di-DQ; Tue, 15 Apr 2014 16:52:26 +0100
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 1Wa5es-0003Xk-9c; Tue, 15 Apr 2014 16:52:26 +0100
Received: from host86-168-9-99.range86-168.btcentralplus.com ([86.168.9.99] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Wa5er-00078a-Nx; Tue, 15 Apr 2014 16:52:26 +0100
Message-ID: <534D55F3.4040704@gridmerge.com>
Date: Tue, 15 Apr 2014 16:53:23 +0100
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: Hannes Tschofenig ,  Rene Struik 
References: <533CFC50.3090801@gmx.net>, <53471413.5070207@gmail.com> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080903010103090605050001"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/GEy4tuYp5KJyVOLW9QPGhlIoyVY
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 15 Apr 2014 15:52:44 -0000

This is a cryptographically signed message in MIME format.

--------------ms080903010103090605050001
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

A couple of small comments inline. I am OK with the rest of the changes.

Robert

On 14/04/2014 1:25 PM, Hannes Tschofenig wrote:
> Hi Rene,
>  =20
> thanks for the review comments. I have updated the charter text accordi=
ngly.
>  =20
> A few remarks inline:
>  =20
>
> Gesendet: Donnerstag, 10. April 2014 um 22:58 Uhr
> Von: "Rene Struik" 
> An: "Hannes Tschofenig" , "ace@ietf.org" 
> Betreff: Re: [Ace] Last Call for Comments on ACE Charter Text
>
> Hi Hannes:
>
> I had a look at the charter text. I do agree with the two tasks identif=
ied in the charter.
>
> I do have some some comments on the (rather lengthy) prelude to the enu=
meration of these two tasks. These comments do not matter if the group ag=
rees that the charter does not try and steer into a particular solution d=
irection (as some comments on the list have indeed suggested to be the ca=
se). My comments are worded in case this is not so.
>
> Small comments:
> a) 2nd para, l. 3: replace "authorization decisions" by "authorization =
criteria" or "authorization policy". After all, decisions are not stored,=
 but acted upon.
>  =20
> [hannes] Fixed.
I have no particular issue with the change but I think it was OK as =

it was, as an authorization *policy* can often be static, therefore not=20
requiring storage. Decisions certainly are stored and form the basis for =

access control.
>  =20
> b) 2nd para, l. -1: replace "resource server" by "resource owner", "res=
ource holder", or similar. This would make it clearer that the "server" i=
s the device that actually stores the info the client is soliciting.
>
> [hannes] I changed the wording to make clear that we are talking about =
the server that is holding the resource.
The way it is written now could read that clients can hold=20
resources - not the case in a REST architecture. Again, I thought it was =

OK as it way


--------------ms080903010103090605050001
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
Fw0xNDA0MTUxNTUzMjNaMCMGCSqGSIb3DQEJBDEWBBQpUvrpIBlzA7dS9+PQzw3VAW2xHzBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAHpC0PYHVNe6TLe6AtUb9HJFiHY3Kiq1TbAaXNbHz1SyRx2s
INTUl4kJB59ZbYqoVxApQMqK7oZ4VyBKqYFrDgUbB38kNGt7LcQTNfdO5A7N4BPKEGv/ehqp
LfPSkOwKmYyw4xKvGldmvj26+2+7FdpdmmG+PuaAph67+ShNVYuYmZ2tPsz+zq90blGFo4l5
UmfSuucJRbCGa3iQcWRuqnpUKTOeTq+r5LxbYP9MMhMo14rbjqYET/h1pFq2DE8diQJnRgak
55sSyOgloJF89y/XfYjSdAJuZB2L0pQ4VRZP/mLmVOVyWyIPC/4XXsXIjj9g10OAMV4nSkOO
YUEdkEAAAAAAAAA=
--------------ms080903010103090605050001--


From nobody Wed Apr 16 02:52: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 C6A951A004C for ; Wed, 16 Apr 2014 02:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.073
X-Spam-Level: 
X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 HygCjWUdniql for ; Wed, 16 Apr 2014 02:52:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 251371A0040 for ; Wed, 16 Apr 2014 02:52:01 -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 BFR81066; Wed, 16 Apr 2014 09:51:56 +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; Wed, 16 Apr 2014 10:50:34 +0100
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; Wed, 16 Apr 2014 10:51:55 +0100
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; Wed, 16 Apr 2014 17:51:49 +0800
From: Likepeng 
To: Hannes Tschofenig , "ace@ietf.org" 
Thread-Topic: [Ace] Identity
Thread-Index: AQHPV9DZ+FrE8ccdOECuhdCGPdg3A5sUAung
Date: Wed, 16 Apr 2014 09:51:49 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B200B9@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: 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/yWj3Yf3aAkO4uX90hQVTKpB1LUU
Subject: Re: [Ace] Identity
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, 16 Apr 2014 09:52:06 -0000

PiBJIGFtIHN1Z2dlc3RpbmcgdG8gb21pdCB0aGlzIGRlc2NyaXB0aW9uL2Rpc2N1c3Npb24gZnJv
bSB0aGUgY2hhcnRlciB0ZXh0IHNpbmNlDQo+IGl0IHdvdWxkIGJlIHNvbWV3aGF0IGNvbmZ1c2lu
ZyBmb3IgYSByZWFkZXIuDQoNCisxLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQo+IC0tLS0t
6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0Bp
ZXRmLm9yZ10g5Luj6KGoIEhhbm5lcyBUc2Nob2ZlbmlnDQo+IOWPkemAgeaXtumXtDogMjAxNOW5
tDTmnIgxNOaXpSAxOTowMQ0KPiDmlLbku7bkuro6IGFjZUBpZXRmLm9yZw0KPiDkuLvpopg6IFtB
Y2VdIElkZW50aXR5DQo+IA0KPiBTaW5jZSB0aGlzIGlzc3VlIGNhbWUgdXAgYXMgd2VsbCBpbiBh
IG1haWwgZXhjaGFuZ2UgYmV0d2VlbiBMdWR3aWcgYW5kIEJvYi4NCj4gDQo+IEJvYiByZS11c2Vk
IGF1dGhlbnRpY2F0aW9uIHRlcm1pbm9sb2d5IGZyb20gTklTVCBTUCA4MDAtNjMNCj4gaHR0cDov
L252bHB1YnMubmlzdC5nb3YvbmlzdHB1YnMvU3BlY2lhbFB1YmxpY2F0aW9ucy9OSVNULlNQLjgw
MC02My0yLnBkZg0KPiANCj4gSW4gdGhlIGNsYXNzaWNhbCBhdXRoZW50aWNhdGlvbiBsaXRlcmF0
dXJlIHRoZSB0ZXJtIGF1dGhlbnRpY2F0aW9uIGlzIG9mdGVuIHRpZWQNCj4gdG8gaHVtYW5zIHNp
bmNlIHRoZXJlIGlzIGEgc3RlcCBpbiB0aGUgcHJvY2VzcyB3aGVyZSB5b3UgdXNlIGlkZW50aXR5
IHByb29maW5nDQo+IG9mIGEgcGVyc29uIHRvIGxpbmsgaXQgdG8gdGhlIGNyZWRlbnRpYWxzIHVz
ZWQgaW4gdGhlIGVsZWN0cm9uaWMgc3lzdGVtLg0KPiANCj4gVGhpcyBpcyBxdWl0ZSB1c2VmdWwg
Zm9yIG1hbnkgaWRlbnRpdHkgc3lzdGVtcyBidXQgU1AgODAwLTYzIGlzIGZvY3VzZWQgb24gYQ0K
PiBzdWJzZXQgb2YgaWRlbnRpdHkgaW5mb3JtYXRpb24gKG5hbWVseSBhdXRoZW50aWNhdGlvbiBp
bmZvcm1hdGlvbiByZWxhdGVkIHRvDQo+IGh1bWFucykuwqBSRkMgNjk3M8KgZGVmaW5lcyB0aGUg
dGVybSBpZGVudGl0eSBhczoNCj4gDQo+ICAgICQgSWRlbnRpdHk6ICBBbnkgc3Vic2V0IG9mIGFu
IGluZGl2aWR1YWwncyBhdHRyaWJ1dGVzLCBpbmNsdWRpbmcNCj4gICAgICAgbmFtZXMsIHRoYXQg
aWRlbnRpZmllcyB0aGUgaW5kaXZpZHVhbCB3aXRoaW4gYSBnaXZlbiBjb250ZXh0Lg0KPiAgICAg
ICBJbmRpdmlkdWFscyB1c3VhbGx5IGhhdmUgbXVsdGlwbGUgaWRlbnRpdGllcyBmb3IgdXNlIGlu
IGRpZmZlcmVudA0KPiAgICAgICBjb250ZXh0cy4NCj4gDQo+IEFzIHlvdSBjYW4gc2VlIGlkZW50
aXR5IGlzIGEgZmFpcmx5IGJyb2FkIGNvbmNlcHQgYW5kIGF1dGhlbnRpY2F0aW9uIHJlbGF0ZWQN
Cj4gaW5mb3JtYXRpb24gbWlnaHQgb25seSBiZSBhIHNtYWxsIHBpZWNlIG9mIGl0Lg0KPiANCj4g
SW4gdGhlIEFDRSB3b3JrIHdlIGFyZSB0YWxraW5nIGFib3V0IGEgc2xpZ2h0bHkgZGlmZmVyZW50
IHNjb3BlIGV2ZW4gdGhvdWdoDQo+IGh1bWFucyBhbHNvIHNob3cgdXAgaW4gdGhlIHN5c3RlbSBz
aW5jZSB0aGV5IG93biBkZXZpY2VzIGFuZCBwbGF5IGEgcm9sZSBpbg0KPiBhdXRob3JpemF0aW9u
IHBvbGljaWVzLg0KPiANCj4gSSBhbSBzdWdnZXN0aW5nIHRvIG9taXQgdGhpcyBkZXNjcmlwdGlv
bi9kaXNjdXNzaW9uIGZyb20gdGhlIGNoYXJ0ZXIgdGV4dCBzaW5jZQ0KPiBpdCB3b3VsZCBiZSBz
b21ld2hhdCBjb25mdXNpbmcgZm9yIGEgcmVhZGVyLg0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCj4g
DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiBBY2UgbWFpbGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K


From nobody Wed Apr 16 02:54: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 95D941A0037 for ; Wed, 16 Apr 2014 02:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level: 
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 i9umVL3ULHiz for ; Wed, 16 Apr 2014 02:53:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA5321A0022 for ; Wed, 16 Apr 2014 02:53:57 -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 BDD93141; Wed, 16 Apr 2014 09:53:54 +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; Wed, 16 Apr 2014 10:51:55 +0100
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; Wed, 16 Apr 2014 10:53:30 +0100
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, 16 Apr 2014 17:53:25 +0800
From: Likepeng 
To: Hannes Tschofenig , "ace@ietf.org" 
Thread-Topic: [Ace] Concluding the Charter Discussions (?)
Thread-Index: AQHPV86+d0YDXo0MA0Sx5qVT3cw7yJsUA27A
Date: Wed, 16 Apr 2014 09:53:24 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B200C5@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: 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/UskViYPpLSkijkalp57Wdh71YpI
Subject: Re: [Ace] Concluding the Charter Discussions (?)
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, 16 Apr 2014 09:53:59 -0000

PiBIYXZpbmcgc2FpZCB0aGF0IEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHdlIGNvdWxkIG9taXQg
YSBkZXNjcmlwdGlvbiBmcm9tDQo+IHRoZSBjaGFydGVyIHBhZ2UuIEkgdGhpbmsgd2UgZG9uJ3Qg
ZG8gdGhlIHRvcGljIGp1c3RpY2UgaWYgd2UgY29uZGVuc2UgaXQgZG93bg0KPiB0byBhIHNpbmds
ZSBzZW50ZW5jZS4NCg0KQWdyZWUuDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3p
gq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGll
dGYub3JnXSDku6PooaggSGFubmVzIFRzY2hvZmVuaWcNCj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0
NOaciDE05pelIDE4OjQ2DQo+IOaUtuS7tuS6ujogYWNlQGlldGYub3JnDQo+IOS4u+mimDogW0Fj
ZV0gQ29uY2x1ZGluZyB0aGUgQ2hhcnRlciBEaXNjdXNzaW9ucyAoPykNCj4gDQo+IEhpIGFsbCwN
Cj4gDQo+IGluIGEgcmVjZW50IG1haWwgSSB0cmllZCB0byBoaWdobGlnaHQgdGhlIGNvbXBsZXhp
dHkgcmVnYXJkaW5nIGF1dGhlbnRpY2F0aW9uLA0KPiBhdXRob3JpemF0aW9uLCBhbmQga2V5IGRp
c3RyaWJ1dGlvbjoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9j
dXJyZW50L21zZzAwNTE4Lmh0bWwNCj4gDQo+IEFzIENhcnN0ZW4sIFJlbmUswqBHw7ZyYW4sIGFu
ZCBMdWR3aWcgY29ycmVjdGx5IG5vdGljZWQgKGEpIHRoZXJlIGFyZSBkZXRhaWxzDQo+IG1pc3Np
bmcgaW4gbXkgKGFscmVhZHkgbG9uZykgZGVzY3JpcHRpb24gYW5kIChiKSB0aGlzIGRvZXMgbm90
IHF1aXRlIGZpdCBvbiB0aGUNCj4gY2hhcnRlciBwYWdlLg0KPiANCj4gSW4gZmFjdCwgdGhlIHB1
cnBvc2Ugb2YgbXkgd3JpdGUtdXAgd2FzIHRvIHBvaW50IG91dCB0aGF0IHRoaXMgaXMgYSB0b28g
bG9uZw0KPiB0b3BpYyB0byBjb3ZlciBvbiB0aGUgY2hhcnRlciBwYWdlLiBBbiBpbnRlcmVzdGVk
IHJlYWRlciB3aWxsIGhhdmUgdG8gZ28NCj4gYmV5b25kIHRoZSBjb250ZW50IG9mIHRoZSBjaGFy
dGVyIHBhZ2UgYW5kIHRha2UgYSBsb29rIGF0IHRoZSBkb2N1bWVudHMgb2YNCj4gdGhlIGdyb3Vw
Lg0KPiANCj4gSGF2aW5nIHNhaWQgdGhhdCBJIHdhcyB3b25kZXJpbmcgd2hldGhlciB3ZSBjb3Vs
ZCBvbWl0IGEgZGVzY3JpcHRpb24gZnJvbQ0KPiB0aGUgY2hhcnRlciBwYWdlLiBJIHRoaW5rIHdl
IGRvbid0IGRvIHRoZSB0b3BpYyBqdXN0aWNlIGlmIHdlIGNvbmRlbnNlIGl0IGRvd24NCj4gdG8g
YSBzaW5nbGUgc2VudGVuY2UuDQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0KPiANCj4gUFM6IEkgd2ls
bCBzdGlsbCBoYXZlIHRvIHRha2UgdGhlIHJldmlldyBjb21tZW50cyBmcm9tIFJlbmUgaW50byBh
Y2NvdW50OyBJIHdpbGwNCj4gc2VuZCBhIHNlcGFyYXRlIG1haWwgYWJvdXQgaXQuDQo+IA0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBY2UgbWFp
bGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2FjZQ0K


From nobody Wed Apr 16 03:48: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 968531A0123 for ; Wed, 16 Apr 2014 03:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level: 
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 XcTVPcfOxY9y for ; Wed, 16 Apr 2014 03:48:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C25861A010B for ; Wed, 16 Apr 2014 03:48:21 -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 BFR87013; Wed, 16 Apr 2014 10:48:17 +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, 16 Apr 2014 11:46:39 +0100
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; Wed, 16 Apr 2014 11:48:14 +0100
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, 16 Apr 2014 18:48:12 +0800
From: Likepeng 
To: "robert.cragie@gridmerge.com" , "Hannes Tschofenig" , Rene Struik 
Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text
Thread-Index: AQHPTwe6QUxfO7RxWkK4iWtgneZXrZsK6+eAgAWpGwCAAcx7gIABttpg
Date: Wed, 16 Apr 2014 10:48:12 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B2012F@SZXEMA501-MBS.china.huawei.com>
References: <533CFC50.3090801@gmx.net>, <53471413.5070207@gmail.com>  <534D55F3.4040704@gridmerge.com>
In-Reply-To: <534D55F3.4040704@gridmerge.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/w4nVDrllCxd7oaBYsaRzbn6AgEQ
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 16 Apr 2014 10:48:24 -0000

PiA8UkNDPlRoZSB3YXkgaXQgaXMgd3JpdHRlbiBub3cgY291bGQgcmVhZCB0aGF0IGNsaWVudHMg
Y2FuIGhvbGQgcmVzb3VyY2VzIC0NCj4gbm90IHRoZSBjYXNlIGluIGEgUkVTVCBhcmNoaXRlY3R1
cmUuIEFnYWluLCBJIHRob3VnaHQgaXQgd2FzIE9LIGFzIGl0IHdheTwvUkNDPg0KDQpJIGhhdmUg
dGhlIHNhbWUgZmVlbGluZyBhcyBSb2JlcnQuIEZyb20gdGhlIHdvcmRpbmcsIGl0IHNlZW1zIHRo
YXQgdGhlIGNsaWVudHMgY2FuIGhvbGQgcmVzb3VyY2VzLg0KDQpJbiBmYWN0LCBpbiB0aGUgY2hh
cnRlciwgdGhlcmUgaXMgYW5vdGhlciBzZW50ZW5jZSB3aGljaCBjbGFyaWZpZXMgdGhlIHJlc291
cmNlcyBhcmUgc3RvcmVkIGF0IHJlc291cmNlIHNlcnZlcjoNCkFzIGEgc3RhcnRpbmcgcG9pbnQs
IHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYXNzdW1lIHRoYXQgYWNjZXNzIHRvIHJlc291cmNlcyBh
dCBhIHJlc291cmNlIHNlcnZlciBieSBhIGNsaWVudCBkZXZpY2UgdGFrZXMgcGxhY2UgdXNpbmcg
Q29BUCBhbmQgaXMgcHJvdGVjdGVkIGJ5IERUTFMuDQoNClNvIFJlbmUncyBjb25jZXJuIGNhbiBi
ZSBnb25lLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t
LS0NCj4g5Y+R5Lu25Lq6OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGo
IFJvYmVydCBDcmFnaWUNCj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0NOaciDE15pelIDIzOjUzDQo+
IOaUtuS7tuS6ujogSGFubmVzIFRzY2hvZmVuaWc7IFJlbmUgU3RydWlrDQo+IOaKhOmAgTogYWNl
QGlldGYub3JnDQo+IOS4u+mimDogUmU6IFtBY2VdIExhc3QgQ2FsbCBmb3IgQ29tbWVudHMgb24g
QUNFIENoYXJ0ZXIgVGV4dA0KPiANCj4gQSBjb3VwbGUgb2Ygc21hbGwgY29tbWVudHMgaW5saW5l
LiBJIGFtIE9LIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNoYW5nZXMuDQo+IA0KPiBSb2JlcnQNCj4g
DQo+IE9uIDE0LzA0LzIwMTQgMToyNSBQTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+ID4g
SGkgUmVuZSwNCj4gPg0KPiA+IHRoYW5rcyBmb3IgdGhlIHJldmlldyBjb21tZW50cy4gSSBoYXZl
IHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgdGV4dA0KPiBhY2NvcmRpbmdseS4NCj4gPg0KPiA+IEEgZmV3
IHJlbWFya3MgaW5saW5lOg0KPiA+DQo+ID4gYikgMm5kIHBhcmEsIGwuIC0xOiByZXBsYWNlICJy
ZXNvdXJjZSBzZXJ2ZXIiIGJ5ICJyZXNvdXJjZSBvd25lciIsICJyZXNvdXJjZQ0KPiBob2xkZXIi
LCBvciBzaW1pbGFyLiBUaGlzIHdvdWxkIG1ha2UgaXQgY2xlYXJlciB0aGF0IHRoZSAic2VydmVy
IiBpcyB0aGUgZGV2aWNlDQo+IHRoYXQgYWN0dWFsbHkgc3RvcmVzIHRoZSBpbmZvIHRoZSBjbGll
bnQgaXMgc29saWNpdGluZy4NCj4gPg0KPiA+IFtoYW5uZXNdIEkgY2hhbmdlZCB0aGUgd29yZGlu
ZyB0byBtYWtlIGNsZWFyIHRoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlDQo+IHNlcnZlciB0
aGF0IGlzIGhvbGRpbmcgdGhlIHJlc291cmNlLg0KPiA8UkNDPlRoZSB3YXkgaXQgaXMgd3JpdHRl
biBub3cgY291bGQgcmVhZCB0aGF0IGNsaWVudHMgY2FuIGhvbGQgcmVzb3VyY2VzIC0NCj4gbm90
IHRoZSBjYXNlIGluIGEgUkVTVCBhcmNoaXRlY3R1cmUuIEFnYWluLCBJIHRob3VnaHQgaXQgd2Fz
IE9LIGFzIGl0IHdheTwvUkNDPg0KDQo=


From nobody Wed Apr 16 03:58: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 CAE8C1A0133 for ; Wed, 16 Apr 2014 03:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level: 
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 cXUzHXt6hhVL for ; Wed, 16 Apr 2014 03:58:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0BF1A012C for ; Wed, 16 Apr 2014 03:58:35 -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 BFR88041; Wed, 16 Apr 2014 10:58:31 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Apr 2014 11:57:05 +0100
Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Apr 2014 11:58:26 +0100
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, 16 Apr 2014 18:58:24 +0800
From: Likepeng 
To: "robert.cragie@gridmerge.com" , "Hannes Tschofenig" , Rene Struik 
Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text
Thread-Index: AQHPTwe6QUxfO7RxWkK4iWtgneZXrZsK6+eAgAWpGwCAAcx7gIABxQig
Date: Wed, 16 Apr 2014 10:58:24 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B2013D@SZXEMA501-MBS.china.huawei.com>
References: <533CFC50.3090801@gmx.net>, <53471413.5070207@gmail.com>  <534D55F3.4040704@gridmerge.com>
In-Reply-To: <534D55F3.4040704@gridmerge.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/axkhr9NFkGs6hR9OI7NNDei4y3k
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 16 Apr 2014 10:58:38 -0000

PiA+IGEpIDJuZCBwYXJhLCBsLiAzOiByZXBsYWNlICJhdXRob3JpemF0aW9uIGRlY2lzaW9ucyIg
YnkgImF1dGhvcml6YXRpb24gY3JpdGVyaWEiIG9yICJhdXRob3JpemF0aW9uIHBvbGljeSIuIEFm
dGVyIGFsbCwgZGVjaXNpb25zIGFyZSBub3Qgc3RvcmVkLCBidXQgYWN0ZWQgdXBvbi4NCg0KPiA8
UkNDPkkgaGF2ZSBubyBwYXJ0aWN1bGFyIGlzc3VlIHdpdGggdGhlIGNoYW5nZSBidXQgSSB0aGlu
ayBpdCB3YXMgT0sgYXMgaXQgd2FzLCBhcyBhbiBhdXRob3JpemF0aW9uICpwb2xpY3kqIGNhbiBv
ZnRlbiBiZSBzdGF0aWMsIHRoZXJlZm9yZSBub3QgcmVxdWlyaW5nIHN0b3JhZ2UuIERlY2lzaW9u
cyBjZXJ0YWlubHkgYXJlIHN0b3JlZCBhbmQgZm9ybSB0aGUgYmFzaXMgZm9yIGFjY2VzcyBjb250
cm9sLjwvUkNDPg0KDQpGb3IgdGhpcyBvbmUsIEkgdGVuZCB0byBhZ3JlZSB3aXRoIFJlbmUuIERl
Y2lzaW9ucyBhcmUgbm90IHN0b3JlZCwgYnV0IGFjdGVkIHVwb24uIEZvciBleGFtcGxlLCBpZiB0
aGUgZGVjaXNpb24gaXMgInllcyIsIG9wZW4gdGhlIGRvb3IuIFRoZXJlIGlzIG5vIG5lZWQgdG8g
c3RvcmUgdGhlICJ5ZXMiLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQo+IC0tLS0t6YKu5Lu2
5Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9y
Z10g5Luj6KGoIFJvYmVydCBDcmFnaWUNCj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0NOaciDE15pel
IDIzOjUzDQo+IOaUtuS7tuS6ujogSGFubmVzIFRzY2hvZmVuaWc7IFJlbmUgU3RydWlrDQo+IOaK
hOmAgTogYWNlQGlldGYub3JnDQo+IOS4u+mimDogUmU6IFtBY2VdIExhc3QgQ2FsbCBmb3IgQ29t
bWVudHMgb24gQUNFIENoYXJ0ZXIgVGV4dA0KPiANCj4gQSBjb3VwbGUgb2Ygc21hbGwgY29tbWVu
dHMgaW5saW5lLiBJIGFtIE9LIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNoYW5nZXMuDQo+IA0KPiBS
b2JlcnQNCj4gDQo+IE9uIDE0LzA0LzIwMTQgMToyNSBQTSwgSGFubmVzIFRzY2hvZmVuaWcgd3Jv
dGU6DQo+ID4gSGkgUmVuZSwNCj4gPg0KPiA+IHRoYW5rcyBmb3IgdGhlIHJldmlldyBjb21tZW50
cy4gSSBoYXZlIHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgdGV4dA0KPiBhY2NvcmRpbmdseS4NCj4gPg0K
PiA+IEEgZmV3IHJlbWFya3MgaW5saW5lOg0KPiA+DQo+ID4NCj4gPiBHZXNlbmRldDogRG9ubmVy
c3RhZywgMTAuIEFwcmlsIDIwMTQgdW0gMjI6NTggVWhyDQo+ID4gVm9uOiAiUmVuZSBTdHJ1aWsi
IDxyc3RydWlrLmV4dEBnbWFpbC5jb20+DQo+ID4gQW46ICJIYW5uZXMgVHNjaG9mZW5pZyIgPGhh
bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+LCAiYWNlQGlldGYub3JnIg0KPiA+IDxhY2VAaWV0Zi5v
cmc+DQo+ID4gQmV0cmVmZjogUmU6IFtBY2VdIExhc3QgQ2FsbCBmb3IgQ29tbWVudHMgb24gQUNF
IENoYXJ0ZXIgVGV4dA0KPiA+DQo+ID4gSGkgSGFubmVzOg0KPiA+DQo+ID4gSSBoYWQgYSBsb29r
IGF0IHRoZSBjaGFydGVyIHRleHQuIEkgZG8gYWdyZWUgd2l0aCB0aGUgdHdvIHRhc2tzIGlkZW50
aWZpZWQgaW4gdGhlDQo+IGNoYXJ0ZXIuDQo+ID4NCj4gPiBJIGRvIGhhdmUgc29tZSBzb21lIGNv
bW1lbnRzIG9uIHRoZSAocmF0aGVyIGxlbmd0aHkpIHByZWx1ZGUgdG8gdGhlDQo+IGVudW1lcmF0
aW9uIG9mIHRoZXNlIHR3byB0YXNrcy4gVGhlc2UgY29tbWVudHMgZG8gbm90IG1hdHRlciBpZiB0
aGUgZ3JvdXANCj4gYWdyZWVzIHRoYXQgdGhlIGNoYXJ0ZXIgZG9lcyBub3QgdHJ5IGFuZCBzdGVl
ciBpbnRvIGEgcGFydGljdWxhciBzb2x1dGlvbg0KPiBkaXJlY3Rpb24gKGFzIHNvbWUgY29tbWVu
dHMgb24gdGhlIGxpc3QgaGF2ZSBpbmRlZWQgc3VnZ2VzdGVkIHRvIGJlIHRoZSBjYXNlKS4NCj4g
TXkgY29tbWVudHMgYXJlIHdvcmRlZCBpbiBjYXNlIHRoaXMgaXMgbm90IHNvLg0KPiA+DQo+ID4g
U21hbGwgY29tbWVudHM6DQo+ID4gYSkgMm5kIHBhcmEsIGwuIDM6IHJlcGxhY2UgImF1dGhvcml6
YXRpb24gZGVjaXNpb25zIiBieSAiYXV0aG9yaXphdGlvbiBjcml0ZXJpYSINCj4gb3IgImF1dGhv
cml6YXRpb24gcG9saWN5Ii4gQWZ0ZXIgYWxsLCBkZWNpc2lvbnMgYXJlIG5vdCBzdG9yZWQsIGJ1
dCBhY3RlZCB1cG9uLg0KPiA+DQo+ID4gW2hhbm5lc10gRml4ZWQuDQo+IDxSQ0M+SSBoYXZlIG5v
IHBhcnRpY3VsYXIgaXNzdWUgd2l0aCB0aGUgY2hhbmdlIGJ1dCBJIHRoaW5rIGl0IHdhcyBPSyBh
cyBpdCB3YXMsDQo+IGFzIGFuIGF1dGhvcml6YXRpb24gKnBvbGljeSogY2FuIG9mdGVuIGJlIHN0
YXRpYywgdGhlcmVmb3JlIG5vdCByZXF1aXJpbmcNCj4gc3RvcmFnZS4gRGVjaXNpb25zIGNlcnRh
aW5seSBhcmUgc3RvcmVkIGFuZCBmb3JtIHRoZSBiYXNpcyBmb3IgYWNjZXNzDQo+IGNvbnRyb2wu
PC9SQ0M+DQo+ID4NCj4gPiBiKSAybmQgcGFyYSwgbC4gLTE6IHJlcGxhY2UgInJlc291cmNlIHNl
cnZlciIgYnkgInJlc291cmNlIG93bmVyIiwgInJlc291cmNlDQo+IGhvbGRlciIsIG9yIHNpbWls
YXIuIFRoaXMgd291bGQgbWFrZSBpdCBjbGVhcmVyIHRoYXQgdGhlICJzZXJ2ZXIiIGlzIHRoZSBk
ZXZpY2UNCj4gdGhhdCBhY3R1YWxseSBzdG9yZXMgdGhlIGluZm8gdGhlIGNsaWVudCBpcyBzb2xp
Y2l0aW5nLg0KPiA+DQo+ID4gW2hhbm5lc10gSSBjaGFuZ2VkIHRoZSB3b3JkaW5nIHRvIG1ha2Ug
Y2xlYXIgdGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUNCj4gc2VydmVyIHRoYXQgaXMgaG9s
ZGluZyB0aGUgcmVzb3VyY2UuDQo+IDxSQ0M+VGhlIHdheSBpdCBpcyB3cml0dGVuIG5vdyBjb3Vs
ZCByZWFkIHRoYXQgY2xpZW50cyBjYW4gaG9sZCByZXNvdXJjZXMgLQ0KPiBub3QgdGhlIGNhc2Ug
aW4gYSBSRVNUIGFyY2hpdGVjdHVyZS4gQWdhaW4sIEkgdGhvdWdodCBpdCB3YXMgT0sgYXMgaXQg
d2F5PC9SQ0M+DQoNCg==


From nobody Wed Apr 16 04: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 DE4AE1A012A for ; Wed, 16 Apr 2014 04:40:32 -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 KWF6evmI2dNd for ; Wed, 16 Apr 2014 04:40:30 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.21]) by ietfa.amsl.com (Postfix) with ESMTP id 20D821A010B for ; Wed, 16 Apr 2014 04:40:29 -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 1WaOCV-00062B-R3; Wed, 16 Apr 2014 12:40:23 +0100
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 1WaOCV-0001J6-Jc; Wed, 16 Apr 2014 12:40:23 +0100
Received: from host86-168-9-99.range86-168.btcentralplus.com ([86.168.9.99] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WaOCR-0006rY-QJ; Wed, 16 Apr 2014 12:40:20 +0100
Message-ID: <534E6C5D.6050506@gridmerge.com>
Date: Wed, 16 Apr 2014 12:41:17 +0100
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: Likepeng ,  Hannes Tschofenig , Rene Struik 
References: <533CFC50.3090801@gmx.net>, <53471413.5070207@gmail.com>  <534D55F3.4040704@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2013D@SZXEMA501-MBS.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B2013D@SZXEMA501-MBS.china.huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080301030009000900010401"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/lWSjLjDTolNl-r4ykUk9aTCtG8E
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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: Wed, 16 Apr 2014 11:40:33 -0000

This is a cryptographically signed message in MIME format.

--------------ms080301030009000900010401
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

OK - I have no problem with the change. No further comments.

Robert

On 16/04/2014 11:58 AM, Likepeng wrote:
>>> a) 2nd para, l. 3: replace "authorization decisions" by "authorizatio=
n criteria" or "authorization policy". After all, decisions are not store=
d, but acted upon.
>> I have no particular issue with the change but I think it was OK =
as it was, as an authorization *policy* can often be static, therefore no=
t requiring storage. Decisions certainly are stored and form the basis fo=
r access control.
> For this one, I tend to agree with Rene. Decisions are not stored, but =
acted upon. For example, if the decision is "yes", open the door. There i=
s no need to store the "yes".
>
> 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 Robert Cragie
>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B44=E6=9C=8815=E6=97=A5=
 23:53
>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Hannes Tschofenig; Rene Struik
>> =E6=8A=84=E9=80=81: ace@ietf.org
>> =E4=B8=BB=E9=A2=98: Re: [Ace] Last Call for Comments on ACE Charter Te=
xt
>>
>> A couple of small comments inline. I am OK with the rest of the change=
s.
>>
>> Robert
>>
>> On 14/04/2014 1:25 PM, Hannes Tschofenig wrote:
>>> Hi Rene,
>>>
>>> thanks for the review comments. I have updated the charter text
>> accordingly.
>>> A few remarks inline:
>>>
>>>
>>> Gesendet: Donnerstag, 10. April 2014 um 22:58 Uhr
>>> Von: "Rene Struik" 
>>> An: "Hannes Tschofenig" , "ace@ietf.org"
>>> 
>>> Betreff: Re: [Ace] Last Call for Comments on ACE Charter Text
>>>
>>> Hi Hannes:
>>>
>>> I had a look at the charter text. I do agree with the two tasks ident=
ified in the
>> charter.
>>> I do have some some comments on the (rather lengthy) prelude to the
>> enumeration of these two tasks. These comments do not matter if the gr=
oup
>> agrees that the charter does not try and steer into a particular solut=
ion
>> direction (as some comments on the list have indeed suggested to be th=
e case).
>> My comments are worded in case this is not so.
>>> Small comments:
>>> a) 2nd para, l. 3: replace "authorization decisions" by "authorizatio=
n criteria"
>> or "authorization policy". After all, decisions are not stored, but ac=
ted upon.
>>> [hannes] Fixed.
>> I have no particular issue with the change but I think it was OK =
as it was,
>> as an authorization *policy* can often be static, therefore not requir=
ing
>> storage. Decisions certainly are stored and form the basis for access
>> control.
>>> b) 2nd para, l. -1: replace "resource server" by "resource owner", "r=
esource
>> holder", or similar. This would make it clearer that the "server" is t=
he device
>> that actually stores the info the client is soliciting.
>>> [hannes] I changed the wording to make clear that we are talking abou=
t the
>> server that is holding the resource.
>> The way it is written now could read that clients can hold resour=
ces -
>> not the case in a REST architecture. Again, I thought it was OK as it =
way
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace



--------------ms080301030009000900010401
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
Fw0xNDA0MTYxMTQxMTdaMCMGCSqGSIb3DQEJBDEWBBS/Ky6F1i/YOlZH56B3aQT4CwWtQjBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBACOm6/CUhv/RA+ZmK39MWuSgx3TY7ls0kmYuNB0hJf/gTHEw
il9FtUKVbtKT+p82OI56Ue43RuSEyEpS12QYT3gxoY1winqTqejkXprm7Ct0hGkrmWahoFDP
M5puJWw13ygX0bfnDqwlVHVpXTaPJlMTY/MfJR5RugJ0e5217f3QzKC5P2qAZu7WS+oTE6LU
yyhPoZ+Yx6YpHGVgieyG1tV0yNbfIOQrEcEkOHK47CNBQYKYa3RXjgnE79rH4p5+Q7OSaAI2
K+D0r1BPPaLsS2CkJX84Q8+dMYKPUp0ZnkTj/ZOnQlBHhM0O+5eGstKDTvZNrWWaiwZ3d/Eb
ei2d69sAAAAAAAA=
--------------ms080301030009000900010401--


From nobody Mon Apr 21 01:46: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 3EF5F1A01BD for ; Mon, 21 Apr 2014 01:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level: 
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 I8oSiZuKpNuC for ; Mon, 21 Apr 2014 01:46:43 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF6731A01C4 for ; Mon, 21 Apr 2014 01:46:40 -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 BFW82941; Mon, 21 Apr 2014 08:46:35 +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, 21 Apr 2014 09:46:00 +0100
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; Mon, 21 Apr 2014 09:46:34 +0100
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; Mon, 21 Apr 2014 16:46:22 +0800
From: Likepeng 
To: Likepeng , "robert.cragie@gridmerge.com" , Hannes Tschofenig , Rene Struik 
Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text
Thread-Index: AQHPTwe6QUxfO7RxWkK4iWtgneZXrZsK6+eAgAWpGwCAAcx7gIABttpggAfD/BA=
Date: Mon, 21 Apr 2014 08:46:21 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B222DA@SZXEMA501-MBS.china.huawei.com>
References: <533CFC50.3090801@gmx.net>, <53471413.5070207@gmail.com>  <534D55F3.4040704@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2012F@SZXEMA501-MBS.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B2012F@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: 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/0g_y0yvHwAj4EZF6EbMySc-Osqs
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 21 Apr 2014 08:46:47 -0000

UmVjZWl2aW5nIG5vIG90aGVyIGZlZWRiYWNrLCBJIG1hZGUgdGhlIGNoYW5nZSB0byB0aGUgY2hh
cnRlci4NCg0KT0xEOg0Kd2hlcmUgY2xpZW50cyBhbmQvb3Igc2VydmVycyBob2xkaW5nIHJlc291
cmNlcyBhcmUgY29uc3RyYWluZWQuDQoNCk5FVzoNCndoZXJlIGNsaWVudHMgYW5kL29yIHJlc291
cmNlIHNlcnZlcnMgYXJlIGNvbnN0cmFpbmVkLg0KDQpOb3cgaXQgaXMgdjAuOWMsIHF1aXRlIGNs
b3NlIHRvIDEuMC4gOi0pDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9jb3JlL3RyYWMv
d2lraS9BQ0VfY2hhcnRlciMNCg0KUGxlYXNlIHRha2UgYSBmaW5hbCBjaGVjayB0byBzZWUgaWYg
eW91ciBjb21tZW50cyBoYXZlIGJlZW4gcmVzb2x2ZWQgaW4gdGhpcyB2ZXJzaW9uLg0KDQpUaGFu
a3MsDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K
PiDlj5Hku7bkuro6IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTGlr
ZXBlbmcNCj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0NOaciDE25pelIDE4OjQ4DQo+IOaUtuS7tuS6
ujogcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tOyBIYW5uZXMgVHNjaG9mZW5pZzsgUmVuZSBT
dHJ1aWsNCj4g5oqE6YCBOiBhY2VAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW0FjZV0gTGFzdCBD
YWxsIGZvciBDb21tZW50cyBvbiBBQ0UgQ2hhcnRlciBUZXh0DQo+IA0KPiA+IDxSQ0M+VGhlIHdh
eSBpdCBpcyB3cml0dGVuIG5vdyBjb3VsZCByZWFkIHRoYXQgY2xpZW50cyBjYW4gaG9sZA0KPiA+
IHJlc291cmNlcyAtIG5vdCB0aGUgY2FzZSBpbiBhIFJFU1QgYXJjaGl0ZWN0dXJlLiBBZ2Fpbiwg
SSB0aG91Z2h0IGl0DQo+ID4gd2FzIE9LIGFzIGl0IHdheTwvUkNDPg0KPiANCj4gSSBoYXZlIHRo
ZSBzYW1lIGZlZWxpbmcgYXMgUm9iZXJ0LiBGcm9tIHRoZSB3b3JkaW5nLCBpdCBzZWVtcyB0aGF0
IHRoZSBjbGllbnRzDQo+IGNhbiBob2xkIHJlc291cmNlcy4NCj4gDQo+IEluIGZhY3QsIGluIHRo
ZSBjaGFydGVyLCB0aGVyZSBpcyBhbm90aGVyIHNlbnRlbmNlIHdoaWNoIGNsYXJpZmllcyB0aGUg
cmVzb3VyY2VzDQo+IGFyZSBzdG9yZWQgYXQgcmVzb3VyY2Ugc2VydmVyOg0KPiBBcyBhIHN0YXJ0
aW5nIHBvaW50LCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFzc3VtZSB0aGF0IGFjY2VzcyB0byBy
ZXNvdXJjZXMgYXQNCj4gYSByZXNvdXJjZSBzZXJ2ZXIgYnkgYSBjbGllbnQgZGV2aWNlIHRha2Vz
IHBsYWNlIHVzaW5nIENvQVAgYW5kIGlzIHByb3RlY3RlZCBieQ0KPiBEVExTLg0KPiANCj4gU28g
UmVuZSdzIGNvbmNlcm4gY2FuIGJlIGdvbmUuDQo+IA0KPiBLaW5kIFJlZ2FyZHMNCj4gS2VwZW5n
DQo+IA0KPiA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPiDlj5Hku7bkuro6IEFjZSBbbWFp
bHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9iZXJ0IENyYWdpZQ0KPiA+IOWPkemA
geaXtumXtDogMjAxNOW5tDTmnIgxNeaXpSAyMzo1Mw0KPiA+IOaUtuS7tuS6ujogSGFubmVzIFRz
Y2hvZmVuaWc7IFJlbmUgU3RydWlrDQo+ID4g5oqE6YCBOiBhY2VAaWV0Zi5vcmcNCj4gPiDkuLvp
opg6IFJlOiBbQWNlXSBMYXN0IENhbGwgZm9yIENvbW1lbnRzIG9uIEFDRSBDaGFydGVyIFRleHQN
Cj4gPg0KPiA+IEEgY291cGxlIG9mIHNtYWxsIGNvbW1lbnRzIGlubGluZS4gSSBhbSBPSyB3aXRo
IHRoZSByZXN0IG9mIHRoZSBjaGFuZ2VzLg0KPiA+DQo+ID4gUm9iZXJ0DQo+ID4NCj4gPiBPbiAx
NC8wNC8yMDE0IDE6MjUgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KPiA+ID4gSGkgUmVu
ZSwNCj4gPiA+DQo+ID4gPiB0aGFua3MgZm9yIHRoZSByZXZpZXcgY29tbWVudHMuIEkgaGF2ZSB1
cGRhdGVkIHRoZSBjaGFydGVyIHRleHQNCj4gPiBhY2NvcmRpbmdseS4NCj4gPiA+DQo+ID4gPiBB
IGZldyByZW1hcmtzIGlubGluZToNCj4gPiA+DQo+ID4gPiBiKSAybmQgcGFyYSwgbC4gLTE6IHJl
cGxhY2UgInJlc291cmNlIHNlcnZlciIgYnkgInJlc291cmNlIG93bmVyIiwNCj4gPiA+ICJyZXNv
dXJjZQ0KPiA+IGhvbGRlciIsIG9yIHNpbWlsYXIuIFRoaXMgd291bGQgbWFrZSBpdCBjbGVhcmVy
IHRoYXQgdGhlICJzZXJ2ZXIiIGlzDQo+ID4gdGhlIGRldmljZSB0aGF0IGFjdHVhbGx5IHN0b3Jl
cyB0aGUgaW5mbyB0aGUgY2xpZW50IGlzIHNvbGljaXRpbmcuDQo+ID4gPg0KPiA+ID4gW2hhbm5l
c10gSSBjaGFuZ2VkIHRoZSB3b3JkaW5nIHRvIG1ha2UgY2xlYXIgdGhhdCB3ZSBhcmUgdGFsa2lu
Zw0KPiA+ID4gYWJvdXQgdGhlDQo+ID4gc2VydmVyIHRoYXQgaXMgaG9sZGluZyB0aGUgcmVzb3Vy
Y2UuDQo+ID4gPFJDQz5UaGUgd2F5IGl0IGlzIHdyaXR0ZW4gbm93IGNvdWxkIHJlYWQgdGhhdCBj
bGllbnRzIGNhbiBob2xkDQo+ID4gcmVzb3VyY2VzIC0gbm90IHRoZSBjYXNlIGluIGEgUkVTVCBh
cmNoaXRlY3R1cmUuIEFnYWluLCBJIHRob3VnaHQgaXQNCj4gPiB3YXMgT0sgYXMgaXQgd2F5PC9S
Q0M+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiBBY2UgbWFpbGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K


From nobody Tue Apr 22 01:31: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 5760F1A0143 for ; Tue, 22 Apr 2014 01:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Level: 
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 uxrVthN_FlZm for ; Tue, 22 Apr 2014 01:31:33 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E9CBE1A0087 for ; Tue, 22 Apr 2014 01:31:32 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MXIGf-1WOY8K3oqj-00WBDe; Tue, 22 Apr 2014 10:31:22 +0200
Message-ID: <53562865.9080508@gmx.net>
Date: Tue, 22 Apr 2014 10:29:25 +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: Likepeng ,  "robert.cragie@gridmerge.com" , Rene Struik 
References: <533CFC50.3090801@gmx.net>, <53471413.5070207@gmail.com>  <534D55F3.4040704@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2012F@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B222DA@SZXEMA501-MBS.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B222DA@SZXEMA501-MBS.china.huawei.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WOv6NfrIX4tOeMoJss774qocMq8c1RSx1"
X-Provags-ID: V03:K0:A6mxtIzPtaJbYLNPaLRQrIuTCo2QiGpGavMkU+UOMbeBLqVBX8Y mPU6ePr1925FsyEYEuyc9XwFna2CNzhGLnWRCMYojCX9M691WjgQaTw6VMKH47C19BJH1oh 2HYV8qIcRxQ6jM2wrHDRt2ABo1qJ4DKZe9QdAm6rU0zdQU2KnUfTdgYREHyVjfCTu5Kha81 34AkwAGU4yWCe3Ca4AGDg==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/EU9yqrnFdmKoB_7voytug3cMhFE
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 22 Apr 2014 08:31:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--WOv6NfrIX4tOeMoJss774qocMq8c1RSx1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good for me, Kepeng!

On 04/21/2014 10:46 AM, Likepeng wrote:
> Receiving no other feedback, I made the change to the charter.
>=20
> OLD:
> where clients and/or servers holding resources are constrained.
>=20
> NEW:
> where clients and/or resource servers are constrained.
>=20
> Now it is v0.9c, quite close to 1.0. :-)
> http://trac.tools.ietf.org/wg/core/trac/wiki/ACE_charter#
>=20
> Please take a final check to see if your comments have been resolved in=
 this version.
>=20
> Thanks,
>=20
> Kind Regards
> Kepeng
>=20
>> -----=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 Likepeng
>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B44=E6=9C=8816=E6=97=A5=
 18:48
>> =E6=94=B6=E4=BB=B6=E4=BA=BA: robert.cragie@gridmerge.com; Hannes Tscho=
fenig; Rene Struik
>> =E6=8A=84=E9=80=81: ace@ietf.org
>> =E4=B8=BB=E9=A2=98: Re: [Ace] Last Call for Comments on ACE Charter Te=
xt
>>
>>> The way it is written now could read that clients can hold
>>> resources - not the case in a REST architecture. Again, I thought it
>>> was OK as it way
>>
>> I have the same feeling as Robert. From the wording, it seems that the=
 clients
>> can hold resources.
>>
>> In fact, in the charter, there is another sentence which clarifies the=
 resources
>> are stored at resource server:
>> As a starting point, the working group will assume that access to reso=
urces at
>> a resource server by a client device takes place using CoAP and is pro=
tected by
>> DTLS.
>>
>> So Rene's concern can be gone.
>>
>> 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 Robert Cragie
>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B44=E6=9C=8815=E6=97=
=A5 23:53
>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Hannes Tschofenig; Rene Struik
>>> =E6=8A=84=E9=80=81: ace@ietf.org
>>> =E4=B8=BB=E9=A2=98: Re: [Ace] Last Call for Comments on ACE Charter T=
ext
>>>
>>> A couple of small comments inline. I am OK with the rest of the chang=
es.
>>>
>>> Robert
>>>
>>> On 14/04/2014 1:25 PM, Hannes Tschofenig wrote:
>>>> Hi Rene,
>>>>
>>>> thanks for the review comments. I have updated the charter text
>>> accordingly.
>>>>
>>>> A few remarks inline:
>>>>
>>>> b) 2nd para, l. -1: replace "resource server" by "resource owner",
>>>> "resource
>>> holder", or similar. This would make it clearer that the "server" is
>>> the device that actually stores the info the client is soliciting.
>>>>
>>>> [hannes] I changed the wording to make clear that we are talking
>>>> about the
>>> server that is holding the resource.
>>> The way it is written now could read that clients can hold
>>> resources - not the case in a REST architecture. Again, I thought it
>>> was OK as it way
>>
>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace


--WOv6NfrIX4tOeMoJss774qocMq8c1RSx1
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/

iQEcBAEBCgAGBQJTVihlAAoJEGhJURNOOiAtT1gIAI3QkIrVzb/H8VP6RtXyhQTk
mJI6BMgduEB6/to/qYxLXULIcA3hDW/XAA+ZBp4E2vwD7Edk8p/jUz5GgTHtHdTs
4ftlyQ4gtIi/I7QfP13vcDpq1POqcejvgckP0NLvJTOpHvNUQwiCbjUQIimapXcD
s++bngjkqKkxOr+6JUuitsMd+1IKZ50Ecft3C5AwNE1mhqtSBpuIXP2sbjxYzGAp
eRch/ngVL/Xn6wyhHm2IcYDV4vI2bLbxwN7lLy1lk4ppQDmcQ3I+2ilV3Hvz+VOC
N6d04f7qcHwfIUVzplC5BJ1pgzJvLRWfHG7PcfscZJhnNNNwIYv+phODTbiw614=
=b2di
-----END PGP SIGNATURE-----

--WOv6NfrIX4tOeMoJss774qocMq8c1RSx1--


From nobody Tue Apr 22 01:33: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 3F2CC1A0162; Tue, 22 Apr 2014 01:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 fWZAlFAlX_85; Tue, 22 Apr 2014 01:33:20 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4FA1A0161; Tue, 22 Apr 2014 01:33:20 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9wrU-1WnTRB1mcy-00B1PE; Tue, 22 Apr 2014 10:33:13 +0200
Message-ID: <535628D4.80308@gmx.net>
Date: Tue, 22 Apr 2014 10:31:16 +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: "ace@ietf.org" 
References: <533EC002.2010506@gmx.net>
In-Reply-To: <533EC002.2010506@gmx.net>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ODESLsjihpBW0sPFDqn81Bk8khScjJR8b"
X-Provags-ID: V03:K0:ghTdU6B9infijOtmexpPNgP0e/39UQ1sB5P+R1Y+POH+x70/ZZ1 pyeokjoCoG1ioX208+Ims6rtJjedxmHBjkw0R+E4fs6TVWqOt0OlPW2WSWpf8syKO0rss05 OBaR7YbfFuusVXQ4C+lAATBYW5+ffMCfUPdPRefo4uUoKH4CmQoCuElrOIxEhF0G2XUg3JM XoA8W4PR+8HOD+dNSZ4Cg==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/DhXF6Tq-PupsJelKUxyDK_XSgjw
Cc: saag@ietf.org
Subject: [Ace] Reminder: ABFAB Tutorial - April 22nd
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, 22 Apr 2014 08:33:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ODESLsjihpBW0sPFDqn81Bk8khScjJR8b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Please join the ABFAB tutorial today.

On 04/04/2014 04:21 PM, Hannes Tschofenig wrote:
> Hi all,
>=20
> at the ACE BOF we promised to also schedule a tutorial about ABFAB. We
> have been working with Margaret, Sam, and Rhys on the details and they
> kindly offered to give us an overview of ABFAB and how it applies to th=
e
> IoT space.
>=20
> Date: Tuesday, April 22, 2014
> Time: 1:00 pm BST =3D 8am EDT =3D 8pm CST
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2014&m=
onth=3D4&day=3D22&hour=3D12&min=3D0&sec=3D0&p1=3D37&p2=3D136&p3=3D179&p4=3D=
33
>=20
> Webex:
> https://ietf.webex.com/ietf/j.php?MTID=3Dmd4e56d458aa66a2bbdfd2e1463dbc=
977
>=20
> Meeting Number: 644 405 818
> Meeting Password: abfab
>=20
> Audio:
> +1-650-479-3208
> Access code:644 405 818
>=20
> Due to the IETF Webex configuration restrictions there are no other
> dial-in codes available.
>=20
> Ciao
> Hannes & Kepeng
>=20
>=20
>=20
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>=20


--ODESLsjihpBW0sPFDqn81Bk8khScjJR8b
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/

iQEcBAEBCgAGBQJTVijUAAoJEGhJURNOOiAtCcQH/3yuNqsW1dr3xnWEOudnzCyO
t1/51xMu9NFol/yT/l5uRA25ny1klxLWOUT101LlmruFDHrhYwWgke2xXCaC/L0M
puuczxuBFV7orCYUDx2kOYXg5kcTnsTpU/CRsMCot+d6TskwPgGp64p4trhM7QO+
b8JaBzckTlem1BVJU3X4NFsDNKX4xCSPWp3kqrjMkbt1W7DcMyidTdSTqLwopEeS
vIPMDFnAnf+PDiXFrfQY8kzprEcM8WQJ8Kiar4Vb9N0V4IRoqXitWoWx2dG+qWav
acnEHkhmaYY665sUVOrB39g0YAc/+HkS0h1+CT2GIkKyLnqABSXI6PJmDbMHHks=
=S5Hk
-----END PGP SIGNATURE-----

--ODESLsjihpBW0sPFDqn81Bk8khScjJR8b--


From nobody Tue Apr 22 08:54: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 126901A018E for ; Tue, 22 Apr 2014 08:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 I6nDrmi8aS7b for ; Tue, 22 Apr 2014 08:54:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id CDBC31A0004 for ; Tue, 22 Apr 2014 08:54:31 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M5r89-1WsE4K0v3x-00xoVi for ; Tue, 22 Apr 2014 17:54:21 +0200
Message-ID: <53568E8E.5090103@gmx.net>
Date: Tue, 22 Apr 2014 17:45:18 +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: "ace@ietf.org" 
References: <533EC002.2010506@gmx.net> <535628D4.80308@gmx.net>
In-Reply-To: <535628D4.80308@gmx.net>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Cf1alKt0gfTpl0VUX2Euh5Pi1XhDs5Ee8"
X-Provags-ID: V03:K0:P2u4Jpkngd7lYeZXmlCW/FIXuCLvsZILv8fYNFrcds9GIIJ+2oT aaE2BVlGao1ZPxc3sBpsE7RNn6btTlPW1H7BGNVoLgCMMalg0XW3C+kFIHxM48Btd5eggPY 4JUtDUEAWvowXAh9xiUf1Ksv5ZYahHDB+eW/kIEGjUjCBKc/cFFZRl7yaF8MBFmmLyJVlKC VRH/HY15Kz+E9hVhBsYUg==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/VIg8ti9TicKJZsNgrvoLELIkLJI
Subject: Re: [Ace] Reminder: ABFAB Tutorial - April 22nd
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, 22 Apr 2014 15:54:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Cf1alKt0gfTpl0VUX2Euh5Pi1XhDs5Ee8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The slides and the recording is available at:
http://www.tschofenig.priv.at/tutorials/ABFAB-Tutorial.pptx
http://www.tschofenig.priv.at/tutorials/ABFAB-Tutorial.arf

Thanks to Rhys for the talk!

Ciao
Hannes

On 04/22/2014 10:31 AM, Hannes Tschofenig wrote:
> Please join the ABFAB tutorial today.
>=20
> On 04/04/2014 04:21 PM, Hannes Tschofenig wrote:
>> Hi all,
>>
>> at the ACE BOF we promised to also schedule a tutorial about ABFAB. We=

>> have been working with Margaret, Sam, and Rhys on the details and they=

>> kindly offered to give us an overview of ABFAB and how it applies to t=
he
>> IoT space.
>>
>> Date: Tuesday, April 22, 2014
>> Time: 1:00 pm BST =3D 8am EDT =3D 8pm CST
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2014&=
month=3D4&day=3D22&hour=3D12&min=3D0&sec=3D0&p1=3D37&p2=3D136&p3=3D179&p4=
=3D33
>>
>> Webex:
>> https://ietf.webex.com/ietf/j.php?MTID=3Dmd4e56d458aa66a2bbdfd2e1463db=
c977
>>
>> Meeting Number: 644 405 818
>> Meeting Password: abfab
>>
>> Audio:
>> +1-650-479-3208
>> Access code:644 405 818
>>
>> Due to the IETF Webex configuration restrictions there are no other
>> dial-in codes available.
>>
>> Ciao
>> Hannes & Kepeng
>>
>>
>>
>> _______________________________________________
>> 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


--Cf1alKt0gfTpl0VUX2Euh5Pi1XhDs5Ee8
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/

iQEcBAEBCgAGBQJTVo6OAAoJEGhJURNOOiAtV6wH/1ouzAmp5+KksLj+G4ZUIN7u
XR+pWY8EZe3uZtpB0O3OBxQ2P5sibu4vyElZMAz9qLgggHs8GOT1A4ZKxveFotcy
fHBHx1g52AD0YadpUAmPwilHgefX6kkhBEyZ5ud1nRii+xJSJ5ZH8grw4oM44PHL
nd8eBF2rxN4fFx59cUr+xIic3ulnuuVCnnlvueHth16Ctb/8GuFwGcZItlnoaNRB
i9BN2AXcyk+n/uTD6XbZn8Kt+LWJYBeDkWnvuRXEmYp/SG+/nI4SNL8d068CTwl4
XW6JQAhwsTCcwyXrGAOkxc30NaynD/JvwCyAoD2Ir9dsJLAsv3KrmefFR/0hzSY=
=1vov
-----END PGP SIGNATURE-----

--Cf1alKt0gfTpl0VUX2Euh5Pi1XhDs5Ee8--


From nobody Thu Apr 24 01:25: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 E316E1A0564 for ; Thu, 24 Apr 2014 01:25:02 -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 EVZq1joH4tHd for ; Thu, 24 Apr 2014 01:25:01 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2AE1A03A8 for ; Thu, 24 Apr 2014 01:25:01 -0700 (PDT)
X-AuditID: c1b4fb3a-f79156d000001144-e7-5358ca55ea16
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A7.17.04420.55AC8535; Thu, 24 Apr 2014 10:24:53 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 10:24:53 +0200
From: =?iso-8859-1?Q?G=F6ran_Selander?= 
To: "ace@ietf.org" 
Thread-Topic: ACE pre-WG meeting
Thread-Index: AQHPX5aq2nl1O2yRbUmKhf/QvGzt3g==
Date: Thu, 24 Apr 2014 08:24:52 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6A056996FDF3C54B849B0E04D23269D6@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjW7oqYhgg/NTdS2+f+thdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqd1n9kKZnJWXH3wmbGBcQ17FyMnh4SAicS3S79YIWwxiQv3 1rN1MXJxCAkcZZRoeHqOGcJZzCjx+noDG0gVm4CrxIEH75i6GDk4RAQUJa4/SgQJCwtIS5x5 vJsFxBYRUJC4uPckE4StJ/H1YwfYAhYBVYlTpz+B2bwC5hIfbt0DG8kItPj7qTVg9cwC4hK3 nsxngjhIQGLJnvPMELaoxMvH/8B6RYFmvjsOU6MosfNsOzNEr57EjalT2CBsa4m/C9dAxbUl li18zQyxV1Di5MwnLBMYRWchWTcLSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kZFealFmcnFx fp5eXmrJJkZgrBzc8ttqB+PB546HGAU4GJV4eNnU/IKFWBPLiitzDzFKc7AoifNOWuQeLCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoGx2GDfnb2b1h+/pMk3p1324tTph2dN0T4UMMvmxI6Z O9Ssl3fn7NqctD6wYH0wR8Qnq8CbAgY9j+/lh96RMjbY5f1/8nFvTeYw9UkHvlyO/si+7vd5 uRUJccs0/kbd7+O/bfWEL1/gEmukj+R7fkutfDXGnFWi2b3eh+bZ7/iQ4XDrnbuX+PoPSizF GYmGWsxFxYkAgceBv3YCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Xi6PbsDVd9RAgzAuSdS5E6JpuhM
Subject: [Ace] ACE pre-WG meeting
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, 24 Apr 2014 08:25:03 -0000

Hi all,

As was noted in the tutorial session this week, and previously in the
charter discussions, neither the ACE charter nor the use case &
requirements document provides sufficiently detailed problem statement to
be able to evaluate candidate security protocols.

The option to meet face to face and discuss the scope of ACE has been
aired on several occasions. In an recent offline discussion I got a
positive feedback about trying to arrange a meeting before Toronto. The
purpose of the meeting would be to discuss - and hopefully produce - a
more detailed problem statement proposal as input to the ACE work.

A good time could be end-of-May / beginning-of-June to allow for travel
arrangements and still leave enough time for editing drafts based on the
output. =20

One possible location for this meeting is at the Ericsson premises in
Kista out of Stockholm, Sweden. Kista is a short ride from airports
Arlanda and Bromma.

For those interested in attending, please fill in this Doodle ASAP:

http://doodle.com/nw94ruh77fg3qvfg


Please note that this would not be an official interim meeting, as ACE is
not a WG yet.



G=F6ran




From nobody Thu Apr 24 06:15: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 3AAA01A01E3 for ; Thu, 24 Apr 2014 06:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.539
X-Spam-Level: 
X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 STdulK3yvrEL for ; Thu, 24 Apr 2014 06:15:16 -0700 (PDT)
Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3571A01B3 for ; Thu, 24 Apr 2014 06:15:15 -0700 (PDT)
Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA for <51AD17FC6D>; ace@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 24 Apr 2014 18:45:07 +0530
From: "Dr. Corinna Schmitt" 
To: ace@ietf.org
In-Reply-To: 
References: 
Message-ID: <0ddadd275af011dd0145f5cf39d0c9ce@ifi.uzh.ch>
X-Sender: schmitt@ifi.uzh.ch
User-Agent: Roundcube Webmail/0.9.5
X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/9Md5umUx0ZPuZjDVeZ3_oE0_tHc
Subject: Re: [Ace] ACE pre-WG meeting
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, 24 Apr 2014 13:15:19 -0000

Dear Goeran,

that meeting is a good idea especially to schedule it before Toronto. 
Let's discuss those documents and the request needed to be addressed. I 
would be in at this meeting.

Regards from India,
Corinna


Am 2014-04-24 13:54, schrieb Göran Selander:
> Hi all,
> 
> As was noted in the tutorial session this week, and previously in the
> charter discussions, neither the ACE charter nor the use case &
> requirements document provides sufficiently detailed problem statement 
> to
> be able to evaluate candidate security protocols.
> 
> The option to meet face to face and discuss the scope of ACE has been
> aired on several occasions. In an recent offline discussion I got a
> positive feedback about trying to arrange a meeting before Toronto. The
> purpose of the meeting would be to discuss - and hopefully produce - a
> more detailed problem statement proposal as input to the ACE work.
> 
> A good time could be end-of-May / beginning-of-June to allow for travel
> arrangements and still leave enough time for editing drafts based on 
> the
> output.
> 
> One possible location for this meeting is at the Ericsson premises in
> Kista out of Stockholm, Sweden. Kista is a short ride from airports
> Arlanda and Bromma.
> 
> For those interested in attending, please fill in this Doodle ASAP:
> 
> http://doodle.com/nw94ruh77fg3qvfg
> 
> 
> Please note that this would not be an official interim meeting, as ACE 
> is
> not a WG yet.
> 
> 
> 
> Göran
> 
> 
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace


From nobody Fri Apr 25 00:04: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 811DB1A0328 for ; Fri, 25 Apr 2014 00:04:07 -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 2261Q5zbk-iH for ; Fri, 25 Apr 2014 00:04:06 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id A68761A0412 for ; Fri, 25 Apr 2014 00:04:05 -0700 (PDT)
X-AuditID: c1b4fb3a-f79156d000001144-db-535a08de3311
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9C.D7.04420.ED80A535; Fri, 25 Apr 2014 09:03:58 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Fri, 25 Apr 2014 09:03:58 +0200
From: =?iso-8859-1?Q?G=F6ran_Selander?= 
To: "ace@ietf.org" 
Thread-Topic: ACE pre-WG meeting
Thread-Index: AQHPX5aq2nl1O2yRbUmKhf/QvGzt3psh6d4A
Date: Fri, 25 Apr 2014 07:03:58 +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.4.1.140326
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6995DEB8DAEBD04387CD3CAAC4ABF1BD@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje49jqhgg5Xdphbfv/UwOzB6LFny kymAMYrLJiU1J7MstUjfLoErY8v/Q0wFPWIVX57/ZmxgvC/YxcjJISFgIrHyyTU2CFtM4sK9 9WC2kMBRRonXa8y7GLmA7MWMEo86rrGAJNgEXCUOPHjH1MXIwSEioChx/VEiiCksIC/RvT0A pEJEQEHi4t6TUBVGEmeneoOEWQRUJS4ufs4CEuYVMJdY+iATYpG5xOy5p8FmcwpYSEzcepAd xGYEOub7qTVMIDazgLjErSfzmSCOFJBYsuc8M4QtKvHy8T9WEFtUQE/i3XGYGiWJFdsvMUL0 6kncmDqFDcK2lmhdcJAZwtaWWLbwNZjNKyAocXLmE5YJjOKzkKybhaR9FpL2WUjaZyFpX8DI uopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMKYObvlttYPx4HPHQ4wCHIxKPLzFXyKDhVgT y4orcw8xSnOwKInzTlrkHiwkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsdElbkbH4QsRrE+L Ehc/jctV722e0BVpGTl9lWpj5rWbl1fL/+CUT5qcHBPvmKW4nm2Cfsmyfd2CgmkheuZvAlb9 uPLq957kDIvE/A9P9q5rWVVvMOXm08zjS/O9rs++7doeNe/wZ/cPPTe5DGIEPh/jmF7gJ9e7 e03VxpfW19a8t7hsETFHRYmlOCPRUIu5qDgRAC4VTOWKAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/h6e6yaDwfcj6nWZXQ6CZa8LPRM4
Subject: Re: [Ace] ACE pre-WG meeting
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, 25 Apr 2014 07:04:07 -0000

I got some questions offline about this f2f interim meeting and how it is
supposed to work.=20

Here is what I had in mind:

1. We try to fix a date for a 1-day meeting in about 5-6 weeks.

2. Before this meeting, people are invited to submit proposals of a more
detailed problem statement of ACE. With =B3more detailed problem statement=
=B2
I mean for example properties of security protocols between nodes that a
solution should exhibit or support, e.g. whether symmetric and/or
asymmetric keys should be supported, whether negotiation of crypto suite
should be supported, support for intermittent connectivity, round trips,
processing or caching requirements etc.

The input could be in the form of mails to the ACE list, internet drafts,
or something in-between e.g. using some repository for documents. (There
will be at least one detailed input.)

3. We meet and discuss the different proposals and try to agree on a more
detailed problem statement, and then report back to the ACE list.

The reason for proposing a 1-day meeting is based on the assumption that
people have read the inputs and we can go directly to the things people
disagree on and hear the motivations (not necessarily coming to an
agreement). But I don=B9t have a strong opinion about that.

Phone conference facilities could always be considered, but the intent
with such a f2f meeting is to give a chance to brainstorm, draw and
discuss pictures on a white board, etc.

What do you think about this?


G=F6ran




On 24/04/14 10:24, "G=F6ran Selander"  wrote:

>
>Hi all,
>
>As was noted in the tutorial session this week, and previously in the
>charter discussions, neither the ACE charter nor the use case &
>requirements document provides sufficiently detailed problem statement to
>be able to evaluate candidate security protocols.
>
>The option to meet face to face and discuss the scope of ACE has been
>aired on several occasions. In an recent offline discussion I got a
>positive feedback about trying to arrange a meeting before Toronto. The
>purpose of the meeting would be to discuss - and hopefully produce - a
>more detailed problem statement proposal as input to the ACE work.
>
>A good time could be end-of-May / beginning-of-June to allow for travel
>arrangements and still leave enough time for editing drafts based on the
>output. =20
>
>One possible location for this meeting is at the Ericsson premises in
>Kista out of Stockholm, Sweden. Kista is a short ride from airports
>Arlanda and Bromma.
>
>For those interested in attending, please fill in this Doodle ASAP:
>
>http://doodle.com/nw94ruh77fg3qvfg
>
>
>Please note that this would not be an official interim meeting, as ACE is
>not a WG yet.
>
>
>
>G=F6ran
>
>
>


From nobody Sat Apr 26 04:08: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 C44D71A0564 for ; Sat, 26 Apr 2014 04:08:32 -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 8nxDe-gXm4iA for ; Sat, 26 Apr 2014 04:08:28 -0700 (PDT)
Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D5A4B1A05D3 for ; Sat, 26 Apr 2014 04:08:25 -0700 (PDT)
Received: by mail-yh0-f50.google.com with SMTP id b6so1788660yha.37 for ; Sat, 26 Apr 2014 04:08:19 -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:reply-to:mime-version :content-type; bh=S4U17dyp8FW4r9Xxw+oRu+t5X4H6Bsq2J4oA1Uj3X5Y=; b=xzS8KJJhbESiT+L6nSlUdaxHDUuTOAqO/i966CYrw5XmlbmnYPNx3qJt6fzgxloYRu Uh2SBhYoNivituFmsw3EvPPMD+Mq5plU/IdhutBk8/C5K6TbsvnHjXB9X63+T6PPYQ2Z nizOJ2IkIvoDtUFIl2OcH1NfAOfzausZmHSu5bC9IweEcrccyvHVi7UoSb/0rUxv9XCG nnY/TAohCzMzKqJje/22MBSo/ElKwKIRzHGfnu9fhGRYoClsX92cd5N55IddwNqIEKAY IiTVA7uHSyB1vuUGQfBloct3ZPfDmtsSo0a/zcX+3DKdlDD869IaP2INUxSNpQ0MUjbn HVGQ==
X-Received: by 10.236.113.69 with SMTP id z45mr19954235yhg.0.1398510499034; Sat, 26 Apr 2014 04:08:19 -0700 (PDT)
Received: from [10.210.198.141] ([75.112.176.4]) by mx.google.com with ESMTPSA id o62sm18772179yha.27.2014.04.26.04.08.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 04:08:18 -0700 (PDT)
Date: Sat, 26 Apr 2014 07:06:31 -0400
Message-ID: <42n7k6im62yd99tmy0jf8vek.1398507546397@email.android.com>
Importance: normal
From: Margaret Wasserman 
To: =?ISO-8859-1?Q?G=F6ran_Selander?= , "ace@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_2566386644755500"
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/v_N6sgpGdBdCCipJwLVLybH7Iak
Subject: Re: [Ace] ACE pre-WG meeting
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: Sat, 26 Apr 2014 11:08:33 -0000

----_com.android.email_2566386644755500
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SGkgR29yYW4sCgpCZWZvcmUgeW91IGNhbiB0YWxrIG1lYW5pbmdmdWxseSBhYm91dCBzb21lIG9m
IHRoZSB0aGluZ3MgeW91IGhhdmUgbWVudGlvbmVkIGZvciB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQs
IHN1Y2ggYXMgc3ltbWV0cmljIG9yIGFzc3ltbWV0cmljIGtleXMsIEkgdGhpbmsgaXQgd291bGQg
YmUgZ29vZCB0byBtYWtlIHN1cmUgd2UgaGF2ZSBhZ3JlZW1lbnQgb24gdGhlIGJhc2ljIHByb3Bl
cnRpZXMgd2UgbmVlZCBpbiBhIHNvbHV0aW9uLiDCoEkgYW0gbm90IHN1cmUgd2UgYXJlIGFsbCB0
YWxraW5nIGFib3V0IG11dHVhbGx5IGNvbXBhdGlibGUgc2NlbmFyaW9zLgoKU29tZSBwZW9wbGUg
c2VlbSB0byBiZSB0aGlua2luZyBvZiBhIHN5c3RlbSwgbGlrZSBhIHR5cGljYWwgd2lmaSBuZXR3
b3JrLCBpcnJpZ2F0aW9uIGNvbnRyb2xsZXIsIHNlbnNvciBuZXR3b3JrLCBkaXN0cmlidXRpb24g
Y2VudGVyLCBvciBidWlsZGluZyBjb250cm9sIHN5c3RlbSwgd2hlcmUgdGhlIGNvbnN0cmFpbmVk
IG5vZGVlcyBtaWdodCB0YWxrIGRpcmVjdGx5IHRvIGVhY2ggb3RoZXIgKGJvdGggQ2xpZW50IGFu
ZCBSZXNvdXJjZSBQcm92aWRlciBtYXkgYmUgY29uc3RyYWluZWQpLCBidXQgd2hlcmUgaXQgd2ls
bCBiZSBwb3NzaWJsZSB0byByZWFjaCBhIG1vcmUgY2FwYWJsZSBhMEF1dGhlbnRpY2F0aW9uIFNl
cnZlciAob24gdGhlIHdpZmkgQUMsIHRoZSBjb250cm9sbGVyLCBldGMuKSBhdCB0aGUgYmVnaW5u
aW5nIG9mIGVhY2ggc2Vzc2lvbi4gwqBJdCBpcyBlYXN5IHRvIHNlZSBob3cgeW91IGNvdWxkIGFk
ZCBuZXcgbm9kZXMgaW50byBhIHN5c3RlbSBsaWtlIHRoYXQsIHN1cHBvcnQgcmVtb3ZhbCBvZiBu
b2RlcywgdXBkYXRlIGtleXMgZXRjLgoKT3RoZXJzIHNlZW0gdG8gYmUgbG9va2luZyBhdCBhIG1v
cmUgYWRob2Mgc2NlbmFyaW8sIHBlcmhhcHMgWmlnYmVlLWJhc2VkLCB3aGVyZSBub2RlcyBtYXkg
YmUgaW50ZXJtaXR0ZW50bHkgY29ubmVjdGVkLCBhbmQgdHdvIGNvbnN0cmFpbmVkIG5vZGVzIG1h
eSBuZWVkIHRvIGF1dGhlbnRpY2F0ZSBhbmQgYXV0aG9yaXplIG9uZWFub3RoZXIgd2hlbiB0aGVy
ZSBtYXkgYmUgbm8gb3RoZXIgcmVhY2hhYmxlIG5vZGVzLiBJbiB0aGlzIGNhc2UsIHRoZSBBdXRo
ZW50aWNhdGlvbiBTZXJ2ZXIgd291bGQgYmUgbW9yZSBvZiBhIHByb3Zpc2lvbmluZyBzeXN0ZW0g
dGhhdCBwdXNoZXMgc2VjdXJpdHkgcG9saWNpZXMgYW5kIGNyZWRlbnRpYWxzIHRvIHRoZSBjb25z
dHJhaW5lZCBub2RlcyB3aGVuIHBvc3NpYmxlLiDCoEluIHRoaXMgc2NlbmFyaW8sIG5vZGVzIHdp
bGwgb25seSBiZWNvbWUgYXdhcmUgb2YgY2hhbmdlcyAoYWRkaXRpb25hbCBub2RlcyBpbiB0aGUg
c3lzdGVtLCByZW1vdmFsIG9mIG5vZGVzLCBrZXkgY2hhbmdlcykgYWZ0ZXIgc3VmZmljaWVudCBj
b25uZWN0aXZpdHkgd2l0aCB0aGUgQXV0aGVudGljYXRpb24gU2VydmVyLiDCoFRoaXMgbWlnaHQg
YmUgYSBmYWlybHkgc2ltcGxlIHNjZW5hcmlvIGZvciwgYXMgYW4gZXhhbXBsZSwgYSBzZXQgb2Yg
bm9kZXMgdGhhdCBhcmUgY2hhcmdlZCBuaWdodGx5IC0tIHRoZXkgY291bGQgY29ubmVjdCB0byB0
aGUgQXV0aGVudGljYXRpb24gU2VydmVyIHdoZW4gY2hhcmdpbmcgYW5kIGJlIHVwZGF0ZWQgbmln
aHRseS4gwqBJbiBtb3JlIGFkaG9jIHNpdHVhdGlvbnMsIHdoZXJlIG5vZGVzIGNvdWxkIGdvIGRh
eXMgb3IgbW9udGhzIHdpdGhvdXQgcmVhY2hpbmcgYW4gYXV0aGVudGljYXRpb24gc2VydmVyLCB0
aGlzIHdvdWxkIGJlIGEgbXVjaCBtb3JlIGRpZmZpY3VsdCBzY2VuYXJpbyB0byBhZGRyZXNzIHdl
bGwuCgpJdCBzZWVtcyB0byBtZSB0aGF0IHBlb3BsZSB3aG8gYXJlIGNvbnNpZGVyaW5nIHRoZSBm
aXJzdCBtb2RlbCBoYXZlIGEgZGlmZmVyZW50IHNldCBvZiByZXF1aXJlbWVudHMgYW5kIGV4cGVj
dGF0aW9ucyB0aGFuIHBlb3BsZSB3aG8gYXJlIHRoaW5raW5nIG9mIHRoZSBzZWNvbmQgbW9kZWws
IGFuZCB3aGVuIHdlIHRhbGsgYWJvdXQgcG9zc2libGUgc29sdXRpb25zLCBkaWZmZXJlbnQgc29s
dXRpb24gcHJvcGVydGllcyB0ZW5kIHRvIHdvcmsgYmV0dGVyIGZvciBvbmUgc2NlbmFyaW8gdGhh
biB0aGUgb3RoZXIuCgpJIHRoaW5rIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byB3YWxrIHRocm91Z2gg
dGhlc2UgdHdvIHNjZW5hcmlvcyBhbmQgc2VlIHdoYXQgdGhlIHJlcXVpcmVtZW50cywgZXhwZWN0
YXRpb25zIGFuZCBkZXNpcmFibGUgcHJvcGVydGllcyBhcmUgaW4gZWFjaCBzY2VuYXJpby4gwqBX
aGVuIHdlIGFyZSBkb25lIHVuZGVyc3RhbmRpbmcgdGhlaXIgcmVxdWlyZW1lbnRzLCBldGMuIHdl
IGNvdWxkIGRldGVybWluZSBpZiB0aGUgc3VwZXJzZXQgb2YgdGhvc2UgbmVlZHMgY291bGQgYmUg
bWV0IGJ5IGEgc2luZ2xlIHNvbHV0aW9uIHRoYXQgd291bGQgcHJvdmlkZSBhIHNhdGlzZmFjdG9y
eSBleHBlcmllbmNlIGluIGJvdGggY2FzZXMuIEkgYW0gY29uY2VybmVkIHRoYXQgdGhlIHR3byBz
Y2VuYXJpb3MgbWF5IG5vdCBoYXZlIGVub3VnaCBpbiBjb21tb24gdG8gYmUgc2VydmVkIGJ5IGEg
c2luZ2xlIHNvbHV0aW9uLiDCoAoKSU1PLCB0aGUgZmlyc3QgY2FzZSBjb3VsZCBiZSByZWFzb25h
Ymx5IGFkZHJlc3NlZCBieSBtb2RpZmljYXRpb25zIHRvIGV4aXN0aW5nIElFVEYgcHJvdG9jb2xz
IHRvIGNvbnNpZGVyIHRoZSBwcm9wZXJ0aWVzIG9mIGNvbnN0cmFpbmVkIENsaWVudHMgYW5kIFJl
c291cmNlIFNlcnZlcnMuIMKgV2Ugd291bGQgYXR0ZW1wdCB0byByZWR1Y2UgY29tbXVuaWNhdGlv
biBvdmVyaGVhZCBvbiB0aGUgY29uc3RyYWluZWQgbm9kZXMsIGFuZCBvZmZsb2FkIHN0b3JhZ2Ug
YW5kIHByb2Nlc3Npbmcgb3ZlcmhlYWQgdG8gdGhlIEF1dGhlbnRpY2F0aW9uIFNlcnZlci4gwqBJ
IHBlcnNvbmFsbHkgc2VlIHRoZSB3b3JrIG5lY2Vzc2FyeSB0byBkZWFsIHdpdGggdGhlIGZpcnN0
IHNjZW5hcmlvIHRvIGJlIGZhaXJseSBjbGVhciBhbmQgc2ltcGx5IGEgbWF0dGVyIG9mIGVuZ2lu
ZWVyaW5nLgoKSSBhbSBsZXNzIGNlcnRhaW4gaG93IGV4aXN0aW5nIElFVEYgcHJvdG9jb2xzIGNv
dWxkIGJlIGFwcGxpZWQgdG8gdGhlIHNlY29uZCBjYXNlLCB3aGljaCBJIHNlZSBhcyBtb3JlIG9m
IGEgcHJvdmlzaW9uaW5nIHNjZW5hcmlvIHRoYW4gYSBtYXR0ZXIgb2Ygb2ZmbG9hZGluZy4gVGhl
cmUgYXJlIG51bWVyb3VzIHByb2JsZW1zIHRoYXQgY291bGQgYXJpc2Ugd2hlbi9pZiBzb21lIG5v
ZGVzIGFyZSB1cGRhdGVkIGFuZCBvdGhlcnMgYXJlIG5vdCwgZXRjLiDCoFRoZXJlIG1pZ2h0IGJl
IHNldmVyYWwgc3Vic2V0cyBvZiB0aGlzIHNjZW5hcmlvIGJhc2VkIG9uIGFwcGxpY2F0aW9uIG5l
ZWRzIChJLmUuIElzIGl0IGV2ZW4gcG9zc2libGUgdG8gcmVxdWlyZSB0aGF0IG5vZGVzIGJlIGJy
b3VnaHQgaW50byBjb250YWN0IHdpdGggdGhlIEF1dGhlbnRpY2F0aW9uIFNlcnZlciB3aGVuIHRo
ZXkgYXJlIGZvdW5kIHRvIGhhdmUgb3V0LW9mLWRhdGUgaW5mb3JtYXRpb24/KS4gwqBJTU8sIHRo
ZSByZXF1aXJlbWVudHMgb2YgdGhpcyBzY2VuYXJpbyBhcmUgbm90IHdlbGwtZW5vdWdoIHVuZGVy
c3Rvb2QgdG8gYmVnaW4gYnkgZGVzaWduaW5nIGEgc29sdXRpb24uIMKgSWYgd2Ugd2FudCB0byBj
b3ZlciB0aGlzIGNhc2UsIEkgd291bGQgcHJlZmVyIHRvIHNlZSBtb3JlIHdvcmsgZG9uZSBvbiB1
bmRlcnN0YW5kaW5nIHRoZSBwcm9wZXJ0aWVzIGFuZCByZXF1aXJlbWVudHMgb2Ygc3lzdGVtcyB0
aGF0IGZhbGwgaW50byB0aGlzIGNhdGVnb3J5IGJlZm9yZSB3ZSBiZWdpbiB0byBkZXNpZ24gc29s
dXRpb25zLiDCoEkgYW0gY29uY2VybmVkIHRoYXQgdGhlwqBuZWVkcyBvZiB0aGlzIHNjZW5hcmlv
IChvciB0aGVzZSBzY2VuYXJpb3MpIG1heSBub3QgYmUgd2VsbC1lbm91Z2ggdW5kZXJzdG9vZCBm
b3IgdGhpcyB0byBiZSBhbiBlbmdpbmVlcmluZyBwcm9ibGVtIGF0IHRoaXMgcG9pbnQuCgpNYXJn
YXJldAoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tIEfDtnJhbiBTZWxh
bmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiAKRGF0ZTogMDQvMjUvMjAxNCAgMzow
MyBBTSAgKEdNVC0wNTowMCkgClRvIGFjZUBpZXRmLm9yZyAKU3ViamVjdCBSZTogW0FjZV0gQUNF
IHByZS1XRyBtZWV0aW5nIAogCgpJIGdvdCBzb21lIHF1ZXN0aW9ucyBvZmZsaW5lIGFib3V0IHRo
aXMgZjJmIGludGVyaW0gbWVldGluZyBhbmQgaG93IGl0IGlzCnN1cHBvc2VkIHRvIHdvcmsuIAoK
SGVyZSBpcyB3aGF0IEkgaGFkIGluIG1pbmQ6CgoxLiBXZSB0cnkgdG8gZml4IGEgZGF0ZSBmb3Ig
YSAxLWRheSBtZWV0aW5nIGluIGFib3V0IDUtNiB3ZWVrcy4KCjIuIEJlZm9yZSB0aGlzIG1lZXRp
bmcsIHBlb3BsZSBhcmUgaW52aXRlZCB0byBzdWJtaXQgcHJvcG9zYWxzIG9mIGEgbW9yZQpkZXRh
aWxlZCBwcm9ibGVtIHN0YXRlbWVudCBvZiBBQ0UuIFdpdGggwrNtb3JlIGRldGFpbGVkIHByb2Js
ZW0gc3RhdGVtZW50wrIKSSBtZWFuIGZvciBleGFtcGxlIHByb3BlcnRpZXMgb2Ygc2VjdXJpdHkg
cHJvdG9jb2xzIGJldHdlZW4gbm9kZXMgdGhhdCBhCnNvbHV0aW9uIHNob3VsZCBleGhpYml0IG9y
IHN1cHBvcnQsIGUuZy4gd2hldGhlciBzeW1tZXRyaWMgYW5kL29yCmFzeW1tZXRyaWMga2V5cyBz
aG91bGQgYmUgc3VwcG9ydGVkLCB3aGV0aGVyIG5lZ290aWF0aW9uIG9mIGNyeXB0byBzdWl0ZQpz
aG91bGQgYmUgc3VwcG9ydGVkLCBzdXBwb3J0IGZvciBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5
LCByb3VuZCB0cmlwcywKcHJvY2Vzc2luZyBvciBjYWNoaW5nIHJlcXVpcmVtZW50cyBldGMuCgpU
aGUgaW5wdXQgY291bGQgYmUgaW4gdGhlIGZvcm0gb2YgbWFpbHMgdG8gdGhlIEFDRSBsaXN0LCBp
bnRlcm5ldCBkcmFmdHMsCm9yIHNvbWV0aGluZyBpbi1iZXR3ZWVuIGUuZy4gdXNpbmcgc29tZSBy
ZXBvc2l0b3J5IGZvciBkb2N1bWVudHMuIChUaGVyZQp3aWxsIGJlIGF0IGxlYXN0IG9uZSBkZXRh
aWxlZCBpbnB1dC4pCgozLiBXZSBtZWV0IGFuZCBkaXNjdXNzIHRoZSBkaWZmZXJlbnQgcHJvcG9z
YWxzIGFuZCB0cnkgdG8gYWdyZWUgb24gYSBtb3JlCmRldGFpbGVkIHByb2JsZW0gc3RhdGVtZW50
LCBhbmQgdGhlbiByZXBvcnQgYmFjayB0byB0aGUgQUNFIGxpc3QuCgpUaGUgcmVhc29uIGZvciBw
cm9wb3NpbmcgYSAxLWRheSBtZWV0aW5nIGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQK
cGVvcGxlIGhhdmUgcmVhZCB0aGUgaW5wdXRzIGFuZCB3ZSBjYW4gZ28gZGlyZWN0bHkgdG8gdGhl
IHRoaW5ncyBwZW9wbGUKZGlzYWdyZWUgb24gYW5kIGhlYXIgdGhlIG1vdGl2YXRpb25zIChub3Qg
bmVjZXNzYXJpbHkgY29taW5nIHRvIGFuCmFncmVlbWVudCkuIEJ1dCBJIGRvbsK5dCBoYXZlIGEg
c3Ryb25nIG9waW5pb24gYWJvdXQgdGhhdC4KClBob25lIGNvbmZlcmVuY2UgZmFjaWxpdGllcyBj
b3VsZCBhbHdheXMgYmUgY29uc2lkZXJlZCwgYnV0IHRoZSBpbnRlbnQKd2l0aCBzdWNoIGEgZjJm
IG1lZXRpbmcgaXMgdG8gZ2l2ZSBhIGNoYW5jZSB0byBicmFpbnN0b3JtLCBkcmF3IGFuZApkaXNj
dXNzIHBpY3R1cmVzIG9uIGEgd2hpdGUgYm9hcmQsIGV0Yy4KCldoYXQgZG8geW91IHRoaW5rIGFi
b3V0IHRoaXM/CgoKR8O2cmFuCgoKCgpPbiAyNC8wNC8xNCAxMDoyNCwgIkfDtnJhbiBTZWxhbmRl
ciIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4gd3JvdGU6Cgo+Cj5IaSBhbGwsCj4KPkFz
IHdhcyBub3RlZCBpbiB0aGUgdHV0b3JpYWwgc2Vzc2lvbiB0aGlzIHdlZWssIGFuZCBwcmV2aW91
c2x5IGluIHRoZQo+Y2hhcnRlciBkaXNjdXNzaW9ucywgbmVpdGhlciB0aGUgQUNFIGNoYXJ0ZXIg
bm9yIHRoZSB1c2UgY2FzZSAmCj5yZXF1aXJlbWVudHMgZG9jdW1lbnQgcHJvdmlkZXMgc3VmZmlj
aWVudGx5IGRldGFpbGVkIHByb2JsZW0gc3RhdGVtZW50IHRvCj5iZSBhYmxlIHRvIGV2YWx1YXRl
IGNhbmRpZGF0ZSBzZWN1cml0eSBwcm90b2NvbHMuCj4KPlRoZSBvcHRpb24gdG8gbWVldCBmYWNl
IHRvIGZhY2UgYW5kIGRpc2N1c3MgdGhlIHNjb3BlIG9mIEFDRSBoYXMgYmVlbgo+YWlyZWQgb24g
c2V2ZXJhbCBvY2Nhc2lvbnMuIEluIGFuIHJlY2VudCBvZmZsaW5lIGRpc2N1c3Npb24gSSBnb3Qg
YQo+cG9zaXRpdmUgZmVlZGJhY2sgYWJvdXQgdHJ5aW5nIHRvIGFycmFuZ2UgYSBtZWV0aW5nIGJl
Zm9yZSBUb3JvbnRvLiBUaGUKPnB1cnBvc2Ugb2YgdGhlIG1lZXRpbmcgd291bGQgYmUgdG8gZGlz
Y3VzcyAtIGFuZCBob3BlZnVsbHkgcHJvZHVjZSAtIGEKPm1vcmUgZGV0YWlsZWQgcHJvYmxlbSBz
dGF0ZW1lbnQgcHJvcG9zYWwgYXMgaW5wdXQgdG8gdGhlIEFDRSB3b3JrLgo+Cj5BIGdvb2QgdGlt
ZSBjb3VsZCBiZSBlbmQtb2YtTWF5IC8gYmVnaW5uaW5nLW9mLUp1bmUgdG8gYWxsb3cgZm9yIHRy
YXZlbAo+YXJyYW5nZW1lbnRzIGFuZCBzdGlsbCBsZWF2ZSBlbm91Z2ggdGltZSBmb3IgZWRpdGlu
ZyBkcmFmdHMgYmFzZWQgb24gdGhlCj5vdXRwdXQuwqAgCj4KPk9uZSBwb3NzaWJsZSBsb2NhdGlv
biBmb3IgdGhpcyBtZWV0aW5nIGlzIGF0IHRoZSBFcmljc3NvbiBwcmVtaXNlcyBpbgo+S2lzdGEg
b3V0IG9mIFN0b2NraG9sbSwgU3dlZGVuLiBLaXN0YSBpcyBhIHNob3J0IHJpZGUgZnJvbSBhaXJw
b3J0cwo+QXJsYW5kYSBhbmQgQnJvbW1hLgo+Cj5Gb3IgdGhvc2UgaW50ZXJlc3RlZCBpbiBhdHRl
bmRpbmcsIHBsZWFzZSBmaWxsIGluIHRoaXMgRG9vZGxlIEFTQVA6Cj4KPmh0dHA6Ly9kb29kbGUu
Y29tL253OTRydWg3N2ZnM3F2ZmcKPgo+Cj5QbGVhc2Ugbm90ZSB0aGF0IHRoaXMgd291bGQgbm90
IGJlIGFuIG9mZmljaWFsIGludGVyaW0gbWVldGluZywgYXMgQUNFIGlzCj5ub3QgYSBXRyB5ZXQu
Cj4KPgo+Cj5Hw7ZyYW4KPgo+Cj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCkFjZSBtYWlsaW5nIGxpc3QKQWNlQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlCg==

----_com.android.email_2566386644755500
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+SGkgR29yYW4sPGRpdj48YnI+PC9k
aXY+PGRpdj5CZWZvcmUgeW91IGNhbiB0YWxrIG1lYW5pbmdmdWxseSBhYm91dCBzb21lIG9mIHRo
ZSB0aGluZ3MgeW91IGhhdmUgbWVudGlvbmVkIGZvciB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIHN1
Y2ggYXMgc3ltbWV0cmljIG9yIGFzc3ltbWV0cmljIGtleXMsIEkgdGhpbmsgaXQgd291bGQgYmUg
Z29vZCB0byBtYWtlIHN1cmUgd2UgaGF2ZSBhZ3JlZW1lbnQgb24gdGhlIGJhc2ljIHByb3BlcnRp
ZXMgd2UgbmVlZCBpbiBhIHNvbHV0aW9uLiAmbmJzcDtJIGFtIG5vdCBzdXJlIHdlIGFyZSBhbGwg
dGFsa2luZyBhYm91dCBtdXR1YWxseSBjb21wYXRpYmxlIHNjZW5hcmlvcy48L2Rpdj48ZGl2Pjxi
cj48L2Rpdj48ZGl2PlNvbWUgcGVvcGxlIHNlZW0gdG8gYmUgdGhpbmtpbmcgb2YgYSBzeXN0ZW0s
IGxpa2UgYSB0eXBpY2FsIHdpZmkgbmV0d29yaywgaXJyaWdhdGlvbiBjb250cm9sbGVyLCBzZW5z
b3IgbmV0d29yaywgZGlzdHJpYnV0aW9uIGNlbnRlciwgb3IgYnVpbGRpbmcgY29udHJvbCBzeXN0
ZW0sIHdoZXJlIHRoZSBjb25zdHJhaW5lZCBub2RlZXMgbWlnaHQgdGFsayBkaXJlY3RseSB0byBl
YWNoIG90aGVyIChib3RoIENsaWVudCBhbmQgUmVzb3VyY2UgUHJvdmlkZXIgbWF5IGJlIGNvbnN0
cmFpbmVkKSwgYnV0IHdoZXJlIGl0IHdpbGwgYmUgcG9zc2libGUgdG8gcmVhY2ggYSBtb3JlIGNh
cGFibGUgYTBBdXRoZW50aWNhdGlvbiBTZXJ2ZXIgKG9uIHRoZSB3aWZpIEFDLCB0aGUgY29udHJv
bGxlciwgZXRjLikgYXQgdGhlIGJlZ2lubmluZyBvZiBlYWNoIHNlc3Npb24uICZuYnNwO0l0IGlz
IGVhc3kgdG8gc2VlIGhvdyB5b3UgY291bGQgYWRkIG5ldyBub2RlcyBpbnRvIGEgc3lzdGVtIGxp
a2UgdGhhdCwgc3VwcG9ydCByZW1vdmFsIG9mIG5vZGVzLCB1cGRhdGUga2V5cyBldGMuPC9kaXY+
PGRpdj48YnI+PC9kaXY+PGRpdj5PdGhlcnMgc2VlbSB0byBiZSBsb29raW5nIGF0IGEgbW9yZSBh
ZGhvYyBzY2VuYXJpbywgcGVyaGFwcyBaaWdiZWUtYmFzZWQsIHdoZXJlIG5vZGVzIG1heSBiZSBp
bnRlcm1pdHRlbnRseSBjb25uZWN0ZWQsIGFuZCB0d28gY29uc3RyYWluZWQgbm9kZXMgbWF5IG5l
ZWQgdG8gYXV0aGVudGljYXRlIGFuZCBhdXRob3JpemUgb25lYW5vdGhlciB3aGVuIHRoZXJlIG1h
eSBiZSBubyBvdGhlciByZWFjaGFibGUgbm9kZXMuIEluIHRoaXMgY2FzZSwgdGhlIEF1dGhlbnRp
Y2F0aW9uIFNlcnZlciB3b3VsZCBiZSBtb3JlIG9mIGEgcHJvdmlzaW9uaW5nIHN5c3RlbSB0aGF0
IHB1c2hlcyBzZWN1cml0eSBwb2xpY2llcyBhbmQgY3JlZGVudGlhbHMgdG8gdGhlIGNvbnN0cmFp
bmVkIG5vZGVzIHdoZW4gcG9zc2libGUuICZuYnNwO0luIHRoaXMgc2NlbmFyaW8sIG5vZGVzIHdp
bGwgb25seSBiZWNvbWUgYXdhcmUgb2YgY2hhbmdlcyAoYWRkaXRpb25hbCBub2RlcyBpbiB0aGUg
c3lzdGVtLCByZW1vdmFsIG9mIG5vZGVzLCBrZXkgY2hhbmdlcykgYWZ0ZXIgc3VmZmljaWVudCBj
b25uZWN0aXZpdHkgd2l0aCB0aGUgQXV0aGVudGljYXRpb24gU2VydmVyLiAmbmJzcDtUaGlzIG1p
Z2h0IGJlIGEgZmFpcmx5IHNpbXBsZSBzY2VuYXJpbyBmb3IsIGFzIGFuIGV4YW1wbGUsIGEgc2V0
IG9mIG5vZGVzIHRoYXQgYXJlIGNoYXJnZWQgbmlnaHRseSAtLSB0aGV5IGNvdWxkIGNvbm5lY3Qg
dG8gdGhlIEF1dGhlbnRpY2F0aW9uIFNlcnZlciB3aGVuIGNoYXJnaW5nIGFuZCBiZSB1cGRhdGVk
IG5pZ2h0bHkuICZuYnNwO0luIG1vcmUgYWRob2Mgc2l0dWF0aW9ucywgd2hlcmUgbm9kZXMgY291
bGQgZ28gZGF5cyBvciBtb250aHMgd2l0aG91dCByZWFjaGluZyBhbiBhdXRoZW50aWNhdGlvbiBz
ZXJ2ZXIsIHRoaXMgd291bGQgYmUgYSBtdWNoIG1vcmUgZGlmZmljdWx0IHNjZW5hcmlvIHRvIGFk
ZHJlc3Mgd2VsbC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkl0IHNlZW1zIHRvIG1lIHRoYXQg
cGVvcGxlIHdobyBhcmUgY29uc2lkZXJpbmcgdGhlIGZpcnN0IG1vZGVsIGhhdmUgYSBkaWZmZXJl
bnQgc2V0IG9mIHJlcXVpcmVtZW50cyBhbmQgZXhwZWN0YXRpb25zIHRoYW4gcGVvcGxlIHdobyBh
cmUgdGhpbmtpbmcgb2YgdGhlIHNlY29uZCBtb2RlbCwgYW5kIHdoZW4gd2UgdGFsayBhYm91dCBw
b3NzaWJsZSBzb2x1dGlvbnMsIGRpZmZlcmVudCBzb2x1dGlvbiBwcm9wZXJ0aWVzIHRlbmQgdG8g
d29yayBiZXR0ZXIgZm9yIG9uZSBzY2VuYXJpbyB0aGFuIHRoZSBvdGhlci48L2Rpdj48ZGl2Pjxi
cj48L2Rpdj48ZGl2PkkgdGhpbmsgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIHdhbGsgdGhyb3VnaCB0
aGVzZSB0d28gc2NlbmFyaW9zIGFuZCBzZWUgd2hhdCB0aGUgcmVxdWlyZW1lbnRzLCBleHBlY3Rh
dGlvbnMgYW5kIGRlc2lyYWJsZSBwcm9wZXJ0aWVzIGFyZSBpbiBlYWNoIHNjZW5hcmlvLiAmbmJz
cDtXaGVuIHdlIGFyZSBkb25lIHVuZGVyc3RhbmRpbmcgdGhlaXIgcmVxdWlyZW1lbnRzLCBldGMu
IHdlIGNvdWxkIGRldGVybWluZSBpZiB0aGUgc3VwZXJzZXQgb2YgdGhvc2UgbmVlZHMgY291bGQg
YmUgbWV0IGJ5IGEgc2luZ2xlIHNvbHV0aW9uIHRoYXQgd291bGQgcHJvdmlkZSBhIHNhdGlzZmFj
dG9yeSBleHBlcmllbmNlIGluIGJvdGggY2FzZXMuIEkgYW0gY29uY2VybmVkIHRoYXQgdGhlIHR3
byBzY2VuYXJpb3MgbWF5IG5vdCBoYXZlIGVub3VnaCBpbiBjb21tb24gdG8gYmUgc2VydmVkIGJ5
IGEgc2luZ2xlIHNvbHV0aW9uLiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PklNTywg
dGhlIGZpcnN0IGNhc2UgY291bGQgYmUgcmVhc29uYWJseSBhZGRyZXNzZWQgYnkgbW9kaWZpY2F0
aW9ucyB0byBleGlzdGluZyBJRVRGIHByb3RvY29scyB0byBjb25zaWRlciB0aGUgcHJvcGVydGll
cyBvZiBjb25zdHJhaW5lZCBDbGllbnRzIGFuZCBSZXNvdXJjZSBTZXJ2ZXJzLiAmbmJzcDtXZSB3
b3VsZCBhdHRlbXB0IHRvIHJlZHVjZSBjb21tdW5pY2F0aW9uIG92ZXJoZWFkIG9uIHRoZSBjb25z
dHJhaW5lZCBub2RlcywgYW5kIG9mZmxvYWQgc3RvcmFnZSBhbmQgcHJvY2Vzc2luZyBvdmVyaGVh
ZCB0byB0aGUgQXV0aGVudGljYXRpb24gU2VydmVyLiAmbmJzcDtJIHBlcnNvbmFsbHkgc2VlIHRo
ZSB3b3JrIG5lY2Vzc2FyeSB0byBkZWFsIHdpdGggdGhlIGZpcnN0IHNjZW5hcmlvIHRvIGJlIGZh
aXJseSBjbGVhciBhbmQgc2ltcGx5IGEgbWF0dGVyIG9mIGVuZ2luZWVyaW5nLjwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+SSBhbSBsZXNzIGNlcnRhaW4gaG93IGV4aXN0aW5nIElFVEYgcHJvdG9j
b2xzIGNvdWxkIGJlIGFwcGxpZWQgdG8gdGhlIHNlY29uZCBjYXNlLCB3aGljaCBJIHNlZSBhcyBt
b3JlIG9mIGEgcHJvdmlzaW9uaW5nIHNjZW5hcmlvIHRoYW4gYSBtYXR0ZXIgb2Ygb2ZmbG9hZGlu
Zy4gVGhlcmUgYXJlIG51bWVyb3VzIHByb2JsZW1zIHRoYXQgY291bGQgYXJpc2Ugd2hlbi9pZiBz
b21lIG5vZGVzIGFyZSB1cGRhdGVkIGFuZCBvdGhlcnMgYXJlIG5vdCwgZXRjLiAmbmJzcDtUaGVy
ZSBtaWdodCBiZSBzZXZlcmFsIHN1YnNldHMgb2YgdGhpcyBzY2VuYXJpbyBiYXNlZCBvbiBhcHBs
aWNhdGlvbiBuZWVkcyAoSS5lLiBJcyBpdCBldmVuIHBvc3NpYmxlIHRvIHJlcXVpcmUgdGhhdCBu
b2RlcyBiZSBicm91Z2h0IGludG8gY29udGFjdCB3aXRoIHRoZSBBdXRoZW50aWNhdGlvbiBTZXJ2
ZXIgd2hlbiB0aGV5IGFyZSBmb3VuZCB0byBoYXZlIG91dC1vZi1kYXRlIGluZm9ybWF0aW9uPyku
ICZuYnNwO0lNTywgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGlzIHNjZW5hcmlvIGFyZSBub3Qgd2Vs
bC1lbm91Z2ggdW5kZXJzdG9vZCB0byBiZWdpbiBieSBkZXNpZ25pbmcgYSBzb2x1dGlvbi4gJm5i
c3A7SWYgd2Ugd2FudCB0byBjb3ZlciB0aGlzIGNhc2UsIEkgd291bGQgcHJlZmVyIHRvIHNlZSBt
b3JlIHdvcmsgZG9uZSBvbiB1bmRlcnN0YW5kaW5nIHRoZSBwcm9wZXJ0aWVzIGFuZCByZXF1aXJl
bWVudHMgb2Ygc3lzdGVtcyB0aGF0IGZhbGwgaW50byB0aGlzIGNhdGVnb3J5IGJlZm9yZSB3ZSBi
ZWdpbiB0byBkZXNpZ24gc29sdXRpb25zLiAmbmJzcDtJIGFtIGNvbmNlcm5lZCB0aGF0IHRoZSZu
YnNwO25lZWRzIG9mIHRoaXMgc2NlbmFyaW8gKG9yIHRoZXNlIHNjZW5hcmlvcykgbWF5IG5vdCBi
ZSB3ZWxsLWVub3VnaCB1bmRlcnN0b29kIGZvciB0aGlzIHRvIGJlIGFuIGVuZ2luZWVyaW5nIHBy
b2JsZW0gYXQgdGhpcyBwb2ludC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk1hcmdhcmV0PC9k
aXY+PGJyPjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj5Gcm9t
IEfDtnJhbiBTZWxhbmRlciAmbHQ7Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tJmd0OyA8YnI+
RGF0ZTogMDQvMjUvMjAxNCAgMzowMyBBTSAgKEdNVC0wNTowMCkgPGJyPlRvIGFjZUBpZXRmLm9y
ZyA8YnI+U3ViamVjdCBSZTogW0FjZV0gQUNFIHByZS1XRyBtZWV0aW5nIDxicj4gPGJyPjxicj48
YnI+SSBnb3Qgc29tZSBxdWVzdGlvbnMgb2ZmbGluZSBhYm91dCB0aGlzIGYyZiBpbnRlcmltIG1l
ZXRpbmcgYW5kIGhvdyBpdCBpczxicj5zdXBwb3NlZCB0byB3b3JrLiA8YnI+PGJyPkhlcmUgaXMg
d2hhdCBJIGhhZCBpbiBtaW5kOjxicj48YnI+MS4gV2UgdHJ5IHRvIGZpeCBhIGRhdGUgZm9yIGEg
MS1kYXkgbWVldGluZyBpbiBhYm91dCA1LTYgd2Vla3MuPGJyPjxicj4yLiBCZWZvcmUgdGhpcyBt
ZWV0aW5nLCBwZW9wbGUgYXJlIGludml0ZWQgdG8gc3VibWl0IHByb3Bvc2FscyBvZiBhIG1vcmU8
YnI+ZGV0YWlsZWQgcHJvYmxlbSBzdGF0ZW1lbnQgb2YgQUNFLiBXaXRoIMKzbW9yZSBkZXRhaWxl
ZCBwcm9ibGVtIHN0YXRlbWVudMKyPGJyPkkgbWVhbiBmb3IgZXhhbXBsZSBwcm9wZXJ0aWVzIG9m
IHNlY3VyaXR5IHByb3RvY29scyBiZXR3ZWVuIG5vZGVzIHRoYXQgYTxicj5zb2x1dGlvbiBzaG91
bGQgZXhoaWJpdCBvciBzdXBwb3J0LCBlLmcuIHdoZXRoZXIgc3ltbWV0cmljIGFuZC9vcjxicj5h
c3ltbWV0cmljIGtleXMgc2hvdWxkIGJlIHN1cHBvcnRlZCwgd2hldGhlciBuZWdvdGlhdGlvbiBv
ZiBjcnlwdG8gc3VpdGU8YnI+c2hvdWxkIGJlIHN1cHBvcnRlZCwgc3VwcG9ydCBmb3IgaW50ZXJt
aXR0ZW50IGNvbm5lY3Rpdml0eSwgcm91bmQgdHJpcHMsPGJyPnByb2Nlc3Npbmcgb3IgY2FjaGlu
ZyByZXF1aXJlbWVudHMgZXRjLjxicj48YnI+VGhlIGlucHV0IGNvdWxkIGJlIGluIHRoZSBmb3Jt
IG9mIG1haWxzIHRvIHRoZSBBQ0UgbGlzdCwgaW50ZXJuZXQgZHJhZnRzLDxicj5vciBzb21ldGhp
bmcgaW4tYmV0d2VlbiBlLmcuIHVzaW5nIHNvbWUgcmVwb3NpdG9yeSBmb3IgZG9jdW1lbnRzLiAo
VGhlcmU8YnI+d2lsbCBiZSBhdCBsZWFzdCBvbmUgZGV0YWlsZWQgaW5wdXQuKTxicj48YnI+My4g
V2UgbWVldCBhbmQgZGlzY3VzcyB0aGUgZGlmZmVyZW50IHByb3Bvc2FscyBhbmQgdHJ5IHRvIGFn
cmVlIG9uIGEgbW9yZTxicj5kZXRhaWxlZCBwcm9ibGVtIHN0YXRlbWVudCwgYW5kIHRoZW4gcmVw
b3J0IGJhY2sgdG8gdGhlIEFDRSBsaXN0Ljxicj48YnI+VGhlIHJlYXNvbiBmb3IgcHJvcG9zaW5n
IGEgMS1kYXkgbWVldGluZyBpcyBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0PGJyPnBlb3Bs
ZSBoYXZlIHJlYWQgdGhlIGlucHV0cyBhbmQgd2UgY2FuIGdvIGRpcmVjdGx5IHRvIHRoZSB0aGlu
Z3MgcGVvcGxlPGJyPmRpc2FncmVlIG9uIGFuZCBoZWFyIHRoZSBtb3RpdmF0aW9ucyAobm90IG5l
Y2Vzc2FyaWx5IGNvbWluZyB0byBhbjxicj5hZ3JlZW1lbnQpLiBCdXQgSSBkb27CuXQgaGF2ZSBh
IHN0cm9uZyBvcGluaW9uIGFib3V0IHRoYXQuPGJyPjxicj5QaG9uZSBjb25mZXJlbmNlIGZhY2ls
aXRpZXMgY291bGQgYWx3YXlzIGJlIGNvbnNpZGVyZWQsIGJ1dCB0aGUgaW50ZW50PGJyPndpdGgg
c3VjaCBhIGYyZiBtZWV0aW5nIGlzIHRvIGdpdmUgYSBjaGFuY2UgdG8gYnJhaW5zdG9ybSwgZHJh
dyBhbmQ8YnI+ZGlzY3VzcyBwaWN0dXJlcyBvbiBhIHdoaXRlIGJvYXJkLCBldGMuPGJyPjxicj5X
aGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGlzPzxicj48YnI+PGJyPkfDtnJhbjxicj48YnI+PGJy
Pjxicj48YnI+T24gMjQvMDQvMTQgMTA6MjQsICJHw7ZyYW4gU2VsYW5kZXIiICZsdDtnb3Jhbi5z
ZWxhbmRlckBlcmljc3Nvbi5jb20mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0Ozxicj4mZ3Q7SGkgYWxs
LDxicj4mZ3Q7PGJyPiZndDtBcyB3YXMgbm90ZWQgaW4gdGhlIHR1dG9yaWFsIHNlc3Npb24gdGhp
cyB3ZWVrLCBhbmQgcHJldmlvdXNseSBpbiB0aGU8YnI+Jmd0O2NoYXJ0ZXIgZGlzY3Vzc2lvbnMs
IG5laXRoZXIgdGhlIEFDRSBjaGFydGVyIG5vciB0aGUgdXNlIGNhc2UgJmFtcDs8YnI+Jmd0O3Jl
cXVpcmVtZW50cyBkb2N1bWVudCBwcm92aWRlcyBzdWZmaWNpZW50bHkgZGV0YWlsZWQgcHJvYmxl
bSBzdGF0ZW1lbnQgdG88YnI+Jmd0O2JlIGFibGUgdG8gZXZhbHVhdGUgY2FuZGlkYXRlIHNlY3Vy
aXR5IHByb3RvY29scy48YnI+Jmd0Ozxicj4mZ3Q7VGhlIG9wdGlvbiB0byBtZWV0IGZhY2UgdG8g
ZmFjZSBhbmQgZGlzY3VzcyB0aGUgc2NvcGUgb2YgQUNFIGhhcyBiZWVuPGJyPiZndDthaXJlZCBv
biBzZXZlcmFsIG9jY2FzaW9ucy4gSW4gYW4gcmVjZW50IG9mZmxpbmUgZGlzY3Vzc2lvbiBJIGdv
dCBhPGJyPiZndDtwb3NpdGl2ZSBmZWVkYmFjayBhYm91dCB0cnlpbmcgdG8gYXJyYW5nZSBhIG1l
ZXRpbmcgYmVmb3JlIFRvcm9udG8uIFRoZTxicj4mZ3Q7cHVycG9zZSBvZiB0aGUgbWVldGluZyB3
b3VsZCBiZSB0byBkaXNjdXNzIC0gYW5kIGhvcGVmdWxseSBwcm9kdWNlIC0gYTxicj4mZ3Q7bW9y
ZSBkZXRhaWxlZCBwcm9ibGVtIHN0YXRlbWVudCBwcm9wb3NhbCBhcyBpbnB1dCB0byB0aGUgQUNF
IHdvcmsuPGJyPiZndDs8YnI+Jmd0O0EgZ29vZCB0aW1lIGNvdWxkIGJlIGVuZC1vZi1NYXkgLyBi
ZWdpbm5pbmctb2YtSnVuZSB0byBhbGxvdyBmb3IgdHJhdmVsPGJyPiZndDthcnJhbmdlbWVudHMg
YW5kIHN0aWxsIGxlYXZlIGVub3VnaCB0aW1lIGZvciBlZGl0aW5nIGRyYWZ0cyBiYXNlZCBvbiB0
aGU8YnI+Jmd0O291dHB1dC4mbmJzcDsgPGJyPiZndDs8YnI+Jmd0O09uZSBwb3NzaWJsZSBsb2Nh
dGlvbiBmb3IgdGhpcyBtZWV0aW5nIGlzIGF0IHRoZSBFcmljc3NvbiBwcmVtaXNlcyBpbjxicj4m
Z3Q7S2lzdGEgb3V0IG9mIFN0b2NraG9sbSwgU3dlZGVuLiBLaXN0YSBpcyBhIHNob3J0IHJpZGUg
ZnJvbSBhaXJwb3J0czxicj4mZ3Q7QXJsYW5kYSBhbmQgQnJvbW1hLjxicj4mZ3Q7PGJyPiZndDtG
b3IgdGhvc2UgaW50ZXJlc3RlZCBpbiBhdHRlbmRpbmcsIHBsZWFzZSBmaWxsIGluIHRoaXMgRG9v
ZGxlIEFTQVA6PGJyPiZndDs8YnI+Jmd0O2h0dHA6Ly9kb29kbGUuY29tL253OTRydWg3N2ZnM3F2
Zmc8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDtQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgd291bGQgbm90
IGJlIGFuIG9mZmljaWFsIGludGVyaW0gbWVldGluZywgYXMgQUNFIGlzPGJyPiZndDtub3QgYSBX
RyB5ZXQuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDtHw7ZyYW48YnI+Jmd0Ozxicj4m
Z3Q7PGJyPiZndDs8YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPkFjZSBtYWlsaW5nIGxpc3Q8YnI+QWNlQGlldGYub3JnPGJyPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPGJyPjwvYm9keT4=

----_com.android.email_2566386644755500--



From nobody Sat Apr 26 04:16: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 66A691A0164 for ; Sat, 26 Apr 2014 04:16: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 ToIyvapT9TVb for ; Sat, 26 Apr 2014 04:16:28 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) by ietfa.amsl.com (Postfix) with ESMTP id AF5C81A0148 for ; Sat, 26 Apr 2014 04:16:28 -0700 (PDT)
Received: by mail-yk0-f181.google.com with SMTP id 131so4181302ykp.26 for ; Sat, 26 Apr 2014 04:16:21 -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=b7RXniIrWhunedmTB0P75pbLTb00tIvaTvC6l9bgOZw=; b=ybytt3bPrKQNGE6t4h0hhi+QfyVzqObuytrD5C0HDZ0RUclVHbWLWqXkYICyt5pnh4 /RDfbHV6B7NNjDoh5RJLCxSMrPV2ZkScxy01AvtxgfJYGe/pKCVhGiqWOzlP3QCT1Paw quCbFv0eJJC26R7BkGKeEAdGXLqIOp1ifRJXqV9KCDSMZrmq2rndiTvkx+9vp+4AW5jo cBlmqx8vQX8PwGK8ak0d3QRnzV9cS8W+0JEy0r9jeL5IWDw8ZQdFmPpvY/EpjQpQSdL4 ev0WFr8KQYfmvcdys+U7uEmjiRyQTJWQpTfF7Rst+07E6S3ed1vIW7c2X3cGZk+wW6uY BYLA==
X-Received: by 10.236.99.99 with SMTP id w63mr19688786yhf.52.1398510981897; Sat, 26 Apr 2014 04:16:21 -0700 (PDT)
Received: from [10.210.198.141] ([75.112.176.4]) by mx.google.com with ESMTPSA id o62sm18772179yha.27.2014.04.26.04.16.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 04:16:21 -0700 (PDT)
Date: Sat, 26 Apr 2014 07:14:35 -0400
Message-ID: 
Importance: normal
From: Margaret Wasserman 
To: "robert.cragie@gridmerge.com" , Hannes Tschofenig , Rene Struik 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_2571214806561140"
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/TJo5gFNxVpgCT6uCn1Z-14NNp-M
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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: Sat, 26 Apr 2014 11:16:31 -0000

----_com.android.email_2571214806561140
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SGkgUm9iZXJ0LMKgCgpPbmUgcXVlc3Rpb24gZm9yIHRoZSBXRyBiYXNlZCBvbiB5b3VyIGNvbW1l
bnRzIG9uIHRoZSBjaGFydGVyIHRleHQ6CgpXb3VsZCB3ZSBiZSBva2F5IHdpdGggYSBzb2x1dGlv
biB0aGF0IG9ubHkgd29ya3MgZm9yIFJFU1QtYmFzZWQgYXBwbGljYXRpb25zLCBvciB3aWxsIHdl
IGFsc28gbmVlZCB0byBzZWN1cmUgYW55IG90aGVyIHNvcnRzIG9mIGNvbW11bmljYXRpb24gYmV0
d2VlbiBDbGllbnRzIGFuZCBSZXNvdXJjZSBTZXJ2ZXJzPwoKTWFyZ2FyZXQKCgoKLS0tLS0tLS0g
T3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tIFJvYmVydCBDcmFnaWUgPHJvYmVydC5jcmFn
aWVAZ3JpZG1lcmdlLmNvbT4gCkRhdGU6IDA0LzE1LzIwMTQgIDExOjUzIEFNICAoR01ULTA1OjAw
KSAKVG8gSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+LFJlbmUg
U3RydWlrIDxyc3RydWlrLmV4dEBnbWFpbC5jb20+IApDYyBhY2VAaWV0Zi5vcmcgClN1YmplY3Qg
UmU6IFtBY2VdIExhc3QgQ2FsbCBmb3IgQ29tbWVudHMgb24gQUNFIENoYXJ0ZXIgVGV4dCAKIApB
IGNvdXBsZSBvZiBzbWFsbCBjb21tZW50cyBpbmxpbmUuIEkgYW0gT0sgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY2hhbmdlcy4KClJvYmVydAoKT24gMTQvMDQvMjAxNCAxOjI1IFBNLCBIYW5uZXMgVHNj
aG9mZW5pZyB3cm90ZToKPiBIaSBSZW5lLAo+wqDCoCAKPiB0aGFua3MgZm9yIHRoZSByZXZpZXcg
Y29tbWVudHMuIEkgaGF2ZSB1cGRhdGVkIHRoZSBjaGFydGVyIHRleHQgYWNjb3JkaW5nbHkuCj7C
oMKgIAo+IEEgZmV3IHJlbWFya3MgaW5saW5lOgo+wqDCoCAKPgo+IEdlc2VuZGV0OiBEb25uZXJz
dGFnLCAxMC4gQXByaWwgMjAxNCB1bSAyMjo1OCBVaHIKPiBWb246ICJSZW5lIFN0cnVpayIgPHJz
dHJ1aWsuZXh0QGdtYWlsLmNvbT4KPiBBbjogIkhhbm5lcyBUc2Nob2ZlbmlnIiA8aGFubmVzLnRz
Y2hvZmVuaWdAZ214Lm5ldD4sICJhY2VAaWV0Zi5vcmciIDxhY2VAaWV0Zi5vcmc+Cj4gQmV0cmVm
ZjogUmU6IFtBY2VdIExhc3QgQ2FsbCBmb3IgQ29tbWVudHMgb24gQUNFIENoYXJ0ZXIgVGV4dAo+
Cj4gSGkgSGFubmVzOgo+Cj4gSSBoYWQgYSBsb29rIGF0IHRoZSBjaGFydGVyIHRleHQuIEkgZG8g
YWdyZWUgd2l0aCB0aGUgdHdvIHRhc2tzIGlkZW50aWZpZWQgaW4gdGhlIGNoYXJ0ZXIuCj4KPiBJ
IGRvIGhhdmUgc29tZSBzb21lIGNvbW1lbnRzIG9uIHRoZSAocmF0aGVyIGxlbmd0aHkpIHByZWx1
ZGUgdG8gdGhlIGVudW1lcmF0aW9uIG9mIHRoZXNlIHR3byB0YXNrcy4gVGhlc2UgY29tbWVudHMg
ZG8gbm90IG1hdHRlciBpZiB0aGUgZ3JvdXAgYWdyZWVzIHRoYXQgdGhlIGNoYXJ0ZXIgZG9lcyBu
b3QgdHJ5IGFuZCBzdGVlciBpbnRvIGEgcGFydGljdWxhciBzb2x1dGlvbiBkaXJlY3Rpb24gKGFz
IHNvbWUgY29tbWVudHMgb24gdGhlIGxpc3QgaGF2ZSBpbmRlZWQgc3VnZ2VzdGVkIHRvIGJlIHRo
ZSBjYXNlKS4gTXkgY29tbWVudHMgYXJlIHdvcmRlZCBpbiBjYXNlIHRoaXMgaXMgbm90IHNvLgo+
Cj4gU21hbGwgY29tbWVudHM6Cj4gYSkgMm5kIHBhcmEsIGwuIDM6IHJlcGxhY2UgImF1dGhvcml6
YXRpb24gZGVjaXNpb25zIiBieSAiYXV0aG9yaXphdGlvbiBjcml0ZXJpYSIgb3IgImF1dGhvcml6
YXRpb24gcG9saWN5Ii4gQWZ0ZXIgYWxsLCBkZWNpc2lvbnMgYXJlIG5vdCBzdG9yZWQsIGJ1dCBh
Y3RlZCB1cG9uLgo+wqDCoCAKPiBbaGFubmVzXSBGaXhlZC4KPFJDQz5JIGhhdmUgbm8gcGFydGlj
dWxhciBpc3N1ZSB3aXRoIHRoZSBjaGFuZ2UgYnV0IEkgdGhpbmsgaXQgd2FzIE9LIGFzIAppdCB3
YXMsIGFzIGFuIGF1dGhvcml6YXRpb24gKnBvbGljeSogY2FuIG9mdGVuIGJlIHN0YXRpYywgdGhl
cmVmb3JlIG5vdCAKcmVxdWlyaW5nIHN0b3JhZ2UuIERlY2lzaW9ucyBjZXJ0YWlubHkgYXJlIHN0
b3JlZCBhbmQgZm9ybSB0aGUgYmFzaXMgZm9yIAphY2Nlc3MgY29udHJvbC48L1JDQz4KPsKgwqAg
Cj4gYikgMm5kIHBhcmEsIGwuIC0xOiByZXBsYWNlICJyZXNvdXJjZSBzZXJ2ZXIiIGJ5ICJyZXNv
dXJjZSBvd25lciIsICJyZXNvdXJjZSBob2xkZXIiLCBvciBzaW1pbGFyLiBUaGlzIHdvdWxkIG1h
a2UgaXQgY2xlYXJlciB0aGF0IHRoZSAic2VydmVyIiBpcyB0aGUgZGV2aWNlIHRoYXQgYWN0dWFs
bHkgc3RvcmVzIHRoZSBpbmZvIHRoZSBjbGllbnQgaXMgc29saWNpdGluZy4KPgo+IFtoYW5uZXNd
IEkgY2hhbmdlZCB0aGUgd29yZGluZyB0byBtYWtlIGNsZWFyIHRoYXQgd2UgYXJlIHRhbGtpbmcg
YWJvdXQgdGhlIHNlcnZlciB0aGF0IGlzIGhvbGRpbmcgdGhlIHJlc291cmNlLgo8UkNDPlRoZSB3
YXkgaXQgaXMgd3JpdHRlbiBub3cgY291bGQgcmVhZCB0aGF0IGNsaWVudHMgY2FuIGhvbGQgCnJl
c291cmNlcyAtIG5vdCB0aGUgY2FzZSBpbiBhIFJFU1QgYXJjaGl0ZWN0dXJlLiBBZ2FpbiwgSSB0
aG91Z2h0IGl0IHdhcyAKT0sgYXMgaXQgd2F5PC9SQ0M+CgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KQWNlIG1haWxpbmcgbGlzdApBY2VAaWV0Zi5vcmcK
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UK

----_com.android.email_2571214806561140
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+SGkgUm9iZXJ0LCZuYnNwOzxkaXY+
PGJyPjwvZGl2PjxkaXY+T25lIHF1ZXN0aW9uIGZvciB0aGUgV0cgYmFzZWQgb24geW91ciBjb21t
ZW50cyBvbiB0aGUgY2hhcnRlciB0ZXh0OjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+V291bGQg
d2UgYmUgb2theSB3aXRoIGEgc29sdXRpb24gdGhhdCBvbmx5IHdvcmtzIGZvciBSRVNULWJhc2Vk
IGFwcGxpY2F0aW9ucywgb3Igd2lsbCB3ZSBhbHNvIG5lZWQgdG8gc2VjdXJlIGFueSBvdGhlciBz
b3J0cyBvZiBjb21tdW5pY2F0aW9uIGJldHdlZW4gQ2xpZW50cyBhbmQgUmVzb3VyY2UgU2VydmVy
cz88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk1hcmdhcmV0PC9kaXY+PGRpdj48YnI+PC9kaXY+
PGJyPjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj5Gcm9tIFJv
YmVydCBDcmFnaWUgJmx0O3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbSZndDsgPGJyPkRhdGU6
IDA0LzE1LzIwMTQgIDExOjUzIEFNICAoR01ULTA1OjAwKSA8YnI+VG8gSGFubmVzIFRzY2hvZmVu
aWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQmZ3Q7LFJlbmUgU3RydWlrICZsdDtyc3Ry
dWlrLmV4dEBnbWFpbC5jb20mZ3Q7IDxicj5DYyBhY2VAaWV0Zi5vcmcgPGJyPlN1YmplY3QgUmU6
IFtBY2VdIExhc3QgQ2FsbCBmb3IgQ29tbWVudHMgb24gQUNFIENoYXJ0ZXIgVGV4dCA8YnI+IDxi
cj48YnI+QSBjb3VwbGUgb2Ygc21hbGwgY29tbWVudHMgaW5saW5lLiBJIGFtIE9LIHdpdGggdGhl
IHJlc3Qgb2YgdGhlIGNoYW5nZXMuPGJyPjxicj5Sb2JlcnQ8YnI+PGJyPk9uIDE0LzA0LzIwMTQg
MToyNSBQTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6PGJyPiZndDsgSGkgUmVuZSw8YnI+Jmd0
OyZuYnNwOyZuYnNwOyA8YnI+Jmd0OyB0aGFua3MgZm9yIHRoZSByZXZpZXcgY29tbWVudHMuIEkg
aGF2ZSB1cGRhdGVkIHRoZSBjaGFydGVyIHRleHQgYWNjb3JkaW5nbHkuPGJyPiZndDsmbmJzcDsm
bmJzcDsgPGJyPiZndDsgQSBmZXcgcmVtYXJrcyBpbmxpbmU6PGJyPiZndDsmbmJzcDsmbmJzcDsg
PGJyPiZndDs8YnI+Jmd0OyBHZXNlbmRldDogRG9ubmVyc3RhZywgMTAuIEFwcmlsIDIwMTQgdW0g
MjI6NTggVWhyPGJyPiZndDsgVm9uOiAiUmVuZSBTdHJ1aWsiICZsdDtyc3RydWlrLmV4dEBnbWFp
bC5jb20mZ3Q7PGJyPiZndDsgQW46ICJIYW5uZXMgVHNjaG9mZW5pZyIgJmx0O2hhbm5lcy50c2No
b2ZlbmlnQGdteC5uZXQmZ3Q7LCAiYWNlQGlldGYub3JnIiAmbHQ7YWNlQGlldGYub3JnJmd0Ozxi
cj4mZ3Q7IEJldHJlZmY6IFJlOiBbQWNlXSBMYXN0IENhbGwgZm9yIENvbW1lbnRzIG9uIEFDRSBD
aGFydGVyIFRleHQ8YnI+Jmd0Ozxicj4mZ3Q7IEhpIEhhbm5lczo8YnI+Jmd0Ozxicj4mZ3Q7IEkg
aGFkIGEgbG9vayBhdCB0aGUgY2hhcnRlciB0ZXh0LiBJIGRvIGFncmVlIHdpdGggdGhlIHR3byB0
YXNrcyBpZGVudGlmaWVkIGluIHRoZSBjaGFydGVyLjxicj4mZ3Q7PGJyPiZndDsgSSBkbyBoYXZl
IHNvbWUgc29tZSBjb21tZW50cyBvbiB0aGUgKHJhdGhlciBsZW5ndGh5KSBwcmVsdWRlIHRvIHRo
ZSBlbnVtZXJhdGlvbiBvZiB0aGVzZSB0d28gdGFza3MuIFRoZXNlIGNvbW1lbnRzIGRvIG5vdCBt
YXR0ZXIgaWYgdGhlIGdyb3VwIGFncmVlcyB0aGF0IHRoZSBjaGFydGVyIGRvZXMgbm90IHRyeSBh
bmQgc3RlZXIgaW50byBhIHBhcnRpY3VsYXIgc29sdXRpb24gZGlyZWN0aW9uIChhcyBzb21lIGNv
bW1lbnRzIG9uIHRoZSBsaXN0IGhhdmUgaW5kZWVkIHN1Z2dlc3RlZCB0byBiZSB0aGUgY2FzZSku
IE15IGNvbW1lbnRzIGFyZSB3b3JkZWQgaW4gY2FzZSB0aGlzIGlzIG5vdCBzby48YnI+Jmd0Ozxi
cj4mZ3Q7IFNtYWxsIGNvbW1lbnRzOjxicj4mZ3Q7IGEpIDJuZCBwYXJhLCBsLiAzOiByZXBsYWNl
ICJhdXRob3JpemF0aW9uIGRlY2lzaW9ucyIgYnkgImF1dGhvcml6YXRpb24gY3JpdGVyaWEiIG9y
ICJhdXRob3JpemF0aW9uIHBvbGljeSIuIEFmdGVyIGFsbCwgZGVjaXNpb25zIGFyZSBub3Qgc3Rv
cmVkLCBidXQgYWN0ZWQgdXBvbi48YnI+Jmd0OyZuYnNwOyZuYnNwOyA8YnI+Jmd0OyBbaGFubmVz
XSBGaXhlZC48YnI+Jmx0O1JDQyZndDtJIGhhdmUgbm8gcGFydGljdWxhciBpc3N1ZSB3aXRoIHRo
ZSBjaGFuZ2UgYnV0IEkgdGhpbmsgaXQgd2FzIE9LIGFzIDxicj5pdCB3YXMsIGFzIGFuIGF1dGhv
cml6YXRpb24gKnBvbGljeSogY2FuIG9mdGVuIGJlIHN0YXRpYywgdGhlcmVmb3JlIG5vdCA8YnI+
cmVxdWlyaW5nIHN0b3JhZ2UuIERlY2lzaW9ucyBjZXJ0YWlubHkgYXJlIHN0b3JlZCBhbmQgZm9y
bSB0aGUgYmFzaXMgZm9yIDxicj5hY2Nlc3MgY29udHJvbC4mbHQ7L1JDQyZndDs8YnI+Jmd0OyZu
YnNwOyZuYnNwOyA8YnI+Jmd0OyBiKSAybmQgcGFyYSwgbC4gLTE6IHJlcGxhY2UgInJlc291cmNl
IHNlcnZlciIgYnkgInJlc291cmNlIG93bmVyIiwgInJlc291cmNlIGhvbGRlciIsIG9yIHNpbWls
YXIuIFRoaXMgd291bGQgbWFrZSBpdCBjbGVhcmVyIHRoYXQgdGhlICJzZXJ2ZXIiIGlzIHRoZSBk
ZXZpY2UgdGhhdCBhY3R1YWxseSBzdG9yZXMgdGhlIGluZm8gdGhlIGNsaWVudCBpcyBzb2xpY2l0
aW5nLjxicj4mZ3Q7PGJyPiZndDsgW2hhbm5lc10gSSBjaGFuZ2VkIHRoZSB3b3JkaW5nIHRvIG1h
a2UgY2xlYXIgdGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgc2VydmVyIHRoYXQgaXMgaG9s
ZGluZyB0aGUgcmVzb3VyY2UuPGJyPiZsdDtSQ0MmZ3Q7VGhlIHdheSBpdCBpcyB3cml0dGVuIG5v
dyBjb3VsZCByZWFkIHRoYXQgY2xpZW50cyBjYW4gaG9sZCA8YnI+cmVzb3VyY2VzIC0gbm90IHRo
ZSBjYXNlIGluIGEgUkVTVCBhcmNoaXRlY3R1cmUuIEFnYWluLCBJIHRob3VnaHQgaXQgd2FzIDxi
cj5PSyBhcyBpdCB3YXkmbHQ7L1JDQyZndDs8YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5BY2UgbWFpbGluZyBsaXN0PGJyPkFjZUBp
ZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTxicj48
L2JvZHk+

----_com.android.email_2571214806561140--



From nobody Sat Apr 26 16:17: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 BEC4F1A06D2 for ; Sat, 26 Apr 2014 16:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.163
X-Spam-Level: 
X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, 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 yN4jm0MiLQFg for ; Sat, 26 Apr 2014 16:16:57 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6EA1A040C for ; Sat, 26 Apr 2014 16:16:57 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C31020028 for ; Sat, 26 Apr 2014 19:17:46 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id C4EE863ABD; Sat, 26 Apr 2014 19:16:45 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B212763AA2 for ; Sat, 26 Apr 2014 19:16:45 -0400 (EDT)
From: Michael Richardson 
To: "ace\@ietf.org" 
In-Reply-To: <42n7k6im62yd99tmy0jf8vek.1398507546397@email.android.com>
References: <42n7k6im62yd99tmy0jf8vek.1398507546397@email.android.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/HZPVtTEbeWR-Wy94kw58DFrCAd0
Subject: Re: [Ace] ACE pre-WG meeting
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, 26 Apr 2014 23:17:00 -0000

--=-=-=


Margaret Wasserman  wrote:
    > Some people seem to be thinking of a system, like a typical wifi
    > network, irrigation controller, sensor network, distribution center, or
    > building control system, where the constrained nodees might talk
    > directly to each other (both Client and Resource Provider may be
    > constrained), but where it will be possible to reach a more capable
    > a0Authentication Server (on the wifi AC, the controller, etc.) at the
    > beginning of each session.  It is easy to see how you could add new
    > nodes into a system like that, support removal of nodes, update keys
    > etc.

What is you notion of "session" here?
I think that many would like the relationship to be rather long lived.

    > Others seem to be looking at a more adhoc scenario, perhaps
    > Zigbee-based, where nodes may be intermittently connected, and two
    > constrained nodes may need to authenticate and authorize oneanother
    > when there may be no other reachable nodes. In this case, the
    > Authentication Server would be more of a provisioning system that
    > pushes security policies and credentials to the constrained nodes when
    > possible.  In this scenario, nodes will only become aware of changes
    > (additional nodes in the system, removal of nodes, key changes) after
    > sufficient connectivity with the Authentication Server.  This might be
    > a fairly simple scenario for, as an example, a set of nodes that are
    > charged nightly -- they could connect to the Authentication Server when
    > charging and be updated nightly.  In more adhoc situations, where nodes
    > could go days or months without reaching an authentication server, this
    > would be a much more difficult scenario to address well.

I'm not sure I understand why Zigbee is mentioned in this scenario.
I'm asking, because I'm not sure I understand what *Zigbee* brings that
changes the situation.   I think the critical point is that,  the AS has
pushed a policy to the node with the resource, indicating who could be
authorizated, but the nodes have to do the negotiation directly.

    > It seems to me that people who are considering the first model have a
    > different set of requirements and expectations than people who are
    > thinking of the second model, and when we talk about possible
    > solutions, different solution properties tend to work better for one
    > scenario than the other.

I don't think that many of us are considering the second scenario at all.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUBU1w+XYqHRg3pndX9AQJGaQQA4vqmiwIGRATBkm7N7wdSXOMViJKk3gTz
5CCXASTfPSPkaijFRfFnPSdNXljuPkMZ3ylspDc1FC0sCrOZtIJWrM8Vz560MzCf
ZbVXGF9dsuZ82H0PjDpCoqQsDCd0c0jcagkzmNYu1FEuCCdnj0JXZZvWgN3otMGX
ZoNZiP6y0gs=
=/xv6
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Apr 28 00:56: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 E997B1A08BF; Mon, 28 Apr 2014 00:56:33 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 4EB_c8CMDx1b; Mon, 28 Apr 2014 00:56:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id EFDCE1A0767; Mon, 28 Apr 2014 00:56:29 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Le5XQ-1XFAIc0Qge-00py3P; Mon, 28 Apr 2014 09:56:14 +0200
Message-ID: <535E08E6.2000803@gmx.net>
Date: Mon, 28 Apr 2014 09:53:10 +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: The IESG , Barry Leiba 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mmGltb4Pv2DEnFPgnPVgu0dQXJMILaS1u"
X-Provags-ID: V03:K0:uan6qBAviecw7QamZXFxFCEHPCDG09fYGYA1dxFRiBMQmk2UYId wz6a+GD6U71mCbRFck4r28gXdya1SjGp2kMgRumYNqnyHFge1AAMmMzBA3ubD3S+R345sw3 74vBZVtt+37QmytrSEonFuPtxA1jOyAwDtEpR/ykxXMFT90+RLef4gpc8tHxr+CAApdqKNZ KdBr1Hs9cCQ1OiyTdr1Iw==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1uY2q7LP9FaupXe-9hiWpdVNl6M
Cc: IESG Secretary , Kepeng Li <1095318589@qq.com>, Likepeng , "ace@ietf.org" 
Subject: [Ace] Request to form a WG on Authentication and Authorization for Constrained Environment (ACE)
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, 28 Apr 2014 07:56:34 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mmGltb4Pv2DEnFPgnPVgu0dQXJMILaS1u
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Dear IESG, Dear Barry,

at IETF#89 in London many IETF participants met to discuss potential new
work on authentication and authorization for constrained environments
and we received lots of positive feedback during the BOF, see
http://www.ietf.org/mail-archive/web/ace/current/msg00309.html

Following the IETF meeting we continued the charter discussions to
address various questions that surfaced during the BOF and you can find
the discussions at:
http://www.ietf.org/mail-archive/web/ace/current/maillist.html

We have concluded our charter discussions and would like to present the
outcome to the IESG as input for forming a new working group.

------

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

The IETF has recently developed protocols for use in constrained
environments, where network nodes are limited in CPU, memory and power.
It has been 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 environments. An example of
such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions
also arise in constrained environments. For example, a door lock has to
authorize the person seeking access using a "digital key". Where is the
authorization policy 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 temporarily granted to
other persons? How can access be revoked? These types of questions have
been answered by existing protocols for use cases outside constrained
environments, however in constrained environments, additional and
different requirements pose challenges for the use of various security
protocols. In particular, the need arises for a dynamic and fine grained
access control mechanism, where clients and/or resource servers are
constrained.

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 result from the
main deployment use cases they were designed for respectively.

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

This working group therefore aims to produce 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 at a resource server by a
client device takes place using CoAP and is protected by DTLS. Both
resource server and client may be constrained. This access will be
mediated by an authorization server, which is not considered to be
constrained.

Existing authentication and authorization protocols will be used and
re-applied for use in constrained environments where applicable. This
requires relevant specifications to be reviewed for suitability,
selecting a subset of them and restricting the options within each of
the specifications. Some functionality, however, may not be available in
existing protocols and thus new standardization efforts may be required.
Leveraging existing work means the working 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 constrained devices that
provide increased security.

Once progress in identifying suitable candidate solutions has been made,
the working group will verify whether the same mechanisms 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 deployments will be studied, particularly
concerning the use of protocol translation proxies.

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:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for
resource access in constrained environments.

Milestones:

Jul 2014 Submit =93Use cases and Requirements=94 as a WG item.
Dec 2014 Submit =93Authentication and Authorization Solution=94 as a WG i=
tem.
Jul 2015 Submit =93Use cases and Requirements=94 document to the IESG for=

publication as an Informational RFC.
Jul 2016 Submit =93Authentication and Authorization Solution=94
specification to the IESG for publication as a Proposed Standard.

------

Ciao
Hannes & Kepeng

Ciao
Hannes


--mmGltb4Pv2DEnFPgnPVgu0dQXJMILaS1u
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/

iQEcBAEBCgAGBQJTXgjnAAoJEGhJURNOOiAt600H/i963TY0mSWxDD3sdoeKohai
xsQMLY7CWCBWCx9bMkFBSLve/8FFqIHFSR86OpJi+5m6ULUJHJeuX/aNbbIQaK99
yJnyizyCD1dxXAvC9osHTfQ7v5tuP/XnT0Ri+/n0rtBAgQzhcgJULteja2jqdFD0
xZXMJzTr8Nb7sqdLMbrNWnVHfnzW0pwI5i7SKO1KxzETIcqGRT+raLB7btyrMCzt
n7Hq64d/wRfb7FWpn96HVBEy6rTK0FW8eHKTjlhXmTwQ8N8AQa1DN5vTHUia0d1n
mVJD/M5do5YCT3N4J0fgclZWqTMshPtQOD6Jv/JpgcVNRIQrqIgUul9IhFOmzWA=
=SpO5
-----END PGP SIGNATURE-----

--mmGltb4Pv2DEnFPgnPVgu0dQXJMILaS1u--


From nobody Mon Apr 28 01:08: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 D91171A0770 for ; Mon, 28 Apr 2014 01:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Level: 
X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651] 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 g1RIiiBU-dGS for ; Mon, 28 Apr 2014 01:08:41 -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 DFCEA1A08D8 for ; Mon, 28 Apr 2014 01:08:40 -0700 (PDT)
Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s3S87pKt016722 for ; Mon, 28 Apr 2014 10:08:39 +0200
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1k59wv64qf-1 for ; Mon, 28 Apr 2014 10:08:39 +0200
Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 5119540116 for ; Mon, 28 Apr 2014 10:08:39 +0200 (CEST)
Message-ID: <535E0C86.9070604@sics.se>
Date: Mon, 28 Apr 2014 10:08:38 +0200
From: Ludwig Seitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: ace@ietf.org
References: <42n7k6im62yd99tmy0jf8vek.1398507546397@email.android.com>
In-Reply-To: <42n7k6im62yd99tmy0jf8vek.1398507546397@email.android.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000808040301080508020905"
X-Proofpoint-Spam-Reason: safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-04-27_03:2014-04-25,2014-04-27,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/JBaHYR-CMCKVUuRF5R9P9Z3z2Ak
Subject: Re: [Ace] ACE pre-WG meeting
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, 28 Apr 2014 08:08:44 -0000

This is a cryptographically signed message in MIME format.

--------------ms000808040301080508020905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/26/2014 01:06 PM, Margaret Wasserman wrote:
> Hi Goran,
>
> Before you can talk meaningfully about some of the things you have
> mentioned for the problem statement, such as symmetric or assymmetric
> keys, I think it would be good to make sure we have agreement on the
> basic properties we need in a solution.  I am not sure we are all
> talking about mutually compatible scenarios.
>
> Some people seem to be thinking of a system, like a typical wifi
> network, irrigation controller, sensor network, distribution center, or=

> building control system, where the constrained nodees might talk
> directly to each other (both Client and Resource Provider may be
> constrained), but where it will be possible to reach a more capable
> a0Authentication Server (on the wifi AC, the controller, etc.) at the
> beginning of each session.  It is easy to see how you could add new
> nodes into a system like that, support removal of nodes, update keys et=
c.

Note that in some cases the nodes could talk directly to an AS, but not=20
at the same time as they have a secure session established between them. =

This is because establishing a second secure session in parallel to the=20
AS would require too much memory (or take too much time). So either they =

have to tear down and re-establish sessions (very expensive in terms of=20
round trips, time, and battery consumption) or the AS has to provide the =

client with some credentials before it goes on to contact the resource=20
server or the AS has to provide the resource server with access control=20
policies before the client connects to it.

How would that fit into the scenarios you describe?

/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


--------------ms000808040301080508020905
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
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MjgwODA4MzhaMCMGCSqGSIb3DQEJBDEW
BBRd9i4BybaVP5RAZmJZrF8KQyby+DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE
ggEARweFReoyRgWq/5dhbNHuN7e6gyKZs4muZ+ilFkKzniapcCvuTe0YpT3E+IFryxMrwuRZ
UWsEHmpdVcC4bRuiteqtuYexYReAp6QEanjdOjTY5IIxuYlSgzRBKJFnKgJSOkQWVxRwyG2h
RcQKX+gYkxV07lI3iHfFS0bhfhOnAqSxjxWkdMcCbKz3+C7v4zQhxQHxYlRsQ+y/OgaM845F
ff1Xwrqhote1Bf/MT0zdpFTf4J3pG2m6/uzqf0wie7MucYtp0dTOLs+pLMT8MBucAMzpxHL5
UKwv+ZLOP+bnry0Tsb9xeYDjY9StGJhSS/EOq+N0LseBS9Z0VEMfgl3oNwAAAAAAAA==
--------------ms000808040301080508020905--


From nobody Mon Apr 28 02:02: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 34C6D1A098A for ; Mon, 28 Apr 2014 02:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UcTxUJLQcZn8 for ; Mon, 28 Apr 2014 02:02:41 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7971A097C for ; Mon, 28 Apr 2014 02:02:40 -0700 (PDT)
X-AuditID: c1b4fb25-f798a6d000005ede-f2-535e192ec9f6
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A1.0F.24286.E291E535; Mon, 28 Apr 2014 11:02:39 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 11:02:37 +0200
From: =?windows-1254?Q?G=F6ran_Selander?= 
To: Margaret Wasserman , "ace@ietf.org" 
Thread-Topic: [Ace] ACE pre-WG meeting
Thread-Index: AQHPYT+T2nl1O2yRbUmKhf/QvGzt3psmvrMA
Date: Mon, 28 Apr 2014 09:02:37 +0000
Message-ID: 
References: <42n7k6im62yd99tmy0jf8vek.1398507546397@email.android.com>
In-Reply-To: <42n7k6im62yd99tmy0jf8vek.1398507546397@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_CF83D09E1009Bgoranselanderericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM+Jvja6+ZFywwbVlLBbfv/UwWzx4MY/J gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp49n8tW0HzKsaKnge72BsY9/YwdjFyckgI mEhMXfCLFcIWk7hwbz1bFyMXh5DAUUaJf9sPM0M4ixklXr9oZgOpYhNwl5izdyULiC0i4Cvx tuEnM4gtLKAq8XZePztEXE2i4+EeJgjbSOJZTzPYBhagmkfrd4DN4RWwkLh8Yz/QHA6gBW4S p9orQMKcQOM3vH4MVsIIdND3U2vAxjALiEvcejKfCeJQAYkle84zQ9iiEi8f/wMbLyqgJ/Hu OEgNB1BcUWJ5vxxEa6zElgMdUFsFJU7OfMIygVF0FpKps5CUzUJSBhE3kDhy7iYrhK0tsWzh a2YIW19i3oINUDXWEjPuH2VCVrOAkWMVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmAkHtzy W3UH4+U3jocYBTgYlXh4i79EBguxJpYVV+YeYpTmYFES5/1yyydYSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA6PsG9YnFzaH3t2S67yqcOZPNs90I5memq+znkmf+rskvtne7WSEP6PfXua9 BxhbdzjbC26RSGPmOLtFZ0fAmZLOdLubccVfm3mf3ld81iOd43ruuMXisJ6oJlPLrqdOc5ry Tn16N2X5R79dr7gvB13Vns1XeX+mzZnpExds+/mT3/ZgVMnEo/eVWIozEg21mIuKEwGOdwVJ pQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/LRI_8O4oX332yYNHyXFsYXtMq8o
Subject: Re: [Ace] ACE pre-WG meeting
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, 28 Apr 2014 09:02:45 -0000

--_000_CF83D09E1009Bgoranselanderericssoncom_
Content-Type: text/plain; charset="windows-1254"
Content-Transfer-Encoding: quoted-printable

Hi Margaret

I was considering what you call >>basic properties>> to be part of a proble=
m statement (>>support for intermittent connectivity>> was listed as an exa=
mple), so thanks for kicking off the discussion! As you say, it may well be=
 that people have different settings in mind - and there may be more differ=
ences than what you bring up  - how would we know until we have written dow=
n the assumptions in more detail?

I=92m not sure we need to agree on anything at this stage, but I agree that=
 we need to make clear any difference in assumptions so that we have a disc=
ussion around how to handle that (e.g. if there are differences in assumpti=
ons whether only one case should be supported or if multiple cases should b=
e allowed).

In the same way I find it difficult at this stage to judge what is >>well-e=
nough understood =85 to be an engineering problem >>  but that is a good qu=
estion once the problem statement(s) are on the a table, and a potential to=
pic for a f2f meeting.

Some comments inline.


From: Margaret Wasserman >
Reply-To: Margaret Wasserman >
Date: Saturday 26 April 2014 13:06
To: G=F6ran Selander >, "ace@ietf.org" >
Subject: Re: [Ace] ACE pre-WG meeting

Hi Goran,

Before you can talk meaningfully about some of the things you have mentione=
d for the problem statement, such as symmetric or assymmetric keys, I think=
 it would be good to make sure we have agreement on the basic properties we=
 need in a solution.  I am not sure we are all talking about mutually compa=
tible scenarios.

Some people seem to be thinking of a system, like a typical wifi network, i=
rrigation controller, sensor network, distribution center, or building cont=
rol system, where the constrained nodees might talk directly to each other =
(both Client and Resource Provider may be constrained), but where it will b=
e possible to reach a more capable a0Authentication Server (on the wifi AC,=
 the controller, etc.) at the beginning of each session.  It is easy to see=
 how you could add new nodes into a system like that, support removal of no=
des, update keys etc.

Others seem to be looking at a more adhoc scenario, perhaps Zigbee-based, w=
here nodes may be intermittently connected, and two constrained nodes may n=
eed to authenticate and authorize oneanother when there may be no other rea=
chable nodes. In this case, the Authentication Server would be more of a pr=
ovisioning system that pushes security policies and credentials to the cons=
trained nodes when possible.  In this scenario, nodes will only become awar=
e of changes (additional nodes in the system, removal of nodes, key changes=
) after sufficient connectivity with the Authentication Server.  This might=
 be a fairly simple scenario for, as an example, a set of nodes that are ch=
arged nightly -- they could connect to the Authentication Server when charg=
ing and be updated nightly.  In more adhoc situations, where nodes could go=
 days or months without reaching an authentication server, this would be a =
much more difficult scenario to address well.

It seems to me that people who are considering the first model have a diffe=
rent set of requirements and expectations than people who are thinking of t=
he second model, and when we talk about possible solutions, different solut=
ion properties tend to work better for one scenario than the other.

What are the differences between these scenarios in your view?

  *   Intermittent connectivity is assumed in the second and not in the fir=
st.
  *   Policy decision made in the AS in the first scenario, but not in the =
second.
  *   Other differences?

Can we make more precise what assumptions you think we should make? (maybe =
implied by the answer to the previous question)

G=F6ran




I think it might be useful to walk through these two scenarios and see what=
 the requirements, expectations and desirable properties are in each scenar=
io.  When we are done understanding their requirements, etc. we could deter=
mine if the superset of those needs could be met by a single solution that =
would provide a satisfactory experience in both cases. I am concerned that =
the two scenarios may not have enough in common to be served by a single so=
lution.

IMO, the first case could be reasonably addressed by modifications to exist=
ing IETF protocols to consider the properties of constrained Clients and Re=
source Servers.  We would attempt to reduce communication overhead on the c=
onstrained nodes, and offload storage and processing overhead to the Authen=
tication Server.  I personally see the work necessary to deal with the firs=
t scenario to be fairly clear and simply a matter of engineering.

I am less certain how existing IETF protocols could be applied to the secon=
d case, which I see as more of a provisioning scenario than a matter of off=
loading. There are numerous problems that could arise when/if some nodes ar=
e updated and others are not, etc.  There might be several subsets of this =
scenario based on application needs (I.e. Is it even possible to require th=
at nodes be brought into contact with the Authentication Server when they a=
re found to have out-of-date information?).  IMO, the requirements of this =
scenario are not well-enough understood to begin by designing a solution.  =
If we want to cover this case, I would prefer to see more work done on unde=
rstanding the properties and requirements of systems that fall into this ca=
tegory before we begin to design solutions.  I am concerned that the needs =
of this scenario (or these scenarios) may not be well-enough understood for=
 this to be an engineering problem at this point.

Margaret



-------- Original message --------
>From G=F6ran Selander >
Date: 04/25/2014 3:03 AM (GMT-05:00)
To ace@ietf.org
Subject Re: [Ace] ACE pre-WG meeting



I got some questions offline about this f2f interim meeting and how it is
supposed to work.

Here is what I had in mind:

1. We try to fix a date for a 1-day meeting in about 5-6 weeks.

2. Before this meeting, people are invited to submit proposals of a more
detailed problem statement of ACE. With =B3more detailed problem statement=
=B2
I mean for example properties of security protocols between nodes that a
solution should exhibit or support, e.g. whether symmetric and/or
asymmetric keys should be supported, whether negotiation of crypto suite
should be supported, support for intermittent connectivity, round trips,
processing or caching requirements etc.

The input could be in the form of mails to the ACE list, internet drafts,
or something in-between e.g. using some repository for documents. (There
will be at least one detailed input.)

3. We meet and discuss the different proposals and try to agree on a more
detailed problem statement, and then report back to the ACE list.

The reason for proposing a 1-day meeting is based on the assumption that
people have read the inputs and we can go directly to the things people
disagree on and hear the motivations (not necessarily coming to an
agreement). But I don=B9t have a strong opinion about that.

Phone conference facilities could always be considered, but the intent
with such a f2f meeting is to give a chance to brainstorm, draw and
discuss pictures on a white board, etc.

What do you think about this?


G=F6ran




On 24/04/14 10:24, "G=F6ran Selander" > wrote:

>
>Hi all,
>
>As was noted in the tutorial session this week, and previously in the
>charter discussions, neither the ACE charter nor the use case &
>requirements document provides sufficiently detailed problem statement to
>be able to evaluate candidate security protocols.
>
>The option to meet face to face and discuss the scope of ACE has been
>aired on several occasions. In an recent offline discussion I got a
>positive feedback about trying to arrange a meeting before Toronto. The
>purpose of the meeting would be to discuss - and hopefully produce - a
>more detailed problem statement proposal as input to the ACE work.
>
>A good time could be end-of-May / beginning-of-June to allow for travel
>arrangements and still leave enough time for editing drafts based on the
>output.
>
>One possible location for this meeting is at the Ericsson premises in
>Kista out of Stockholm, Sweden. Kista is a short ride from airports
>Arlanda and Bromma.
>
>For those interested in attending, please fill in this Doodle ASAP:
>
>http://doodle.com/nw94ruh77fg3qvfg
>
>
>Please note that this would not be an official interim meeting, as ACE is
>not a WG yet.
>
>
>
>G=F6ran
>
>
>

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

--_000_CF83D09E1009Bgoranselanderericssoncom_
Content-Type: text/html; charset="windows-1254"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Margaret







I was considering what you call >>basic properties>> to be=
 part of a problem statement (>>support for intermittent connectivity=
>> was listed as an example), so thanks for kicking off the discussio=
n! As you say, it may well be that people have different
 settings in mind - and there may be more differences than what you bring u=
p  - how would we know until we have written down the assumptions in m=
ore detail? 







I=92m not sure we need to agree on anything at this stage, but I agree=
 that we need to make clear any difference in assumptions so that we have a=
 discussion around how to handle that (e.g. if there are differences in ass=
umptions whether only one case should
 be supported or if multiple cases should be allowed). 







In the same way I find it difficult at this stage to judge what is >=
;>well-enough understood =85 to be an engineering problem >>  =
;but that is a good question once the problem statement(s) are on the a tab=
le, and a potential topic for a f2f meeting.







Some comments inline.














From: Margaret Wasserman <margaretw42@gmail.com>

Reply-To: Margaret Wasserman <margaretw42@gmail.com>

Date: Saturday 26 April 2014 13:06<=
br>
To: G=F6ran Selander <goran.selander@ericsson.com>, &=
quot;ace@ietf.org" <ace@ietf.org>

Subject: Re: [Ace] ACE pre-WG meeti=
ng













Hi Goran,






Before you can talk meaningfully about some of the things you have men=
tioned for the problem statement, such as symmetric or assymmetric keys, I =
think it would be good to make sure we have agreement on the basic properti=
es we need in a solution.  I am
 not sure we are all talking about mutually compatible scenarios.







Some people seem to be thinking of a system, like a typical wifi netwo=
rk, irrigation controller, sensor network, distribution center, or building=
 control system, where the constrained nodees might talk directly to each o=
ther (both Client and Resource Provider
 may be constrained), but where it will be possible to reach a more capable=
 a0Authentication Server (on the wifi AC, the controller, etc.) at the begi=
nning of each session.  It is easy to see how you could add new nodes =
into a system like that, support removal
 of nodes, update keys etc.







Others seem to be looking at a more adhoc scenario, perhaps Zigbee-bas=
ed, where nodes may be intermittently connected, and two constrained nodes =
may need to authenticate and authorize oneanother when there may be no othe=
r reachable nodes. In this case,
 the Authentication Server would be more of a provisioning system that push=
es security policies and credentials to the constrained nodes when possible=
.  In this scenario, nodes will only become aware of changes (addition=
al nodes in the system, removal of nodes,
 key changes) after sufficient connectivity with the Authentication Server.=
  This might be a fairly simple scenario for, as an example, a set of =
nodes that are charged nightly -- they could connect to the Authentication =
Server when charging and be updated nightly.
  In more adhoc situations, where nodes could go days or months withou=
t reaching an authentication server, this would be a much more difficult sc=
enario to address well.







It seems to me that people who are considering the first model have a =
different set of requirements and expectations than people who are thinking=
 of the second model, and when we talk about possible solutions, different =
solution properties tend to work
 better for one scenario than the other.














What are the differences between these scenarios in your view?


    

  • Intermittent connectivity is assumed in the second and not in the first=
.
  • Policy decision made in the AS in the first scenario, but not in =
the second.
  • Other differences?


Can we make more precise what assumptions you think we should make? (m=
aybe implied by the answer to the previous question)







G=F6ran





























I think it might be useful to walk through these two scenarios and see=
 what the requirements, expectations and desirable properties are in each s=
cenario.  When we are done understanding their requirements, etc. we c=
ould determine if the superset of those
 needs could be met by a single solution that would provide a satisfactory =
experience in both cases. I am concerned that the two scenarios may not hav=
e enough in common to be served by a single solution.  







IMO, the first case could be reasonably addressed by modifications to =
existing IETF protocols to consider the properties of constrained Clients a=
nd Resource Servers.  We would attempt to reduce communication overhea=
d on the constrained nodes, and offload
 storage and processing overhead to the Authentication Server.  I pers=
onally see the work necessary to deal with the first scenario to be fairly =
clear and simply a matter of engineering.







I am less certain how existing IETF protocols could be applied to the =
second case, which I see as more of a provisioning scenario than a matter o=
f offloading. There are numerous problems that could arise when/if some nod=
es are updated and others are not,
 etc.  There might be several subsets of this scenario based on applic=
ation needs (I.e. Is it even possible to require that nodes be brought into=
 contact with the Authentication Server when they are found to have out-of-=
date information?).  IMO, the requirements
 of this scenario are not well-enough understood to begin by designing a so=
lution.  If we want to cover this case, I would prefer to see more wor=
k done on understanding the properties and requirements of systems that fal=
l into this category before we begin
 to design solutions.  I am concerned that the needs of this scen=
ario (or these scenarios) may not be well-enough understood for this to be =
an engineering problem at this point.







Margaret







-------- Original message --------

>From G=F6ran Selander <go=
ran.selander@ericsson.com>


Date: 04/25/2014 3:03 AM (GMT-05:00) 

To ace@ietf.org 

Subject Re: [Ace] ACE pre-WG meeting 







I got some questions offline about this f2f interim meeting and how it is
supposed to work. 



Here is what I had in mind:



1. We try to fix a date for a 1-day meeting in about 5-6 weeks.



2. Before this meeting, people are invited to submit proposals of a more
detailed problem statement of ACE. With =B3more detailed problem statement=
=B2

I mean for example properties of security protocols between nodes that a
solution should exhibit or support, e.g. whether symmetric and/or

asymmetric keys should be supported, whether negotiation of crypto suite
should be supported, support for intermittent connectivity, round trips,
processing or caching requirements etc.



The input could be in the form of mails to the ACE list, internet drafts,
or something in-between e.g. using some repository for documents. (There
will be at least one detailed input.)



3. We meet and discuss the different proposals and try to agree on a more
detailed problem statement, and then report back to the ACE list.



The reason for proposing a 1-day meeting is based on the assumption that
people have read the inputs and we can go directly to the things people

disagree on and hear the motivations (not necessarily coming to an

agreement). But I don=B9t have a strong opinion about that.



Phone conference facilities could always be considered, but the intent

with such a f2f meeting is to give a chance to brainstorm, draw and

discuss pictures on a white board, etc.



What do you think about this?





G=F6ran









On 24/04/14 10:24, "G=F6ran Selander" <goran.selander@ericsson.com> wrote:



>

>Hi all,

>

>As was noted in the tutorial session this week, and previously in the
>charter discussions, neither the ACE charter nor the use case &

>requirements document provides sufficiently detailed problem statement =
to

>be able to evaluate candidate security protocols.

>

>The option to meet face to face and discuss the scope of ACE has been
>aired on several occasions. In an recent offline discussion I got a

>positive feedback about trying to arrange a meeting before Toronto. The=


>purpose of the meeting would be to discuss - and hopefully produce - a<=
br>
>more detailed problem statement proposal as input to the ACE work.

>

>A good time could be end-of-May / beginning-of-June to allow for travel=


>arrangements and still leave enough time for editing drafts based on th=
e

>output.  

>

>One possible location for this meeting is at the Ericsson premises in
>Kista out of Stockholm, Sweden. Kista is a short ride from airports

>Arlanda and Bromma.

>

>For those interested in attending, please fill in this Doodle ASAP:

>

>http://doodle.com/nw94ru=
h77fg3qvfg

>

>

>Please note that this would not be an official interim meeting, as ACE =
is

>not a WG yet.

>

>

>

>G=F6ran

>

>

>



_______________________________________________

Ace mailing list

Ace@ietf.org

https://www.ietf.org/=
mailman/listinfo/ace











--_000_CF83D09E1009Bgoranselanderericssoncom_--


From nobody Mon Apr 28 06:11: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 411581A09F8; Mon, 28 Apr 2014 06:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 Rl6NPMK2foJZ; Mon, 28 Apr 2014 06:10:57 -0700 (PDT)
Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2BE1A078F; Mon, 28 Apr 2014 06:10:57 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id l6so5917052qcy.38 for ; Mon, 28 Apr 2014 06:10:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3O68MpqHOIYzAkBOI1UzRHWBnUnMz4yzYXOz8KXyu+U=; b=skug6xn7Ohj1Gh6104q+SGA+zh/G7Yr5cw4OUGQi6lEELP4UZG1FrBsJR9uzchAP6A YClu2xZ+T27WPkjr4YWlCE96d9qmyVLPL2bp7VlPWst+RuT8b/44ItrBXTS0auU87qcs pUW/RDfMsduzFHrYk5ISUr60MwzRWbuZ1E9E85KcCeGbv5aXbDI9gqEIdiWJANSlYDQK SivTkAcuMcP/RUTPbVPII/urG21He+hnWR0Z9sSOfHkFWLbAztSoJWiHXZNE3A4E4zCZ 6Z7c3EeCjx34DeC5vqggD/IAIxd8GHNPvKDlalTj3OVXrLGRaEYB60hzb6DEqTrjqDGc soSA==
MIME-Version: 1.0
X-Received: by 10.224.166.9 with SMTP id k9mr13834150qay.25.1398690656322; Mon, 28 Apr 2014 06:10:56 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.136.134 with HTTP; Mon, 28 Apr 2014 06:10:56 -0700 (PDT)
In-Reply-To: <535E08E6.2000803@gmx.net>
References: <535E08E6.2000803@gmx.net>
Date: Mon, 28 Apr 2014 09:10:56 -0400
X-Google-Sender-Auth: Fut9xUCdW4umMtuP-zj9yq_UPAo
Message-ID: 
From: Barry Leiba 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/pnZd6ssUaSgfcb2p4Wz1HQR3iBc
Cc: Kepeng Li <1095318589@qq.com>, IAB , The IESG , Likepeng , "ace@ietf.org" 
Subject: Re: [Ace] Request to form a WG on Authentication and Authorization for Constrained Environment (ACE)
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, 28 Apr 2014 13:10:58 -0000

I have begun the chartering process, and the charter is now in
"Informal Review" state, for comment by the IAB and IESG:
https://datatracker.ietf.org/doc/charter-ietf-ace/

Timeline:
The next formal IESG telechat is on 15 May, and I've put it on the
agenda for that telechat.  Its state will change to "Internal Review"
before then.  If it's approved for external review (the IETF and
broader SDO community) then, it will be back on the 29 May telechat
for possible final approval.

During the chartering process, we'll have to decide whether this
belongs in the App Area or the Sec Area, and I specifically ask the
IAB and IESG to comment on that during review.  For now, I'm holding
the token on it.

Barry


From nobody Mon Apr 28 09:51: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 C4C5A1A6F2D for ; Mon, 28 Apr 2014 09:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.414
X-Spam-Level: 
X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 Zu9itaeheSoB for ; Mon, 28 Apr 2014 09:51:44 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D84BA1A09B7 for ; Mon, 28 Apr 2014 09:51:44 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s3SGpUe0016398; Mon, 28 Apr 2014 10:51:30 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 28 Apr 2014 10:51:29 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 10:51:30 -0600
From: Seetharama Rao Durbha 
To: Margaret Wasserman , "robert.cragie@gridmerge.com" , Hannes Tschofenig , Rene Struik 
Thread-Topic: [Ace] Last Call for Comments on ACE Charter Text
Thread-Index: AQHPYUD5/Of6W2HJ40Ctz+97jSAg7psnQbOA
Date: Mon, 28 Apr 2014 16:51:29 +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.4.1.140326
x-originating-ip: [10.4.10.16]
Content-Type: multipart/alternative; boundary="_000_CF83E22B1548Fsdurbhacablelabscom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/aV0FadHVxj026dt6PRTiwYbNrbU
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 28 Apr 2014 16:51:46 -0000

--_000_CF83E22B1548Fsdurbhacablelabscom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi Robert,

One question for the WG based on your comments on the charter text:

Would we be okay with a solution that only works for REST-based application=
s, or will we also need to secure any other sorts of communication between =
Clients and Resource Servers?

Firstly, I am a newcomer to this group =96 so, hello to everyone. I only re=
cently started following this group actively, but am very much interested i=
n the area.

Just on the issue of 'a solution that only works for REST-based application=
s', in my mind, we have to first define the properties  and parameters for =
a secure communication independent of the transport protocol, and then crea=
te mappings for individual protocols. So there needs to be a 'core' specifi=
cation, and then related specifications for mappings/profiles.

--Seetharama Durbha
Lead Security Architect
CableLabs


Margaret




-------- Original message --------
>From Robert Cragie >
Date: 04/15/2014 11:53 AM (GMT-05:00)
To Hannes Tschofenig >,Rene Struik >
Cc ace@ietf.org
Subject Re: [Ace] Last Call for Comments on ACE Charter Text


A couple of small comments inline. I am OK with the rest of the changes.

Robert

On 14/04/2014 1:25 PM, Hannes Tschofenig wrote:
> Hi Rene,
>
> thanks for the review comments. I have updated the charter text according=
ly.
>
> A few remarks inline:
>
>
> Gesendet: Donnerstag, 10. April 2014 um 22:58 Uhr
> Von: "Rene Struik" >
> An: "Hannes Tschofenig" >, "ace@ietf.org" >
> Betreff: Re: [Ace] Last Call for Comments on ACE Charter Text
>
> Hi Hannes:
>
> I had a look at the charter text. I do agree with the two tasks identifie=
d in the charter.
>
> I do have some some comments on the (rather lengthy) prelude to the enume=
ration of these two tasks. These comments do not matter if the group agrees=
 that the charter does not try and steer into a particular solution directi=
on (as some comments on the list have indeed suggested to be the case). My =
comments are worded in case this is not so.
>
> Small comments:
> a) 2nd para, l. 3: replace "authorization decisions" by "authorization cr=
iteria" or "authorization policy". After all, decisions are not stored, but=
 acted upon.
>
> [hannes] Fixed.
I have no particular issue with the change but I think it was OK as
it was, as an authorization *policy* can often be static, therefore not
requiring storage. Decisions certainly are stored and form the basis for
access control.
>
> b) 2nd para, l. -1: replace "resource server" by "resource owner", "resou=
rce holder", or similar. This would make it clearer that the "server" is th=
e device that actually stores the info the client is soliciting.
>
> [hannes] I changed the wording to make clear that we are talking about th=
e server that is holding the resource.
The way it is written now could read that clients can hold
resources - not the case in a REST architecture. Again, I thought it was
OK as it way


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

--_000_CF83E22B1548Fsdurbhacablelabscom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable

















Hi Robert, 






One question for the WG based on your comments on the charter text:






Would we be okay with a solution that only works for REST-based applic=
ations, or will we also need to secure any other sorts of communication bet=
ween Clients and Resource Servers?














Firstly, I am a newcomer to this group =96 so, hello to everyone. I on=
ly recently started following this group actively, but am very much interes=
ted in the area.







Just on the issue of 'a solution that only works for REST-based applic=
ations', in my mind, we have to first define the properties  and param=
eters for a secure communication independent of the transport protocol, and=
 then create mappings for individual
 protocols. So there needs to be a 'core' specification, and then related s=
pecifications for mappings/profiles.







--Seetharama Durbha


Lead Security Architect


CableLabs



















Margaret












-------- Original message --------

>From Robert Cragie <rober=
t.cragie@gridmerge.com>


Date: 04/15/2014 11:53 AM (GMT-05:00) 

To Hannes Tschofenig <Hanne=
s.Tschofenig@gmx.net>,Rene Struik <rstruik.ext@gmail.com>


Cc ace@ietf.org 

Subject Re: [Ace] Last Call for Comments on ACE Charter Text 





A couple of small comments inline. I am OK with the rest of the changes.


Robert



On 14/04/2014 1:25 PM, Hannes Tschofenig wrote:

> Hi Rene,

>   

> thanks for the review comments. I have updated the charter text accord=
ingly.

>   

> A few remarks inline:

>   

>

> Gesendet: Donnerstag, 10. April 2014 um 22:58 Uhr

> Von: "Rene Struik" <rstruik.ext@gmail.com>

> An: "Hannes Tschofenig" <hannes.tschofenig@gmx.net>, "ace@ietf.org" <ace@i=
etf.org>

> Betreff: Re: [Ace] Last Call for Comments on ACE Charter Text

>

> Hi Hannes:

>

> I had a look at the charter text. I do agree with the two tasks identi=
fied in the charter.

>

> I do have some some comments on the (rather lengthy) prelude to the en=
umeration of these two tasks. These comments do not matter if the group agr=
ees that the charter does not try and steer into a particular solution dire=
ction (as some comments on the list
 have indeed suggested to be the case). My comments are worded in case this=
 is not so.

>

> Small comments:

> a) 2nd para, l. 3: replace "authorization decisions" by &quo=
t;authorization criteria" or "authorization policy". After a=
ll, decisions are not stored, but acted upon.

>   

> [hannes] Fixed.

<RCC>I have no particular issue with the change but I think it was OK=
 as 

it was, as an authorization *policy* can often be static, therefore not 
requiring storage. Decisions certainly are stored and form the basis for 
access control.</RCC>

>   

> b) 2nd para, l. -1: replace "resource server" by "resou=
rce owner", "resource holder", or similar. This would make i=
t clearer that the "server" is the device that actually stores th=
e info the client is soliciting.

>

> [hannes] I changed the wording to make clear that we are talking about=
 the server that is holding the resource.

<RCC>The way it is written now could read that clients can hold 

resources - not the case in a REST architecture. Again, I thought it was 
OK as it way</RCC>





_______________________________________________

Ace mailing list

Ace@ietf.org

https://www.ietf.org/=
mailman/listinfo/ace











--_000_CF83E22B1548Fsdurbhacablelabscom_--


From nobody Mon Apr 28 10: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 700A61A6F9B for ; Mon, 28 Apr 2014 10:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 UAWKy37kBPab for ; Mon, 28 Apr 2014 10:28:58 -0700 (PDT)
Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 66D941A6F68 for ; Mon, 28 Apr 2014 10:28:58 -0700 (PDT)
Received: by mail-oa0-f53.google.com with SMTP id j17so7700647oag.12 for ; Mon, 28 Apr 2014 10:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GNdXE3FgUkK6Kn4a/Zco5N8UvkBKG/LsvQ4fpASCXRA=; b=BxnzMjNIpyI5c/l9skk/qyj/qNOKD6tuavK0BjYqCThejKCVv6WJk8wHC4AwR01nBg KtntpquL7X/X01Whf5ilyyij+ir1RBzFpqJrRyKHSngE2bdh4MyhBQXlY+RrnndJLpWp bhLmkHExFViWPTpnZxcfe9Li4sGQ4NI2XEXhhABfLcRU2TOZq6gmZQrdvoxazlVWPMyt 0buUZJFxPHCLDc9u9eRj/Zb6QLHX3m9HRKNJPNxA4dBoE4VFTWhOgFSP4Utg3YJfO7sS 9nWPgK/cfI+1EC4c8rmfKXZTyLJlBZnkvDxI3cJM4A49K7W7nbSVmC46T3Z3gPRnE+EI 4nOQ==
MIME-Version: 1.0
X-Received: by 10.60.157.202 with SMTP id wo10mr23570804oeb.9.1398706137587; Mon, 28 Apr 2014 10:28:57 -0700 (PDT)
Sender: robert.cragie@gmail.com
Received: by 10.76.141.68 with HTTP; Mon, 28 Apr 2014 10:28:57 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 28 Apr 2014 18:28:57 +0100
X-Google-Sender-Auth: EukxUkJyCaTex-wtgdOKOeerPGw
Message-ID: 
From: Robert Cragie 
To: Margaret Wasserman 
Content-Type: multipart/alternative; boundary=047d7bd6c5e879e42a04f81da64a
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/jr7LqpaSLyXFsJU6yKJbNo4Pr70
Cc: Hannes Tschofenig , Rene Struik , "ace@ietf.org" 
Subject: Re: [Ace] Last Call for Comments on ACE Charter Text
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, 28 Apr 2014 17:29:01 -0000

--047d7bd6c5e879e42a04f81da64a
Content-Type: text/plain; charset=UTF-8

Hi Margaret,

The idea is to use REST-based applications as a starting point, which is
the language used in the charter. The charter does also say that "the
working group will verify whether the same mechanisms are also applicable
beyond the use of CoAP and DTLS". So I would say it is not restricted to
REST-based applications.

Robert


On 26 April 2014 12:14, Margaret Wasserman  wrote:

> Hi Robert,
>
> One question for the WG based on your comments on the charter text:
>
> Would we be okay with a solution that only works for REST-based
> applications, or will we also need to secure any other sorts of
> communication between Clients and Resource Servers?
>
> Margaret
>
>
>
>
> -------- Original message --------
> From Robert Cragie 
> Date: 04/15/2014 11:53 AM (GMT-05:00)
> To Hannes Tschofenig ,Rene Struik <
> rstruik.ext@gmail.com>
> Cc ace@ietf.org
> Subject Re: [Ace] Last Call for Comments on ACE Charter Text
>
>
> A couple of small comments inline. I am OK with the rest of the changes.
>
> Robert
>
> On 14/04/2014 1:25 PM, Hannes Tschofenig wrote:
> > Hi Rene,
> >
> > thanks for the review comments. I have updated the charter text
> accordingly.
> >
> > A few remarks inline:
> >
> >
> > Gesendet: Donnerstag, 10. April 2014 um 22:58 Uhr
> > Von: "Rene Struik" 
> > An: "Hannes Tschofenig" , "ace@ietf.org" <
> ace@ietf.org>
> > Betreff: Re: [Ace] Last Call for Comments on ACE Charter Text
> >
> > Hi Hannes:
> >
> > I had a look at the charter text. I do agree with the two tasks
> identified in the charter.
> >
> > I do have some some comments on the (rather lengthy) prelude to the
> enumeration of these two tasks. These comments do not matter if the group
> agrees that the charter does not try and steer into a particular solution
> direction (as some comments on the list have indeed suggested to be the
> case). My comments are worded in case this is not so.
> >
> > Small comments:
> > a) 2nd para, l. 3: replace "authorization decisions" by "authorization
> criteria" or "authorization policy". After all, decisions are not stored,
> but acted upon.
> >
> > [hannes] Fixed.
> I have no particular issue with the change but I think it was OK as
> it was, as an authorization *policy* can often be static, therefore not
> requiring storage. Decisions certainly are stored and form the basis for
> access control.
> >
> > b) 2nd para, l. -1: replace "resource server" by "resource owner",
> "resource holder", or similar. This would make it clearer that the "server"
> is the device that actually stores the info the client is soliciting.
> >
> > [hannes] I changed the wording to make clear that we are talking about
> the server that is holding the resource.
> The way it is written now could read that clients can hold
> resources - not the case in a REST architecture. Again, I thought it was
> OK as it way
>
>
> _______________________________________________
> 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
>
>

--047d7bd6c5e879e42a04f81da64a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Margaret,

The idea is to use REST-ba=
sed applications as a starting point, which is the language used in the cha=
rter. The charter does also say that=C2=A0"the working group will veri=
fy whether the same mechanisms are also applicable beyond the use of CoAP a=
nd DTLS". So I would say it is not restricted to REST-based applicatio=
ns.



Robert


On 26 April 2014 12:14, Margaret Wasserman <m=
argaretw42@gmail.com> wrote:


Hi Robert,=C2=A0

One=
 question for the WG based on your comments on the charter text:
=



Would we be okay with a solution that only works for REST-based applic=
ations, or will we also need to secure any other sorts of communication bet=
ween Clients and Resource Servers?

Margaret






-------- Original message --------
From Rober=
t Cragie <robert.cragie@gridmerge.com> 
Date: 04/15/2014  11:53 AM  (GMT=
-05:00) 

To Hannes Tschofenig <Hannes.Tschofenig@gmx.net>,Rene Struik <rstruik.ext@gmail.com>=
; 

Cc ace@ietf.org 
S=
ubject Re: [Ace] Last Call for Comments on ACE Charter Text 
 

A couple of small comments inline. I am OK with the rest of =
the changes.


Robert

On 14/04/2014 1:25 PM, Hannes Tschofenig wrote:
> H=
i Rene,
>=C2=A0=C2=A0 
> thanks for the review comments. I have=
 updated the charter text accordingly.
>=C2=A0=C2=A0 
> A few r=
emarks inline:

>=C2=A0=C2=A0 
>
> Gesendet: Donnersta=
g, 10. April 2014 um 22:58 Uhr
> Von: "Rene Struik" <rstruik.ext@gmail.c=
om>

> An: "Hannes Tschofenig" <hannes.tschofenig@gmx.net>, "ace@ietf.org" <<=
a href=3D"mailto:ace@ietf.org" target=3D"_blank">ace@ietf.org>

> Betreff: Re: [Ace] Last Call for Comments on ACE Charter Text
><=
br>> Hi Hannes:
>
> I had a look at the charter text. I do a=
gree with the two tasks identified in the charter.
>
> I do hav=
e some some comments on the (rather lengthy) prelude to the enumeration of =
these two tasks. These comments do not matter if the group agrees that the =
charter does not try and steer into a particular solution direction (as som=
e comments on the list have indeed suggested to be the case). My comments a=
re worded in case this is not so.

>
> Small comments:
> a) 2nd para, l. 3: replace "autho=
rization decisions" by "authorization criteria" or "aut=
horization policy". After all, decisions are not stored, but acted upo=
n.

>=C2=A0=C2=A0 
> [hannes] Fixed.
<RCC&=
gt;I have no particular issue with the change but I think it was OK as 
=
it was, as an authorization *policy* can often be static, therefore not requiring storage. Decisions certainly are stored and form the basis for <=
br>
access control.</RCC>
>=C2=A0=C2=A0 
&=
gt; b) 2nd para, l. -1: replace "resource server" by "resour=
ce owner", "resource holder", or similar. This would make it=
 clearer that the "server" is the device that actually stores the=
 info the client is soliciting.

>
> [hannes] I changed the wording to make clear that we are talki=
ng about the server that is holding the resource.
<RCC>The way it =
is written now could read that clients can hold 
resources - not the cas=
e in a REST architecture. Again, I thought it was 

OK as it way</RCC>


_______________________________________=
________
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





--047d7bd6c5e879e42a04f81da64a--