From nobody Wed Apr 1 00:48:55 2015 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 AC9F41A8A43 for ; Wed, 1 Apr 2015 00:48:53 -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 6hyM58XsFqKO for ; Wed, 1 Apr 2015 00:48:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F061A8A46 for ; Wed, 1 Apr 2015 00:48:51 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MCtLD-1Yl9bW1URf-009csp for ; Wed, 01 Apr 2015 09:48:49 +0200 Message-ID: <551BA2E0.6090205@gmx.net> Date: Wed, 01 Apr 2015 09:48:48 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qrnhUIhD0SU2iIo3kEWu5UOgvp4P71fwC" X-Provags-ID: V03:K0:SUopweQEG3qYES6O+FHJWWgKweuyXrOb6eJ1/Rzcq/dx7i4Dwks WzXNVeS8fYzJbA5/xF5jTZcxcilkOtiQOUPlV0gOs8M3GFn+BSad104SfGBSShq7M2v8wkX 3rscJe9Xv02wZu79em9i6dtVaN3t4chOPLPBv8b5+4S51kgYNPpca/bXij0gUDQ1WBc9S82 hkO3mFhPNR9AyMbBeXe7A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 07:48:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qrnhUIhD0SU2iIo3kEWu5UOgvp4P71fwC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here are some short notes from the ACE meeting: --------------------- ACE WG Meeting IETF 92 - Dallas Tuesday 24 March 2015, 13:00 - 15:00 CDT Chairs: Kepeng Li, Hannes Tschofenig * Use Cases (Sandeep S. Kumar) - No open issues. Next step is to initiate WGLC. Five people volunteered to review the draft (Carsten, Dominique, Raj, Steve, Nguyen) * Problem Description (Goeran Selander) - The term "Configuration Server" needs to be checked. - There was consensus to use problem description and terminology as a starting point to work on. * Actors (Carsten Bormann, 20 mins) - There was preference to reuse OAuth terminologies (e.g. Resource Server, Authorization Server). - Action: Design team is requested to merge Problem Description draft and Actors draft, and provide a combined draft. * Delegated CoAP Authentication and Authorization Framework (Carsten Bormann) - No time for the detailed discussion. It is recommended to provide feedback in the mailing list. * Object Security (Goeran Selander) - There was comment that part of the work should be done in CORE. - There was comment that it depends on COSE work. - No consensus to adopt it this time. More time is needed. * Use OAuth and UMA (Hannes Tschofenig) - No time for the detailed discussion. It is recommended to provide feedback in the mailing list. * Wrap-up - Chairs will request 2.5 hours for the next F2F meeting. --------------------- We asked for a minute taker during the meeting but forgot who it was. If you took notes please step forward. Ciao Hannes --qrnhUIhD0SU2iIo3kEWu5UOgvp4P71fwC 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVG6LgAAoJEGhJURNOOiAtHWwH/2hW9Gk2+DF7zHPaaE3QUtPI +U3P+eLbCEqcpVbUmb+jL7Z+eDsv5EzCz8LZK3kXx837FLeEg3oQryxlSzn/D3FB zKRYrdkjRLkfmEGEAQdkUnbZ1PKax+Nua9byNsBAc0qNi3iMVIFSZ/FlWVTu+gO+ btZLssHHcLvkj2dH+eOP8x0Z9NmqSkxKwtfADrBOtgCyp7PBBljbhc6LsUWX60zR VA3hLyJwK9lETGNAtqh6ra0Xnz5Rl4NjKut+5AsBZD5J7po4Svn+oVzRWcaU3KiD 2eeg3IBWagIk07hOokVSs2IaFBOA0fudM85qTEAwDaeUpWu2XS5723mGv8+tojE= =1EK4 -----END PGP SIGNATURE----- --qrnhUIhD0SU2iIo3kEWu5UOgvp4P71fwC-- From nobody Wed Apr 1 08:05:00 2015 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 C83791ACCFC for ; Wed, 1 Apr 2015 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6ckhQmbQZZ6c for ; Wed, 1 Apr 2015 08:04:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2A61ACC85 for ; Wed, 1 Apr 2015 08:04:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D5D75E1AE for ; Wed, 1 Apr 2015 11:14:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E5C9763B76; Wed, 1 Apr 2015 11:04:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D203B63784 for ; Wed, 1 Apr 2015 11:04:27 -0400 (EDT) From: Michael Richardson To: "Ace\@ietf.org" In-Reply-To: <551BA2E0.6090205@gmx.net> References: <551BA2E0.6090205@gmx.net> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:04:59 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > Here are some short notes from the ACE meeting: > * Problem Description (Goeran Selander) - The term "Configuration > Server" needs to be checked. - There was consensus to use problem > description and terminology as a starting point to work on. > * Actors (Carsten Bormann, 20 mins) - There was preference to reuse > OAuth terminologies (e.g. Resource Server, Authorization Server). - > Action: Design team is requested to merge Problem Description draft a= nd > Actors draft, and provide a combined draft. I wonder if a virtual interim might help advance this, and reduce the time needs at the next meeting? > * Wrap-up - Chairs will request 2.5 hours for the next F2F meeting. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVRwI+4CLcPvd0N1lAQKGCgf/W2VzVHIPYrRyvmfGrHtoaKF4TxhYuOj+ 9bE0tcDI7/LEehxJnvNySaB/gtK1Ed/gDKxlIR4uhyEsNoyDLlcL5OD5l2oLqi7E TkC0oUXYPq5ARvTDpxyb4PmDD22hL5YJIZNcnOYtePoeQ4ztysgx2cfxVEx3S5t5 yy3vEaMiPzNj4mztCSreVTKq5vyp3C/bVF3E/0l8jXW7A0AkJYhs+Ft+2icQ6JMX DJ31FLwODjlJmNfl//CmKtVP8/V9nPfGHAKA63nryI/XY3i92EAoTxAumWUWatm0 nIe81y/+jov5JQpEAofeblzAm+30HNWB80fHYD13IWjxjJgWi2vvsQ== =HN85 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 1 10:07:01 2015 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 7165C1A0086 for ; Wed, 1 Apr 2015 10:06:54 -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 VdyBmomX7pEw for ; Wed, 1 Apr 2015 10:06:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153BB1A0037 for ; Wed, 1 Apr 2015 10:06:53 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LfSeH-1ZF9gh2fCz-00p22V; Wed, 01 Apr 2015 19:06:50 +0200 Message-ID: <551C25AA.3070408@gmx.net> Date: Wed, 01 Apr 2015 19:06:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Richardson , "Ace@ietf.org" References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> In-Reply-To: <6280.1427900667@sandelman.ca> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2QROxrKo5FBCEWmIn61iw8RibwnMMTGWj" X-Provags-ID: V03:K0:bDIU2sKtxTZs7FY64DvuAV5N8USAAxZz313vWtGDxN9f1UmYRJC ntxYqTaJ+OO1fFYVeFIoOM/wkv/Qd0GK8zOJHNpvCunSO7KO7m2TTwaSbk4wQTvY3XFIEV+ GSPEiCUuX3+96jmMEWNDmn/GpkEmspTQ35zKAvM2xdMTEHxfI6L4zKc8VN176N0D+m33Igj WN7mDgtEjeq1xVgHRjk4w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:06:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2QROxrKo5FBCEWmIn61iw8RibwnMMTGWj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That's a good idea, Michael. It would also set a hard deadline for folks to agree on the text. > I wonder if a virtual interim might help advance this, and reduce the t= ime > needs at the next meeting? --2QROxrKo5FBCEWmIn61iw8RibwnMMTGWj 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHCWqAAoJEGhJURNOOiAttv0H+wdRdezEr2/WGmwciYwtECxY VsWnHa9yQtI/rYqwhcVKXm9YVpgGEyhI3VYS+UgkxVB5DuDSA2qYZyWVVAhdfbOO Nf85saHdFDvSstiLiK6YSDkEoaijbiI/HSnddiIj0G8SFSyNNV/CwAvojB5bOgYA QN+FWm0QlJjFe9hgHOx/kgbd8XjOxhKb2cMBh1HnkZePfLXi524T/AMNilG9BtBs Nq5dqvF9nn+gFE4jS9cdTVgEF3tDngZLEyT6eTsOWuKKif2Mw8Vc8brd8pdc5Jim F9j1keDKXVXSe7QhThYdk5p+/jvRumbtD3cH9+fS95WGroDa0GRaZYMv9BhI6xc= =nl5a -----END PGP SIGNATURE----- --2QROxrKo5FBCEWmIn61iw8RibwnMMTGWj-- From nobody Wed Apr 1 11:02:41 2015 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 27D181A1A62 for ; Wed, 1 Apr 2015 11:02:40 -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_40=-0.001, HELO_EQ_DE=0.35] 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 usRS-GFblYBT for ; Wed, 1 Apr 2015 11:02:39 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBE91A1A43 for ; Wed, 1 Apr 2015 11:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t31I2Zjk003898; Wed, 1 Apr 2015 20:02:35 +0200 (CEST) Received: from alma.local (p5DC7F099.dip0.t-ipconnect.de [93.199.240.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lHFjk5gbkzCthn; Wed, 1 Apr 2015 20:02:34 +0200 (CEST) Message-ID: <551C32B9.3020507@tzi.org> Date: Wed, 01 Apr 2015 20:02:33 +0200 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Hannes Tschofenig References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> In-Reply-To: <551C25AA.3070408@gmx.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:02:40 -0000 Hannes Tschofenig wrote: > It would also set a hard deadline for folks to agree on the text. Good idea. I certainly don't want to spend the summer polishing this text. (If you ask me, it's done; I'm waiting for input from the WG what to fix.) Grüße, Carsten From nobody Wed Apr 1 14:35:08 2015 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 76CE91A86F5 for ; Wed, 1 Apr 2015 14:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 wMmMKzh9efbY for ; Wed, 1 Apr 2015 14:35:06 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED201A86EB for ; Wed, 1 Apr 2015 14:34:53 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-f8-551c647b417a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 21.AF.28347.B746C155; Wed, 1 Apr 2015 23:34:52 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 23:34:51 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , Hannes Tschofenig Thread-Topic: [Ace] Meeting Minutes Thread-Index: AQHQbFBP4gOSRlEpNkyRniPuth93m504ICOAgAAiMQCAAA+SgIAAXNYA Date: Wed, 1 Apr 2015 21:34:51 +0000 Message-ID: References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> In-Reply-To: <551C32B9.3020507@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <234EBDB755646E469F9626015F3CB85D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM+JvjW5NikyowdT1fBbfv/UwWxyZcpfV YunOe6wWPYf62R1YPBZv2s/msWTJTyaPljl7mD2mLcoMYInisklJzcksSy3St0vgyjj0YANb wTG2ir6PCQ2MG9i6GDk4JARMJGYfqOti5AQyxSQu3FsPFObiEBI4yigx8doWJghnMaPE6X1n mECq2ARcJB40PAKzRQSCJV4//ghmMwv4SszrecgMYgsLKEm86Z7GClGjLNG8dC0jhO0mcfbQ cxYQm0VARWJD62k2EJtXwELiy7clYPVCArUSvw+8BqvnFFCX2HbtKdh8RqDrvp9aA7VLXOLW k/lMEFcLSCzZc54ZwhaVePn4H9gcUQE9iZXXm9gg4koSjUuesII8zCygKbF+lz7EGGuJC6de skPYihJTuh+yQ5wjKHFy5hOWCYwSs5Bsm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWpyUm25kpJda lJlcXJyfp5eXWrKJERinB7f8NtjB+PK54yFGAQ5GJR7ehE7pUCHWxLLiytxDjNIcLErivHbG h0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MC5p2zx//kltQcW3h8N7Nl8LP2eeEL11gV2l t3CQz1q7nBn+RxZHrnI6Hjnv3Z4jN92fz/5w3W8vh++RfN/k1Pqrp686cK9anpP64uAdz/f/ Nr28krb7YOjWdLkPe1QOntKfpeh4dXKcaF6/iemnL/M9k1/o1n0RFgvaZf35TYuX8IvFVR1O Bx8qsRRnJBpqMRcVJwIAyeGhsrQCAAA= Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:35:07 -0000 DQoNCk9uIDIwMTUtMDQtMDEgMjA6MDIsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQo+DQo+SGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+PiBJdCB3b3VsZCBhbHNv IHNldCBhIGhhcmQgZGVhZGxpbmUgZm9yIGZvbGtzIHRvIGFncmVlIG9uIHRoZSB0ZXh0Lg0KPg0K Pkdvb2QgaWRlYS4NCj4NCg0KSSBhZ3JlZSB0byBhIGhhcmQgZGVhZGxpbmUuDQoNCldlIGhhdmUg YWxsIGhhZCBzb21lIHRoaW5ncyB0byBhdHRlbmQgdG8gYWZ0ZXIgcmV0dXJuaW5nIGZyb20gRGFs bGFzIGFuZA0Kc29tZSBvZiB1cyBhcmUgb24gRWFzdGVyIGhvbGlkYXlzIGJ1dCB0d28gaW5wdXRz IGhhdmUgYWxyZWFkeSBiZWVuIHNoYXJlZA0KaW4gdGhlIGRlc2lnbiB0ZWFtIGFuZCB0aGUgd29y ayB3aWxsIGNvbnRpbnVlIHRvbW9ycm93Lg0KDQpUaGUgaW5zdHJ1Y3Rpb25zIGZyb20gdGhlIFdH IGFyZSBjbGVhciBhbmQgYW55b25lIGlzIGludml0ZWQgdG8gZm9sbG93IHRoZQ0KcHJvZ3Jlc3Mg b2YgdGhlIHdvcmssIGJ1dCB3ZSBzYXZlIHRoZSBkZXRhaWxzIGZvciB0aG9zZSB3aG8gYXJlIHJl YWxseQ0Ka2Vlbi4NCg0KQmVzdCByZWdhcmRzLA0KR8O2cmFuDQoNCg0K From nobody Thu Apr 2 00:47:15 2015 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 8B3FF1A8999 for ; Thu, 2 Apr 2015 00:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 rRczUxGdySHN for ; Thu, 2 Apr 2015 00:47:13 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F861A8998 for ; Thu, 2 Apr 2015 00:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t327l9Mt002974; Thu, 2 Apr 2015 09:47:09 +0200 (CEST) Received: from [192.168.1.109] (p57A638A9.dip0.t-ipconnect.de [87.166.56.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lHc186mTdzCtRF; Thu, 2 Apr 2015 09:47:08 +0200 (CEST) Message-ID: <551CF3F8.2040708@tzi.de> Date: Thu, 02 Apr 2015 09:47:04 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Carsten Bormann , Hannes Tschofenig References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> In-Reply-To: <551C32B9.3020507@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 07:47:14 -0000 Hi all, On 04/01/2015 08:02 PM, Carsten Bormann wrote: > > I certainly don't want to spend the summer polishing this text. > (If you ask me, it's done; I'm waiting for input from the WG what to fix.) I would really like to know what other WG participants think about this. I wrote the original actors draft to provide for an architecture model that is able to cover all aspects of the problem we are trying to solve, and enables us to talk about these problems. Until now no one was able to tell me what was missing in the original draft. I'm still wondering if it wouldn't have been easier to make the original actors draft a working group document when people asked for that and include what is missing afterwards (if there really was anything to change other than the terminology). I get that people want a compromise but the original actors draft already was that compromise. Best regards, Steffi From nobody Thu Apr 2 02:12:26 2015 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 138FF1B2C14 for ; Thu, 2 Apr 2015 02:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 WxKvsX5T6hBm for ; Thu, 2 Apr 2015 02:12:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7301B2C16 for ; Thu, 2 Apr 2015 02:12:21 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-09-551d07f32e1f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.E5.19337.3F70D155; Thu, 2 Apr 2015 11:12:19 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Thu, 2 Apr 2015 11:12:19 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Carsten Bormann , "Hannes Tschofenig" Thread-Topic: [Ace] Meeting Minutes Thread-Index: AQHQbFBP4gOSRlEpNkyRniPuth93m504ICOAgAAiMQCAAA+SgIAA5l4AgAA5W4A= Date: Thu, 2 Apr 2015 09:12:18 +0000 Message-ID: References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> In-Reply-To: <551CF3F8.2040708@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM+Jvje5ndtlQg+5nphbfv/UwWxyZcpfV YuPFu4wWS3feY7XoOdTP7sDqsXjTfjaPJUt+Mnm0zNnD7LHt7Vdmj2mLMgNYo7hsUlJzMstS i/TtErgy/sxYzVowRaLi1sVnTA2MR8S7GDk5JARMJKZdPMsOYYtJXLi3nq2LkYtDSOAoo8Th I21MEM5iRomrS3tYQarYBFwkHjQ8YgKxRQTKJObeWsgMYjML+ErM63kIZgsLKEm86Z7GClGj LNG8dC0jhO0ncXzfY7AaFgEViWOLb7KB2LwCFhKH70xihVg2k1Gi79l+sGZOATWJP+83ghUx Ap33/dQaJohl4hK3nsxngjhbQGLJnvPMELaoxMvH/8B6RQX0JFZeb2KDiCtK7DzbDlTDAdSr KbF+lz7EGGuJ22+bWSFsRYkp3Q/ZIe4RlDg58wnLBEaJWUi2zULonoWkexaS7llIuhcwsq5i FC1OLU7KTTcy1kstykwuLs7P08tLLdnECIzgg1t+q+5gvPzG8RCjAAejEg/vg1syoUKsiWXF lbmHGKU5WJTEee2MD4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHT8vU/hxvRvW9ed/tFw neOWmVXxPxeG0DNvX7CYp0jFd3DeP7Aj91txStDix2zGe6sVo/hDhY3NekV+R22+Juzzz7Dp lUtXiLV1T+CPvY1T5v2qWHp6m2J4mMCMy4eTNJ5nLGx2lZd5yLJuBq+WzuyPforq00JzlpXu un2JLe1EbMKN/LjNjUosxRmJhlrMRcWJALrLpIHBAgAA Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 09:12:24 -0000 SGkgYWxsLA0KDQpJIGRpZCBub3Qgd2FudCB0byByZW9wZW4gdGhpcyBkaXNjdXNzaW9uLCBidXQg SSB3YW50IHRvIHBvaW50IG91dCB0aGF0DQpMdWR3aWcgYW5kIEkgd3JvdGUgdGhlIG9yaWdpbmFs IHByb2JsZW0gZGVzY3JpcHRpb24gZHJhZnQgdG8gcHJvdmlkZSBhbg0KYXJjaGl0ZWN0dXJlIG1v ZGVsIHRoYXQgaXMgYWJsZSB0byBjb3ZlciBhbGwgYXNwZWN0cyBvZiB0aGUgcHJvYmxlbSB3ZSBh cmUNCnRyeWluZyB0byBzb2x2ZSwgYW5kIGVuYWJsZXMgdXMgdG8gdGFsayBhYm91dCB0aGVzZSBw cm9ibGVtcy4gVGhlIHVwZGF0ZWQNCnZlcnNpb24gcmVmbGVjdGVkIHRoZSBpbnB1dCB3ZSBnb3Qg Zm9yIHRoZSBpbmZvcm1hbCBpbnRlcnJpbSBBQ0UgbWVldGluZywNCnNvIGl0IGlzIGFscmVhZHkg YSBjb21wcm9taXNlLg0KDQpJIGhhdmUgcHJvdmlkZWQgYSBudW1iZXIgb2YgY29tbWVudHMgb24g dGhlIGFjdG9ycyBkcmFmdCwgaW5jbHVkaW5nDQptaXNzaW5nIGVuZC10by1lbmQgc2VjdXJpdHks IG92ZXJhbGwgcHJvYmxlbSBzdGF0ZW1lbnQsIGV0Yy4gSSBoYXZlIG5vdA0KcmVjZWl2ZWQgYW55 IGZ1cnRoZXIgY29tbWVudHMgb24gdGhlIHByb2JsZW0gZGVzY3JpcHRpb24gZHJhZnQuDQoNCkkg aGVhciB0aGF0IHBlb3BsZSB3YW50IGEgY29tcHJvbWlzZSwgSSBkb27igJl0IHNlZSB0aGF0IGFk b3B0aW9uIG9mIG9uZQ0KZHJhZnQgd2lsbCBpbXByb3ZlIHRoZSBzaXR1YXRpb24gLSBvbiB0aGUg Y29udHJhcnkgLSB0aGlzIHdpbGwganVzdCBiZWNvbWUNCmEgcmVwZXRpdGlvbiBvZiB0aGUgZGlz Y3Vzc2lvbiBvZiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQgYWZ0ZXIgaXRzIGFkb3B0aW9uLg0KDQoN Ck15IHJlY29tbWVuZGF0aW9uIGZvciB0aGUgV0cgaXMgdG8gc2V0IGEgZGVhZGxpbmUgZm9yIHRo ZSBkZXNpZ24gdGVhbSBhbmQNCmVuY291cmFnZSB0aGUgdGVhbSB0byBjb21lIHVwIHdpdGggYSBj b21tb24gc3RydWN0dXJlIGFuZCB0ZXh0Lg0KDQpUaGF0IHdpbGwgYWxzbyBjcmVhdGUgYSBncmFj ZSBwZXJpb2Qgb24gdGhlIEFDRSBsaXN0IGZvciBtb3JlIGZydWl0ZnVsDQpkaXNjdXNzaW9ucy4N Cg0KQmVzdCByZWdhcmRzLA0KR8O2cmFuDQoNCk9uIDIwMTUtMDQtMDIgMDk6NDcsICJTdGVmYW5p ZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIGFsbCwNCj4NCj5PbiAwNC8w MS8yMDE1IDA4OjAyIFBNLCBDYXJzdGVuIEJvcm1hbm4gd3JvdGU6DQo+Pg0KPj4gSSBjZXJ0YWlu bHkgZG9uJ3Qgd2FudCB0byBzcGVuZCB0aGUgc3VtbWVyIHBvbGlzaGluZyB0aGlzIHRleHQuDQo+ PiAoSWYgeW91IGFzayBtZSwgaXQncyBkb25lOyBJJ20gd2FpdGluZyBmb3IgaW5wdXQgZnJvbSB0 aGUgV0cgd2hhdCB0bw0KPj5maXguKQ0KPg0KPkkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyB3 aGF0IG90aGVyIFdHIHBhcnRpY2lwYW50cyB0aGluayBhYm91dCB0aGlzLg0KPkkgd3JvdGUgdGhl IG9yaWdpbmFsIGFjdG9ycyBkcmFmdCB0byBwcm92aWRlIGZvciBhbiBhcmNoaXRlY3R1cmUgbW9k ZWwNCj50aGF0IGlzIGFibGUgdG8gY292ZXIgYWxsIGFzcGVjdHMgb2YgdGhlIHByb2JsZW0gd2Ug YXJlIHRyeWluZyB0byBzb2x2ZSwNCj5hbmQgZW5hYmxlcyB1cyB0byB0YWxrIGFib3V0IHRoZXNl IHByb2JsZW1zLiBVbnRpbCBub3cgbm8gb25lIHdhcyBhYmxlDQo+dG8gdGVsbCBtZSB3aGF0IHdh cyBtaXNzaW5nIGluIHRoZSBvcmlnaW5hbCBkcmFmdC4NCj4NCj5JJ20gc3RpbGwgd29uZGVyaW5n IGlmIGl0IHdvdWxkbid0IGhhdmUgYmVlbiBlYXNpZXIgdG8gbWFrZSB0aGUgb3JpZ2luYWwNCj5h Y3RvcnMgZHJhZnQgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHdoZW4gcGVvcGxlIGFza2VkIGZv ciB0aGF0IGFuZA0KPmluY2x1ZGUgd2hhdCBpcyBtaXNzaW5nIGFmdGVyd2FyZHMgKGlmIHRoZXJl IHJlYWxseSB3YXMgYW55dGhpbmcgdG8NCj5jaGFuZ2Ugb3RoZXIgdGhhbiB0aGUgdGVybWlub2xv Z3kpLiBJIGdldCB0aGF0IHBlb3BsZSB3YW50IGEgY29tcHJvbWlzZQ0KPmJ1dCB0aGUgb3JpZ2lu YWwgYWN0b3JzIGRyYWZ0IGFscmVhZHkgd2FzIHRoYXQgY29tcHJvbWlzZS4NCj4NCj5CZXN0IHJl Z2FyZHMsDQo+U3RlZmZpDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5BY2UgbWFpbGluZyBsaXN0DQo+QWNlQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Thu Apr 2 02:19:12 2015 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 EB4001B2C1B for ; Thu, 2 Apr 2015 02:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 m2Cmg_b6iAzR for ; Thu, 2 Apr 2015 02:19:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78EF61B2C16 for ; Thu, 2 Apr 2015 02:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t329J2FY008713; Thu, 2 Apr 2015 11:19:02 +0200 (CEST) Received: from [192.168.1.109] (p57A638A9.dip0.t-ipconnect.de [87.166.56.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lHf3B4BbLzCtfJ; Thu, 2 Apr 2015 11:19:02 +0200 (CEST) Message-ID: <551D0986.2030406@tzi.de> Date: Thu, 02 Apr 2015 11:19:02 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Carsten Bormann , Hannes Tschofenig References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 09:19:11 -0000 Hi Göran, I don't want to reopen the discussion, either. But I really would like to know what other people want and think. Since there were no comments on the problem description draft as you said and several people said that they liked the actors draft and even proposed it to be working group draft, it would be good to know what other people missed in the actors draft. Best regards, Steffi On 04/02/2015 11:12 AM, Göran Selander wrote: > Hi all, > > I did not want to reopen this discussion, but I want to point out that > Ludwig and I wrote the original problem description draft to provide an > architecture model that is able to cover all aspects of the problem we are > trying to solve, and enables us to talk about these problems. The updated > version reflected the input we got for the informal interrim ACE meeting, > so it is already a compromise. > > I have provided a number of comments on the actors draft, including > missing end-to-end security, overall problem statement, etc. I have not > received any further comments on the problem description draft. > > I hear that people want a compromise, I don’t see that adoption of one > draft will improve the situation - on the contrary - this will just become > a repetition of the discussion of the use case document after its adoption. > > > My recommendation for the WG is to set a deadline for the design team and > encourage the team to come up with a common structure and text. > > That will also create a grace period on the ACE list for more fruitful > discussions. > > Best regards, > Göran > > On 2015-04-02 09:47, "Stefanie Gerdes" wrote: > >> Hi all, >> >> On 04/01/2015 08:02 PM, Carsten Bormann wrote: >>> >>> I certainly don't want to spend the summer polishing this text. >>> (If you ask me, it's done; I'm waiting for input from the WG what to >>> fix.) >> >> I would really like to know what other WG participants think about this. >> I wrote the original actors draft to provide for an architecture model >> that is able to cover all aspects of the problem we are trying to solve, >> and enables us to talk about these problems. Until now no one was able >> to tell me what was missing in the original draft. >> >> I'm still wondering if it wouldn't have been easier to make the original >> actors draft a working group document when people asked for that and >> include what is missing afterwards (if there really was anything to >> change other than the terminology). I get that people want a compromise >> but the original actors draft already was that compromise. >> >> Best regards, >> Steffi >> >> _______________________________________________ >> 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 > > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Thu Apr 2 02:28:03 2015 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 65A891A8A86 for ; Thu, 2 Apr 2015 02:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 0FUkJl71hZz6 for ; Thu, 2 Apr 2015 02:28:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EECC1B2C18 for ; Thu, 2 Apr 2015 02:27:59 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MY7dI-1Yzio716xM-00Utp1; Thu, 02 Apr 2015 11:27:55 +0200 Message-ID: <551D0B98.4020407@gmx.net> Date: Thu, 02 Apr 2015 11:27:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Stefanie Gerdes , Carsten Bormann References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9bRXufsfBSeoj36LcP7iGC3ePSpWjF0KA" X-Provags-ID: V03:K0:GdzzR3wedYs8WO9WgoW+RSdpbKVqViGDnLtNI3PfpTVSdCm6GeU LG3q1yEz0I8qzSDGp7yxBGBgS3cP5hYgMyONfil6d+CZAHXswCLjR5BO79wv1FGKzgFNnME FLvEtZlyBE3sozL2TVdTSuEQrdvchZUMRcqYqM9ulImDo3ErapSnxqjpLwFYG5N/3gjGzAr 9VafTmXQ0mkaQiAdi9y2Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 09:28:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9bRXufsfBSeoj36LcP7iGC3ePSpWjF0KA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Based on the discussion during the meeting Kepeng and I got the impression that the group wants to see a harmonized proposal from the key participants involved in that discussion (rather than having different ideas floating around). First, the members of that small design team (consisting of Carsten, Steffi, Goeran, and Ludwig*) need to come up with something they can agree with among each other. Then, come back to the group and present it. Deadline: May. Ciao Hannes PS: If someone else wants to part of the design team please let Kepeng and myself know. On 04/02/2015 11:12 AM, G=C3=B6ran Selander wrote: > Hi all, >=20 > I did not want to reopen this discussion, but I want to point out that > Ludwig and I wrote the original problem description draft to provide an= > architecture model that is able to cover all aspects of the problem we = are > trying to solve, and enables us to talk about these problems. The updat= ed > version reflected the input we got for the informal interrim ACE meetin= g, > so it is already a compromise. >=20 > I have provided a number of comments on the actors draft, including > missing end-to-end security, overall problem statement, etc. I have not= > received any further comments on the problem description draft. >=20 > I hear that people want a compromise, I don=E2=80=99t see that adoption= of one > draft will improve the situation - on the contrary - this will just bec= ome > a repetition of the discussion of the use case document after its adopt= ion. >=20 >=20 > My recommendation for the WG is to set a deadline for the design team a= nd > encourage the team to come up with a common structure and text. >=20 > That will also create a grace period on the ACE list for more fruitful > discussions. >=20 > Best regards, > G=C3=B6ran >=20 > On 2015-04-02 09:47, "Stefanie Gerdes" wrote: >=20 >> Hi all, >> >> On 04/01/2015 08:02 PM, Carsten Bormann wrote: >>> >>> I certainly don't want to spend the summer polishing this text. >>> (If you ask me, it's done; I'm waiting for input from the WG what to >>> fix.) >> >> I would really like to know what other WG participants think about thi= s. >> I wrote the original actors draft to provide for an architecture model= >> that is able to cover all aspects of the problem we are trying to solv= e, >> and enables us to talk about these problems. Until now no one was able= >> to tell me what was missing in the original draft. >> >> I'm still wondering if it wouldn't have been easier to make the origin= al >> actors draft a working group document when people asked for that and >> include what is missing afterwards (if there really was anything to >> change other than the terminology). I get that people want a compromis= e >> but the original actors draft already was that compromise. >> >> Best regards, >> Steffi >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --9bRXufsfBSeoj36LcP7iGC3ePSpWjF0KA 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHQuYAAoJEGhJURNOOiAto3AIAKfB9YI9hU1fdWbHmDPBG9jZ 2wf8Paa6ALqzHukVD7+KYZSu5/2CKwocUTg9kbrtkbWAoWXemkU1ysKThO7T1Ocp 4ZtvGk2dIPlaTLU8UNU4sIhPPX+P6JtYjz6RHpU1r6spkM852OUFz9QeAWsCmaCK QRWwKWvt76i3s4sQN3D1zQJu4jGY2zJjGV6QcMdYEaaQbg6diNSDV/OFkpNc9Owt QGMJhSfV17cV8V7lsoRQrcBTcXGbr2Bi1l2MLZA8OntuQ5zomie9+GpXcoPI3z6C i+tdhLZny7XOv+n2lsg7A3vtUKK0FIAMmJMlA/rxjr/VucfKb0KVavJgUHIBao4= =1tSR -----END PGP SIGNATURE----- --9bRXufsfBSeoj36LcP7iGC3ePSpWjF0KA-- From nobody Thu Apr 2 02:44:25 2015 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 55C4B1B2C37 for ; Thu, 2 Apr 2015 02:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 OBLBVEu71TlA for ; Thu, 2 Apr 2015 02:44:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F071A8BB7 for ; Thu, 2 Apr 2015 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t329iGWe012572; Thu, 2 Apr 2015 11:44:16 +0200 (CEST) Received: from [192.168.1.109] (p57A638A9.dip0.t-ipconnect.de [87.166.56.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lHfcJ2ZDCzCsc4; Thu, 2 Apr 2015 11:44:16 +0200 (CEST) Message-ID: <551D0F6F.2070700@tzi.de> Date: Thu, 02 Apr 2015 11:44:15 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , =?UTF-8?B?R8O2cmFuIFNl?= =?UTF-8?B?bGFuZGVy?= , Carsten Bormann References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> <551D0B98.4020407@gmx.net> In-Reply-To: <551D0B98.4020407@gmx.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 09:44:24 -0000 Hi Hannes, it would still be helpful to know what other people on the list other than the authors of the documents want and need. I just want to encourage people to provide input on that. It's easier to come up with a useful design if we understand what other people are thinking. Best regards, Steffi On 04/02/2015 11:27 AM, Hannes Tschofenig wrote: > Based on the discussion during the meeting Kepeng and I got the > impression that the group wants to see a harmonized proposal from the > key participants involved in that discussion (rather than having > different ideas floating around). > > First, the members of that small design team (consisting of Carsten, > Steffi, Goeran, and Ludwig*) need to come up with something they can > agree with among each other. Then, come back to the group and present > it. Deadline: May. > > Ciao > Hannes > > PS: If someone else wants to part of the design team please let Kepeng > and myself know. > > On 04/02/2015 11:12 AM, Göran Selander wrote: >> Hi all, >> >> I did not want to reopen this discussion, but I want to point out that >> Ludwig and I wrote the original problem description draft to provide an >> architecture model that is able to cover all aspects of the problem we are >> trying to solve, and enables us to talk about these problems. The updated >> version reflected the input we got for the informal interrim ACE meeting, >> so it is already a compromise. >> >> I have provided a number of comments on the actors draft, including >> missing end-to-end security, overall problem statement, etc. I have not >> received any further comments on the problem description draft. >> >> I hear that people want a compromise, I don’t see that adoption of one >> draft will improve the situation - on the contrary - this will just become >> a repetition of the discussion of the use case document after its adoption. >> >> >> My recommendation for the WG is to set a deadline for the design team and >> encourage the team to come up with a common structure and text. >> >> That will also create a grace period on the ACE list for more fruitful >> discussions. >> >> Best regards, >> Göran >> >> On 2015-04-02 09:47, "Stefanie Gerdes" wrote: >> >>> Hi all, >>> >>> On 04/01/2015 08:02 PM, Carsten Bormann wrote: >>>> >>>> I certainly don't want to spend the summer polishing this text. >>>> (If you ask me, it's done; I'm waiting for input from the WG what to >>>> fix.) >>> >>> I would really like to know what other WG participants think about this. >>> I wrote the original actors draft to provide for an architecture model >>> that is able to cover all aspects of the problem we are trying to solve, >>> and enables us to talk about these problems. Until now no one was able >>> to tell me what was missing in the original draft. >>> >>> I'm still wondering if it wouldn't have been easier to make the original >>> actors draft a working group document when people asked for that and >>> include what is missing afterwards (if there really was anything to >>> change other than the terminology). I get that people want a compromise >>> but the original actors draft already was that compromise. >>> >>> Best regards, >>> Steffi >>> >>> _______________________________________________ >>> 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 >> > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Thu Apr 2 17:37:34 2015 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 9EA911A8991 for ; Thu, 2 Apr 2015 17:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FROM_DOMAIN_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVUcg5hd5jAw for ; Thu, 2 Apr 2015 17:37:31 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3D81A8990 for ; Thu, 2 Apr 2015 17:37:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id B5FAB7731043; Thu, 2 Apr 2015 17:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M17ZSh4zrHXV; Thu, 2 Apr 2015 17:37:29 -0700 (PDT) Received: from [192.168.168.101] (unknown [192.168.168.101]) by mail.promanage-inc.com (Postfix) with ESMTPS id 7F6727731031; Thu, 2 Apr 2015 17:37:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: Date: Thu, 2 Apr 2015 17:37:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <91A503A1-BD0D-4ABB-9081-48947673859A@xmlgrrl.com> References: <59F1C792-B108-4DEC-8B5F-94CA8DC19BF8@xmlgrrl.com> <, > <87vbhpv13k.fsf@tzi.org> To: Olaf Bergmann X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] New doc: draft-maler-ace-oauth-uma-00 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, 03 Apr 2015 00:37:33 -0000 Hopefully it won't be too confusing if I offer a bit more nuance on top = of Thomas's answer. (Sorry, I was away on a cruise ship last week and am = just catching up on email!) Registering a permission is, in fact, a required step. The *extent* of = the permission is a judgment call that the resource server is allowed to = apply. ("The resource server is free to choose the extent of the = requested permission that it registers, as long as it minimally suffices = for the access attempted by the client.") You don't strictly need to create a profile of UMA that defines any = missing parts at all; there are default (and, in some cases, = mandatory-to-implement) profiles that you can use in all cases. However, = in practice, there are points of variability where it is very likely = that you will want to lock down deployment choices. The HEART WG is one = example of a community of interest doing this profiling for both = security and semantic reasons (health data sharing, in that case). I, for one, don't actually believe that permission tickets are an area = that will require profiling in most cases, because it's an artifact that = is produced and consumed solely by the authorization server. However, = I'm aware of some discussions around profiling permission tickets for = various clever purposes. It's entirely okay to consider doing this. Hopefully these thoughts are helpful. Eve > On 25 Mar 2015, at 9:14 AM, Thomas Hardjono wrote: >=20 > Hi Olaf, >=20 > In order to use UMA in a given IoT scenario, you will need to create a = profile of UMA that defines the "missing parts", such as the contents of = the permission ticket. This is what the HEART WG is doing in the OIF.=20 >=20 >=20 > /thomas/ >=20 >=20 >=20 >=20 >> On Mar 25, 2015, at 06:11, Olaf Bergmann wrote: >>=20 >> Eve, >>=20 >> Eve Maler writes: >>=20 >>> http://tools.ietf.org/html/draft-maler-ace-oauth-uma-00 >>=20 >> Thanks for sharing this. >>=20 >> One question: draft-hardjono-oauth-umacore-12 specifies that when a >> client attempts to access a protected resource, the resource server = must >> register a requested permission with its authorization server to get = an >> RPT that the client must present to the authorization server. From >> reading Section 5 of draft-maler-ace-oauth-uma, it is unclear to me >> whether or not this step is required in this profile. Can you clarify >> how this is supposed to work? >>=20 >> Thanks >> Olaf >>=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 Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl From nobody Sun Apr 5 12:12:56 2015 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 8C5F61ACDEC for ; Sun, 5 Apr 2015 12:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kpfDzksWQSP for ; Sun, 5 Apr 2015 12:12:53 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76EE1ACDD4 for ; Sun, 5 Apr 2015 12:12:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id B2B13779235C; Sun, 5 Apr 2015 12:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB3MI2wbOu3h; Sun, 5 Apr 2015 12:12:51 -0700 (PDT) Received: from [192.168.168.101] (unknown [192.168.168.101]) by mail.promanage-inc.com (Postfix) with ESMTPS id 585627792343; Sun, 5 Apr 2015 12:12:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_91559AC0-7552-45E8-A316-F2BFCD3ADC54" From: Eve Maler In-Reply-To: Date: Sun, 5 Apr 2015 12:12:50 -0700 Message-Id: <6031F4A5-C715-41E5-88D8-4D58C34EA73B@xmlgrrl.com> References: To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Transaction model X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 19:12:55 -0000 --Apple-Mail=_91559AC0-7552-45E8-A316-F2BFCD3ADC54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Robert, This nicely symmetrical diagram may be obscuring the fact that the = relationship is still pretty asymmetrical. The client, by virtue of = wanting a resource that it has identified (or whose location it has been = provisioned with), essentially =E2=80=9Ctrusts=E2=80=9D that resource = and resource server already. And because it is in the position of = requesting the resource (let=E2=80=99s think of it as a = =E2=80=9Crequest-response=E2=80=9D pattern), there=E2=80=99s already an = asymmetry there too. The policy that the client and its owner thus apply = to the proposition thus typically happen =E2=80=9Coff-stage=E2=80=9D = with respect to the authn/authz aspects of the picture. You can see lots of asymmetry revealed in the =E2=80=9CBinding = Obligations=E2=80=9D discussion here = (hmm, looks = like we need to refresh this doc =E2=80=94 the UMA group is on the cusp = of picking this work up again now that the technical substrate is = stable). Although the Binding Obs doc uses different names than CO, AM, = etc., it has roughly the same piece-parts; what it does is attach basic = contractual obligations to pairs of parties corresponding to the = software/human entities in the picture, whenever a significant state = change occurs. Typical examples of significant state changes are things = like token issuance. (There is, I believe, one main difference between the UMA model and the = DCAF-ish model other than terminology. In UMA, the CO/requesting party = can be represented not just through an =E2=80=9CAM=E2=80=9D, but by = claims gathered by a flexible choice of sources: the AS (on the RO = side), the client, some other third-party identity/claim providers, = etc.) FWIW, Eve > On 23 Mar 2015, at 6:20 PM, Robert Cragie = wrote: >=20 > Further to the discussion in the ACE side meeting, I came up with this = (rather complicated) model which in my mind shows what considerations = there are when it comes to just a very basic instantaneous = request/response transaction with respect to a resource. >=20 > = https://docs.google.com/presentation/d/1qFH5zPoBWx1Rog3OkPwqKnwVd-SNsWsFZR= 9t7lDFdA0/edit?usp=3Dsharing = >=20 > Happy to explain it further. >=20 > Robert > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl --Apple-Mail=_91559AC0-7552-45E8-A316-F2BFCD3ADC54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Robert,

This nicely symmetrical diagram may be = obscuring the fact that the relationship is still pretty asymmetrical. = The client, by virtue of wanting a resource that it has identified (or = whose location it has been provisioned with), essentially =  =E2=80=9Ctrusts=E2=80=9D that resource and resource server = already. And because it is in the position of requesting the resource = (let=E2=80=99s think of it as a =E2=80=9Crequest-response=E2=80=9D = pattern), there=E2=80=99s already an asymmetry there too. The policy = that the client and its owner thus apply to the proposition thus = typically happen =E2=80=9Coff-stage=E2=80=9D with respect to the = authn/authz aspects of the picture.

You can see lots of asymmetry revealed = in the =E2=80=9CBinding Obligations=E2=80=9D discussion here (hmm, looks like we need to refresh this doc = =E2=80=94 the UMA group is on the cusp of picking this work up again now = that the technical substrate is stable). Although the Binding Obs doc = uses different names than CO, AM, etc., it has roughly the same = piece-parts; what it does is attach basic contractual obligations to = pairs of parties corresponding to the software/human entities in the = picture, whenever a significant state change occurs. Typical examples of = significant state changes are things like token issuance.

(There is, I believe, = one main difference between the UMA model and the DCAF-ish model other = than terminology. In UMA, the CO/requesting party can be represented not = just through an =E2=80=9CAM=E2=80=9D, but by claims gathered by a = flexible choice of sources: the AS (on the RO side), the client, some = other third-party identity/claim providers, etc.)
FWIW,

Eve

On = 23 Mar 2015, at 6:20 PM, Robert Cragie <robert.cragie@gridmerge.com> wrote:

Further to the discussion in the ACE side meeting, I came up = with this (rather complicated) model which in my mind shows what = considerations there are when it comes to just a very basic = instantaneous request/response transaction with respect to a = resource.

https://docs.google.com/presentation/d/1qFH5zPoBWx1Rog3OkPwqKnw= Vd-SNsWsFZR9t7lDFdA0/edit?usp=3Dsharing

Happy to explain it = further.

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


Eve Maler | cell +1 425.345.6756 | Skype: = xmlgrrl | Twitter: @xmlgrrl

= --Apple-Mail=_91559AC0-7552-45E8-A316-F2BFCD3ADC54-- From nobody Mon Apr 6 07:23:52 2015 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 EDCF01A1B56 for ; Mon, 6 Apr 2015 07:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SuKP9jbWx4zN for ; Mon, 6 Apr 2015 07:23:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EEE1A1B24 for ; Mon, 6 Apr 2015 07:23:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 61F93203AD; Mon, 6 Apr 2015 10:34:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 13F5163B76; Mon, 6 Apr 2015 10:23:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 03B96636B6; Mon, 6 Apr 2015 10:23:48 -0400 (EDT) From: Michael Richardson To: Stefanie Gerdes In-Reply-To: <551CF3F8.2040708@tzi.de> References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Cc: Carsten Bormann , Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 14:23:51 -0000 --=-=-= Content-Type: text/plain Stefanie Gerdes wrote: >> I certainly don't want to spend the summer polishing this text. (If >> you ask me, it's done; I'm waiting for input from the WG what to fix.) > I would really like to know what other WG participants think about > this. I wrote the original actors draft to provide for an architecture > model that is able to cover all aspects of the problem we are trying to > solve, and enables us to talk about these problems. Until now no one > was able to tell me what was missing in the original draft. Because I felt that the original actors document was just fine, and I advocated for adopting it multiple meetings ago, I am happy if we finally have a way forward. Just so that I am clear: what is your understanding of what is missing? Please feel free to point to an email that perhaps I did not read well enough. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSKW84CLcPvd0N1lAQKVWwgAmtlaSDvfTrMasO/DhWtKfkJ4tEO4Tq6r H2nZYie0vHwZnKae1UvlV9oCWBfMbkMpThfII5wyTE2YpDTQCKheu2b4L1g6MH6w ZyvJ4L0YW7WUaE7kjPcABhrMg1mKlu5bU65T6jX/1gcLNsV7eeqjFvL4jfMnLjK6 eV40Ey2cSSIeNfo6XRkuXpEO80Kh86cYMhZNMaeZZuKQ/KlwG5kL7Ja+urhcG9rl ZoBGrmkz5XV3CVjiY64iLDOkPNNKbizur+ait7QGzg2ougKg5FFu3YRz0tY95h27 L/9A/rNE/iujqNLtE+MeM+Pye6bbrxyVaYyUbAtgdCnzlQhPIaBQSw== =nhjM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 8 07:00:08 2015 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 D90AB1A924B for ; Wed, 8 Apr 2015 07:00:05 -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_20=-0.001, HELO_EQ_DE=0.35] 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 0uh_mkUWqsBh for ; Wed, 8 Apr 2015 07:00:00 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB38A1A87EB for ; Wed, 8 Apr 2015 06:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t38DxkTN004910; Wed, 8 Apr 2015 15:59:46 +0200 (CEST) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:542c:ae99:2d81:3421]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lMS0K4w2Cz2t62; Wed, 8 Apr 2015 15:59:45 +0200 (CEST) From: Olaf Bergmann To: Eve Maler Date: Wed, 08 Apr 2015 15:59:13 +0200 References: <6031F4A5-C715-41E5-88D8-4D58C34EA73B@xmlgrrl.com> Message-ID: <87384azpny.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: robert.cragie@gridmerge.com, "ace@ietf.org" Subject: Re: [Ace] Transaction model 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, 08 Apr 2015 14:00:06 -0000 Eve, Eve Maler writes: > This nicely symmetrical diagram may be obscuring the fact that the > relationship is still pretty asymmetrical. The client, by virtue of > wanting a resource that it has identified (or whose location it has > been provisioned with), essentially =E2=80=9Ctrusts=E2=80=9D that resourc= e and > resource server already. And because it is in the position of > requesting the resource (let=E2=80=99s think of it as a =E2=80=9Crequest-= response=E2=80=9D > pattern), there=E2=80=99s already an asymmetry there too. The policy that= the > client and its owner thus apply to the proposition thus typically > happen =E2=80=9Coff-stage=E2=80=9D with respect to the authn/authz aspect= s of the > picture. The ACE problem statement as presented, e.g., during the WG session in Dallas, clearly states that Client and Server do not know each other a priori. Therefore, you cannot automatically assume that there is pre-established "trust" between the client and the resource server. For example, the client may have discovered the resource server and its capabilities by searching a resource directory. Now, before it can access that resource server, it has to check if the client owner (who may or may not be the same individual as the resource owner) allows this. Sure, you can do this "off-stage", as pointed out in , and there is a lot of authorization protocols that do this. The question here is whether or not this authorization step is documented. The actors draft documents this to avoid always having to say that there is this pre-requisite of having installed a policy (which might be hidden in program code, of course) out-of-band that establishes the trust between client and resource server. > (There is, I believe, one main difference between the UMA model and > the DCAF-ish model other than terminology. In UMA, the CO/requesting > party can be represented not just through an =E2=80=9CAM=E2=80=9D, but by= claims > gathered by a flexible choice of sources: the AS (on the RO side), the > client, some other third-party identity/claim providers, etc.) DCAF follows the generic model from the actors draft where the CO/RqP may or may not be identical with the RO or something else. The nice thing about the actors model is that it entirely covers the UMA model (and all others on the table). The major difference between the actors model and OAuth/UMA etc. is that it explicitly documents the CO/RqP-AM part in terms of the tasks that are required to check that the propositions you have mentioned really apply. The mechanism described in draft-maler-ace-oauth-uma, e.g., perfectly fits into the actor model (the client and the AM in this protocol would reside non-distinguishable in the same piece of software). DCAF also fits into this model, but with DCAF, you have the option to create an AM that actively performs AM's tasks. This could be a separate box or another process on the same device, or even the AS. One nice characteristic of DCAF is that the implementer of the client side can decide if she wants to have an explicit AM or combine it with the client. The latter would be the same as UMA/OAuth do. Gr=C3=BC=C3=9Fe Olaf From nobody Thu Apr 9 10:46:03 2015 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 EDF8E1B2FFB for ; Thu, 9 Apr 2015 10:46:01 -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 bTmbvfFuhzrh for ; Thu, 9 Apr 2015 10:46:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27321B2FFC for ; Thu, 9 Apr 2015 10:45:59 -0700 (PDT) Received: from [192.168.10.172] ([167.220.25.4]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MNqfr-1YmYyx2Kip-007TNo; Thu, 09 Apr 2015 19:45:53 +0200 Message-ID: <5526BACB.3090703@gmx.net> Date: Thu, 09 Apr 2015 19:45:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , Stefanie Gerdes References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> <2791.1428330228@sandelman.ca> In-Reply-To: <2791.1428330228@sandelman.ca> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3RklHOjSUwkc2BvA66NHqEcCpOuQrf0Tt" X-Provags-ID: V03:K0:RzuyCC4ldlyNxNvo4+KOu+pisgCvHYF0Lx58197hirhvFAfwSoi BNba/Sko5g29IIVNEzuD5XQo8Ayf4eV4q8VDXPLkKl3LtvXdVigw2a6+9Rv5ZIvdCk23p5T QSuEBt1IWcDqIQPPatGbKMmas4G7/P+/RiYB6cI0d8Jh2tHghXzcOuOrffbYCL4XfW7tR2U RPGlatyZr1O/mPd2/l+QA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Carsten Bormann , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:46:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3RklHOjSUwkc2BvA66NHqEcCpOuQrf0Tt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Michael, I don't remember if you have been at the ACE WG meeting at IETF#92 but the participants in the room gave us the feedback that they liked the approach Goeran presented. Then, it turns out that they also liked the content Carsten proposed. In the subsequent discussion someone suggested to let the two groups work as part of a design team. Kepeng and I liked the idea and that's what we then decided to do. Ciao Hannes On 04/06/2015 04:23 PM, Michael Richardson wrote: >=20 > Stefanie Gerdes wrote: > >> I certainly don't want to spend the summer polishing this text. = (If > >> you ask me, it's done; I'm waiting for input from the WG what to= fix.) >=20 > > I would really like to know what other WG participants think abou= t > > this. I wrote the original actors draft to provide for an archite= cture > > model that is able to cover all aspects of the problem we are try= ing to > > solve, and enables us to talk about these problems. Until now no = one > > was able to tell me what was missing in the original draft. >=20 > Because I felt that the original actors document was just fine, and I > advocated for adopting it multiple meetings ago, I am happy if we final= ly > have a way forward. >=20 > Just so that I am clear: what is your understanding of what is missing?= > Please feel free to point to an email that perhaps I did not read well > enough. >=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 --3RklHOjSUwkc2BvA66NHqEcCpOuQrf0Tt 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVJrrLAAoJEGhJURNOOiAt09kH/0ZIoJMHf0Bo3G9FVEKAdzlz I6ZSj3RsiRuZc9OqgEJ7boCMJyp33AWEkz4g1Roc8tIIfTI3hDmYqYrLbpx4XLpo Xk8wPQ0JU64YjWM7HkvFfdN/j2DyZPof8rwyX4ujfhKwl1IKAk11yoJt1hQEeDb9 hUw7r5lRlmhyud9jY6WvCI8z7rtBnMeMa5Iop+hKnmY3ox3JeGwfLr1iPfPe8Zdc ZZjFlpYFH6gPyu0yrgcNFEBmgziQ2oL5ntN3sjj0ahRn2tI8NkEaXmEVUHQJuoxA SPJO/osHW0AaKK0c58bKaF9XfOpoqaaOn4v24rsxXVO2mWbv9OS6QA3ZGEh+lmg= =0rkR -----END PGP SIGNATURE----- --3RklHOjSUwkc2BvA66NHqEcCpOuQrf0Tt-- From nobody Thu Apr 9 10:48:50 2015 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 D08DF1B3006 for ; Thu, 9 Apr 2015 10:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 uOiirbWVS7V1 for ; Thu, 9 Apr 2015 10:48:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AF91B300C for ; Thu, 9 Apr 2015 10:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t39HmX93018771; Thu, 9 Apr 2015 19:48:33 +0200 (CEST) Received: from alma.local (p5DC7F099.dip0.t-ipconnect.de [93.199.240.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lN91r6NMxz2tZw; Thu, 9 Apr 2015 19:48:32 +0200 (CEST) Message-ID: <5526BB6E.3070401@tzi.org> Date: Thu, 09 Apr 2015 19:48:30 +0200 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Hannes Tschofenig References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> <2791.1428330228@sandelman.ca> <5526BACB.3090703@gmx.net> In-Reply-To: <5526BACB.3090703@gmx.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Michael Richardson , "Ace@ietf.org" , Stefanie Gerdes Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:48:45 -0000 Hannes Tschofenig wrote: > In the subsequent discussion someone suggested to let the two groups > work as part of a design team. > > Kepeng and I liked the idea and that's what we then decided to do. Exactly, and we're at it: we had our first phone call today and will have another one on Monday. Grüße, Carsten From nobody Thu Apr 9 10:48:58 2015 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 8D2F41B301A for ; Thu, 9 Apr 2015 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 klEoEDjrfbIf for ; Thu, 9 Apr 2015 10:48:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C311B300F for ; Thu, 9 Apr 2015 10:48:43 -0700 (PDT) Received: from [192.168.10.172] ([167.220.25.4]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M6SJX-1ZdI2R0BuV-00yTTm; Thu, 09 Apr 2015 19:48:28 +0200 Message-ID: <5526BB68.8080409@gmx.net> Date: Thu, 09 Apr 2015 19:48:24 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stefanie Gerdes , =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Carsten Bormann References: <551BA2E0.6090205@gmx.net> <6280.1427900667@sandelman.ca> <551C25AA.3070408@gmx.net> <551C32B9.3020507@tzi.org> <551CF3F8.2040708@tzi.de> <551D0B98.4020407@gmx.net> <551D0F6F.2070700@tzi.de> In-Reply-To: <551D0F6F.2070700@tzi.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CO50DV61ffApfvGCF70Bu8LHUudhpdeTL" X-Provags-ID: V03:K0:HozK+zUKA5ozXdyuCA+LirgZRfrUZaKF/2LAQrSPon5fJER3Dnp 4mzMj8Lf2dpNEqqo8qSIvizAZ9hU4bb/bhKvUU0JMFijRgfffSIVj3UGgur/BwhFk2okLJP 2TcozpXhSDW6EYhY+Z0Zp/7d+WNyth3ZhFLj5FyJNnccmtvl3ePbxTmOZp46PghOpCNlAn6 ZD+BxnPcfkp0IaOJRcLAg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Michael Richardson , "Ace@ietf.org" Subject: Re: [Ace] Meeting Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:48:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CO50DV61ffApfvGCF70Bu8LHUudhpdeTL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Steffi, of course it would be great to know what other thinks as well. The feedback we got during the meeting was that folks want some terminology and there is a preference for re-using OAuth terminology (since this is something they already know). The problem statement should also be pretty simple to explain. In earlier versions we had the terminology in the use case document already (and then someone removed it). Normally, it does not need a 30+ page document to explain these types of things. Ciao Hannes On 04/02/2015 11:44 AM, Stefanie Gerdes wrote: > Hi Hannes, >=20 > it would still be helpful to know what other people on the list other > than the authors of the documents want and need. I just want to > encourage people to provide input on that. It's easier to come up with = a > useful design if we understand what other people are thinking. >=20 > Best regards, > Steffi >=20 > On 04/02/2015 11:27 AM, Hannes Tschofenig wrote: >> Based on the discussion during the meeting Kepeng and I got the >> impression that the group wants to see a harmonized proposal from the >> key participants involved in that discussion (rather than having >> different ideas floating around). >> >> First, the members of that small design team (consisting of Carsten, >> Steffi, Goeran, and Ludwig*) need to come up with something they can >> agree with among each other. Then, come back to the group and present >> it. Deadline: May. >> >> Ciao >> Hannes >> >> PS: If someone else wants to part of the design team please let Kepeng= >> and myself know. >> >> On 04/02/2015 11:12 AM, G=C3=B6ran Selander wrote: >>> Hi all, >>> >>> I did not want to reopen this discussion, but I want to point out tha= t >>> Ludwig and I wrote the original problem description draft to provide = an >>> architecture model that is able to cover all aspects of the problem >>> we are >>> trying to solve, and enables us to talk about these problems. The >>> updated >>> version reflected the input we got for the informal interrim ACE >>> meeting, >>> so it is already a compromise. >>> >>> I have provided a number of comments on the actors draft, including >>> missing end-to-end security, overall problem statement, etc. I have n= ot >>> received any further comments on the problem description draft. >>> >>> I hear that people want a compromise, I don=E2=80=99t see that adopti= on of one >>> draft will improve the situation - on the contrary - this will just >>> become >>> a repetition of the discussion of the use case document after its >>> adoption. >>> >>> >>> My recommendation for the WG is to set a deadline for the design team= >>> and >>> encourage the team to come up with a common structure and text. >>> >>> That will also create a grace period on the ACE list for more fruitfu= l >>> discussions. >>> >>> Best regards, >>> G=C3=B6ran >>> >>> On 2015-04-02 09:47, "Stefanie Gerdes" wrote: >>> >>>> Hi all, >>>> >>>> On 04/01/2015 08:02 PM, Carsten Bormann wrote: >>>>> >>>>> I certainly don't want to spend the summer polishing this text. >>>>> (If you ask me, it's done; I'm waiting for input from the WG what t= o >>>>> fix.) >>>> >>>> I would really like to know what other WG participants think about >>>> this. >>>> I wrote the original actors draft to provide for an architecture mod= el >>>> that is able to cover all aspects of the problem we are trying to >>>> solve, >>>> and enables us to talk about these problems. Until now no one was ab= le >>>> to tell me what was missing in the original draft. >>>> >>>> I'm still wondering if it wouldn't have been easier to make the >>>> original >>>> actors draft a working group document when people asked for that and= >>>> include what is missing afterwards (if there really was anything to >>>> change other than the terminology). I get that people want a comprom= ise >>>> but the original actors draft already was that compromise. >>>> >>>> Best regards, >>>> Steffi >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> >=20 --CO50DV61ffApfvGCF70Bu8LHUudhpdeTL 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVJrtoAAoJEGhJURNOOiAtfZMH/0kQrcd28iPVfm0fyXXU9dhU QKZ2RhA9P2o0MgX2Ls9jsDjvU69R8L+m0+JZe/G3euyUV1XDQZtzBcKOMg/sHu/H +JenLjZyuarThpG8LTfhDGWYKtFLOI+PT/hX61WOgfdU6o79XKpu8trqTVU+KM00 FfLMTMZG5WH9Ithemv9ORnFohAIdApD3KmUCyJkDmg8WRwNgAeEDfkKXinBCEFDo dMMzLzyXG6UBI1e7C47SX8GG5UmzDMHJueAl/CBpEB0i5HlkF/37lysoSGNja69h RKHK/tTEn++wDBX7MjpRxxdsGCFrrw9c1Er9cluRwPCa0b5e0J1OJ90Fcy5ulCg= =0sHL -----END PGP SIGNATURE----- --CO50DV61ffApfvGCF70Bu8LHUudhpdeTL-- From nobody Thu Apr 9 22:10:47 2015 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 AABFD1ACD87 for ; Thu, 9 Apr 2015 22:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, 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 mnDI-IeETByG for ; Thu, 9 Apr 2015 22:10:45 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 387A81ACD84 for ; Thu, 9 Apr 2015 22:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1428642641; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=AxekH+6LOMjT21tgNsXKZZJu/d+RYzqG5Q79tIf+jp4=; b=sf3+okE/jgzJiIiS6RMbSYFntrHo0WAsNvjv1LR1wr1udGPjMaWcKUtEPZQawvRilOrIJ+SQM03sl2umIQa7gZbxbOdNio6QPhdaysFB7dXtJBJ5zh+u9JDbMB/txe2aauOIvcr7PRhXug2MT89ocUyRRxKu5kYcITmXKG+K/ZI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03022; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.1.151.84(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.187) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Apr 2015 13:10:37 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 10 Apr 2015 13:10:32 +0800 From: "Kepeng Li" To: Hannes Tschofenig , "Ace@ietf.org" Message-ID: Thread-Topic: [Ace] WGLC for draft-ietf-ace-usecases-03 References: <551A9644.9050608@gmx.net> In-Reply-To: <551A9644.9050608@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-usecases-03 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, 10 Apr 2015 05:10:46 -0000 Kindly remind you to review use case document. WGLC will end on Tuesday, April 14. Especially our volunteers: Carsten, Dominique, Raj, Steve, Nguyen. Thank you! Kind Regards Kepeng =D4=DA 31/3/15 8:42 pm=A3=AC "Hannes Tschofenig" =D0=B4=C8=EB: >Hi, > >at the IETF meeting in Dallas last week we received feedback that the >use case document is ready for a working group last call. > >Hence, we would like to start a WGLC on draft-ietf-ace-usecases-03. >This will be a 2-week last call, so it will end on Tuesday, April 14. > >Please send comments to the list. > >Thanks! > >Ciao >Hannes & Kepeng > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Sat Apr 11 09:26:42 2015 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 6B0CD1A6F03 for ; Sat, 11 Apr 2015 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.623 X-Spam-Level: *** X-Spam-Status: No, score=3.623 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 fkwu2CMF3k0X for ; Sat, 11 Apr 2015 09:26:39 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACF81A1AFF for ; Sat, 11 Apr 2015 09:26:38 -0700 (PDT) Received: by layy10 with SMTP id y10so31888070lay.0 for ; Sat, 11 Apr 2015 09:26:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=vlb2h9davjBSHLlU6494Sqsu9INs3JwZbBruHAPaXPQ=; b=ewrbZSsUDTC9jnVh12vMMP9esW96gamFWttp/mI7KcI13D2qtuZA0TKFtZ95L5bgO9 8FH0unVHqiLs+6AFoONwp8wabeS5mezWe2/2GFiUfoC1JhPKYiXp2u2yTcVwG99QKhKO M9+ay2gy3X2sGX1OyqTIHxgfbRkggydkBaS9g1Oat5FRehvUSK1V+x2UHshIafw58it7 W60NPop3CXEkJSeBFZpD69/7G3A5Towjls/Bt32CzIUtA2Om+gI8LS9qYh/Emri/1new jfOEWbVpiBwKag6yhSXXw4e/GsyJCtHrl82YDH5hEQOi9Jd9AUX59ZbhfHanO2IwOkf6 zRAQ== X-Gm-Message-State: ALoCoQktgCRQ3F/Km7/DMPdD1Om85Rt7FjEIEL0Nz2YLaE/U7OWnBQ1wTuLSlpSocYlD7XLnqu36 MIME-Version: 1.0 X-Received: by 10.112.135.131 with SMTP id ps3mr1090887lbb.84.1428769596520; Sat, 11 Apr 2015 09:26:36 -0700 (PDT) Received: by 10.152.111.103 with HTTP; Sat, 11 Apr 2015 09:26:36 -0700 (PDT) Date: Sat, 11 Apr 2015 18:26:36 +0200 Message-ID: From: Samuel Erdtman To: Ace@ietf.org Content-Type: multipart/alternative; boundary=089e0112c270444fa005137558e9 Archived-At: Subject: [Ace] draft-ietf-ace-usecases-03 WGLC review 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, 11 Apr 2015 16:26:41 -0000 --089e0112c270444fa005137558e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for writing a great document, first time I=C2=B4m sending in review comments so I hope I=C2=B4m doing it the right way. =3D Abstract and Introduction Theses sections are mentioning a connections to CoAP for this document but there is very limited actual connections to CoAP that I can see when reading is it really needed to mention CoAP since it also says that most concepts are general. =3D Missing use case? I see nothing about secure firmware update, could maybe be seen as pushing configuration but it would nice to have it spelled out somewhere. =3D General comment Are the Authorization Problems Summary sections cumulative i.e. if a problem has come up in a previous section it will not be mentioned again or are the sections autonomous? If sections are autonomous I thing at least * 2.3. Personal Health Monitoring Also needs integrity protected data, possible confidentiality too. =3D General comment about Authorization Problems Summary sections Big variation in explanation of why it is a requirement For example =E2=80=9CU1.3 The container owner requires the integrity of the sensor data= that is used for climate control.=E2=80=9D Here it is explained, but not here =E2=80=9CU1.7 The fruit vendor requires the integrity of the data that is u= sed to locate the goods=E2=80=9D It just describes the type of data that needs to be integrity protected and nothing about what. We could guess but in U1.3 we did not have to. It would be super nice if the use case text connected to the authorisation problems e.g. =E2=80=9CAdditionally, the sensor values are used to control the climate wi= thin the cargo containers.=E2=80=9D could add a reference so that it looks like this =E2=80=9CAdditionally, the sensor values are used to control the climate wi= thin the cargo containers (U1.3).=E2=80=9D What is the differens between =E2=80=9CU1.4 The fruit vendor requires the confidentiality of the sensor d= ata that pertains the state of the goods.=E2=80=9D and =E2=80=9CU1.6 The fruit vendor requires the confidentiality of the data tha= t is used to locate the goods.=E2=80=9D Is there really a benefit of splitting U1.6 and U1.7 2.2. Home Automation There is nothing about transferring ownership of the permeant parts of the automated home like air conditioning when selling the home. Further it might be important not to get historical data or it might be important to get historical data. e.g. for the heating system it might be good to know exactly how the home behaves during cold periods however it might not be interesting to know what groseries that has been in the refrigerator. 2.5.3. Advanced Metering Infrastructure Can also feature remote power off, from what I know (I wrote a bit on security for smart meters after seeing a hack at Blackhat Europe last https://www.nexusgroup.com/en/blog/smart-meter-security-and-pki/) 2.6.1. Dynamically Connecting Smart Sports Equipment Maybe the device, could report fitness data to Jody=C2=B4s fitness account = while borrowed. would require Jody to authorise the device to access here account for an hour. Best Regards //Samuel Erdtman --089e0112c270444fa005137558e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for writing a gre= at document, first time I=C2=B4m sending in review comments so I hope I=C2= =B4m doing it the right way.


=3D Ab= stract and Introduction
Theses sections are mentioning a connecti= ons to CoAP for this document but there is very limited actual connections = to CoAP that I can see when reading is it really needed to mention CoAP sin= ce it also says that most concepts are general.

=3D Missing use case?
I see nothing about secure fir= mware update, could maybe be seen as pushing configuration but it would nic= e to have it spelled out somewhere.


=3D General comment
Are the Authorization Problems Summary secti= ons cumulative i.e. if a problem has come up in a previous section it will = not be mentioned again or are the sections autonomous?
If section= s are autonomous I thing at least=C2=A0
* 2.3.=C2=A0 Personal Hea= lth Monitoring
Also needs integrity protected data, possible conf= identiality too.


=3D General commen= t about Authorization Problems Summary sections
Big variation in = explanation of why it is a requirement
For example
=E2= =80=9CU1.3 The container owner requires the integrity of the sensor data th= at is used for climate control.=E2=80=9D
Here it is explained, bu= t not here
=E2=80=9CU1.7 The fruit vendor requires the integrity = of the data that is used to locate the goods=E2=80=9D
It just des= cribes the type of data that needs to be integrity protected and nothing ab= out what. We could guess but in U1.3 we did not have to.

It would be super nice if the use case text connected to the authori= sation problems e.g.=C2=A0
=E2=80=9CAdditionally, the sensor valu= es are used to control the climate within the cargo containers.=E2=80=9D
could add a reference so that it looks like this
=E2=80= =9CAdditionally, the sensor values are used to control the climate within t= he cargo containers (U1.3).=E2=80=9D



What is the differens between=C2=A0
=E2=80=9CU1.= 4 The fruit vendor requires the confidentiality of the sensor data that per= tains the state of the goods.=E2=80=9D
and
=E2=80=9CU1.= 6 The fruit vendor requires the confidentiality of the data that is used to= locate the goods.=E2=80=9D


Is ther= e really a benefit of splitting U1.6 and U1.7


=
2.2.=C2=A0 Home Automation
There is nothing about tran= sferring ownership of the permeant parts of the automated home like air con= ditioning when selling the home. Further it might be important not to get h= istorical data or it might be important to get historical data. e.g. for th= e heating system it might be good to know exactly =C2=A0how the home behave= s during cold periods however it might not be interesting to know what gros= eries that has been in the refrigerator.


2.5.3.=C2=A0 Advanced Metering Infrastructure
Can also feat= ure remote power off, from what I know (I wrote a bit on security for smart= meters after seeing a hack at Blackhat Europe last https://www.nexusgrou= p.com/en/blog/smart-meter-security-and-pki/)

<= br>
2.6.1.=C2=A0 Dynamically Connecting Smart Sports Equipment
Maybe the device, could report fitness data to Jody=C2=B4s fitness = account while borrowed. would require Jody to authorise the device to acces= s here account for an hour.


Best Re= gards
//Samuel Erdtman
--089e0112c270444fa005137558e9-- From nobody Mon Apr 13 18:55:24 2015 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 9ACA31B2C47 for ; Mon, 13 Apr 2015 18:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Wto7qdXc1FQS for ; Mon, 13 Apr 2015 18:55:21 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id E20A41B2C42 for ; Mon, 13 Apr 2015 18:55:20 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3460C72E0F8 for ; Mon, 13 Apr 2015 21:55:20 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 2B45B72E0F6 for ; Mon, 13 Apr 2015 21:55:20 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 13 Apr 2015 21:55:19 -0400 Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 13 Apr 2015 21:55:18 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Mon, 13 Apr 2015 21:55:18 -0400 Received: from DM2PR09MB0317.namprd09.prod.outlook.com (25.160.96.150) by DM2PR09MB0317.namprd09.prod.outlook.com (25.160.96.150) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 14 Apr 2015 01:55:15 +0000 Received: from DM2PR09MB0317.namprd09.prod.outlook.com ([25.160.96.150]) by DM2PR09MB0317.namprd09.prod.outlook.com ([25.160.96.150]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 01:55:15 +0000 From: "Moore, Steve" To: "Ace@ietf.org" Thread-Topic: [Ace] draft-ietf-ace-usecases-03 WGLC review Thread-Index: AQHQdHRbFgABAucXNkydmx4CJZBbnJ1LwCON Date: Tue, 14 Apr 2015 01:55:14 +0000 Message-ID: <1428976512246.53294@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.83.31.3] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0317; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(52604005)(377454003)(2900100001)(450100001)(19625215002)(2501003)(46102003)(36756003)(2656002)(122556002)(2351001)(107886001)(66066001)(86362001)(2950100001)(117636001)(92566002)(230783001)(99286002)(102836002)(110136001)(19627405001)(77156002)(54356999)(87936001)(76176999)(62966003)(50986999)(106116001)(19580405001)(19580395003)(16236675004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR09MB0317; H:DM2PR09MB0317.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DM2PR09MB0317; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0317; x-forefront-prvs: 054642504A Content-Type: multipart/alternative; boundary="_000_142897651224653294mitreorg_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 01:55:14.9095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0317 X-OriginatorOrg: mitre.org Archived-At: Subject: Re: [Ace] draft-ietf-ace-usecases-03 WGLC review 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, 14 Apr 2015 01:55:23 -0000 --_000_142897651224653294mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I apologize for chiming in so late on the WGLC, but I also don't think I ha= ve any comments that are show stoppers so to speak. Most of my comments were echoed by Samual, so I'll just steal parts of his = email here and add on in line. ________________________________ > From: Ace on behalf of Samuel Erdtman > Sent: Saturday, April 11, 2015 12:26 PM > To: Ace@ietf.org > Subject: [Ace] draft-ietf-ace-usecases-03 WGLC review > > Hi, > > Thanks for writing a great document, first time I=B4m sending in review c= omments so I hope I=B4m doing it the right way. Same here! I liked the document and the scope of use cases it contained. >=3D Missing use case? >I see nothing about secure firmware update, could maybe be seen as pushing= configuration but it would nice to have it spelled out somewhere. I agree that this is important, but I'm not really sure that the Authentica= tion and Authorization part applies to it. (Although you could make the cas= e that the firmware is another resource on the device maybe?) > 2.2. Home Automation > There is nothing about transferring ownership of the permeant parts of th= e automated home like air conditioning when selling the home. Further it mi= ght be important not to get > historical data or it might be important to g= et historical data. e.g. for the heating system it might be good to know ex= actly how the home behaves during cold periods however it might > not be i= nteresting to know what groseries that has been in the refrigerator. This thought also crossed my mind it is touched upon with the re-provisioni= ng that is mentioned in U4.2 under the building automation. Handing over th= e permanent parts of the house would probably be part of the authorization/= authentication server for the house, but the historical data might be more = of a feature of the home gateway/aggregation service (Or a cloud based home= management system). ?Other than those small thoughts, I think the document looks good to go! -steve --_000_142897651224653294mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I apologize for chiming in so late on the WGLC, but I also don't think I= have any comments that are show stoppers so to speak.

Most of my comments were echoed by Samual, so I'll just steal parts of&n= bsp;his email here and add on in line.

> From: Ace <ace= -bounces@ietf.org> on behalf of Samuel Erdtman <samuel@erdtman.se>=
> Sent: Saturday, April 11, 2015 12:26 PM
> To: Ace@ietf.org
> Subject: [Ace] draft-ietf-ace-usecases-03 WGLC review
> 
> Hi,
>
> Thanks for writing a great document, first time I=B4m sendin= g in review comments so I hope I=B4m doing it the right way.

Same here! I liked the document and the scope of use cases it containe= d.


>=3D Missing use case?
>I see nothing about secure firmware update, could maybe be seen as= pushing configuration but it would nice to have it spelled out somewhere.<= /div>

I agree that this is important, but I'm not really sure that the Authentica= tion and Authorization part applies to it. (Although you could make the cas= e that the firmware is another resource on the device maybe?)

> 2.2.  Home Automation
> There is nothing about transferring ownership of the permean= t parts of the automated home like air conditioning when selling the home. = Further it might be important not to get > historical data or it mi= ght be important to get historical data. e.g. for the heating system it might be good to know exactly  how the home beh= aves during cold periods however it might > not be interesting to k= now what groseries that has been in the refrigerator.

This thought also crossed my mind it is touched upon with the re-provi= sioning that is mentioned in U4.2 under the building automation. Handing ov= er the permanent parts of the house would probably be part of the authorization/authentication server for the house, but the historic= al data might be more of a feature of the home gateway/aggregation ser= vice (Or a cloud based home management system).



​Other than those small thoughts, I think the document looks good to = go!
-steve
--_000_142897651224653294mitreorg_-- From nobody Fri Apr 17 03:08:11 2015 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 E2CA41AD1A3; Fri, 17 Apr 2015 03:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 6YLr2GCCarsG; Fri, 17 Apr 2015 03:08:04 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9954F1AD26B; Fri, 17 Apr 2015 03:08:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A+BQAE2TBV/wQXEqxdg15cxW2BeAELhgGCIAEBAQEBAX6EI3sCIgYyTRgKCAkSiByxVQEBlh4BAQEBBgEBAQEBAQEbhTJihRWEWh4EgjRNHYEWBYs2iWiHeZMzhBlnAYJCAQEB X-IPAS-Result: A2A+BQAE2TBV/wQXEqxdg15cxW2BeAELhgGCIAEBAQEBAX6EI3sCIgYyTRgKCAkSiByxVQEBlh4BAQEBBgEBAQEBAQEbhTJihRWEWh4EgjRNHYEWBYs2iWiHeZMzhBlnAYJCAQEB X-IronPort-AV: E=Sophos;i="5.11,593,1422901800"; d="scan'208";a="667097430" To: dtls-iot@ietf.org, core@ietf.org, Ace@ietf.org MIME-Version: 1.0 X-KeepSent: DD80B75F:0487AB83-65257E2A:0035ED67; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Fri, 17 Apr 2015 15:37:57 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP2HF609 | December 16, 2014) at 04/17/2015 15:37:58, Serialize complete at 04/17/2015 15:37:58 Content-Type: multipart/alternative; boundary="=_alternative 0037A94865257E2A_=" Archived-At: Cc: Arijit Ukil , Soma Bandyopadhyay , Arpan Pal , Tulika Bose Subject: [Ace] New Version Notification for draft-bhattacharyya-dice-less-on-coap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 10:08:08 -0000 This is a multipart message in MIME format. --=_alternative 0037A94865257E2A_= Content-Type: text/plain; charset="US-ASCII" Dear All, We have submitted an experimental draft proposing a cross-layer approach to provide both object security and channel security for pre-shared-key based systems. We call the proposed method 'LESS (Lightweight Establishment of Secure Session) on CoAP'. This draft is prepared out of a paper on this topic that we presented in "Workshop on Pervasive Internet of Things and Smart Cities (PITSaC-2015)" in conjunction with "Advanced Information Networking and Applications (AINA-2015)", Gwangju, Korea, March, 2015. The draft contains the experimental results as well to demonstrate the benefits achieved using the proposed method. Hope you find the proposed method interesting and useful. Any feedback on the draft is more than welcome. The details about the draft are as below: Name: draft-bhattacharyya-dice-less-on-coap Revision: 00 Title: Lightweight Establishment of Secure Session (LESS) on CoAP Document date: 2015-04-17 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-bhattacharyya-dice-less-on-coap-00.txt Status: https://datatracker.ietf.org/doc/draft-bhattacharyya-dice-less-on-coap/ Htmlized: http://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00 Abstract: This draft presents an experimental work proposing a lightweight secure session establishment scheme to mutually authenticate two endpoints and share the session key. It works on symmetric cryptosystem with pre-shared secret between the endpoints during provisioning. The main algorithm is proposed as a generic concept. This draft further describes how the generic concept can be modeled as simple CoAP request/response pairs. Thus the proposed scheme enables CoAP with inherent security which might be useful for object security without requiring any secure transport. Still further, this draft demonstrates how the scheme could be integrated with the record encryption mechanism of DTLS-PSK. It reuses the DTLS session parameter structure without any modification. Thus channel security for the whole application message can be provided. So the scheme is a cross-layer mechanism such that the session establishment is performed in CoAP and channel encryption is performed in the transport layer reusing only the record encryption mechanism of DTLS-PSK. The scheme uses all standard encryption libraries. The lightweight nature and performance improvement is demonstrated with some supporting comparative results. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 0037A94865257E2A_= Content-Type: text/html; charset="US-ASCII" Dear All,
We have submitted an experimental draft proposing a cross-layer approach to provide both object security and channel security for pre-shared-key based systems. We call the proposed method 'LESS (Lightweight Establishment of Secure Session) on CoAP'.
This draft is prepared out of a paper on this topic that we presented in "Workshop on Pervasive Internet of Things and Smart Cities (PITSaC-2015)" in conjunction with "Advanced Information Networking and Applications (AINA-2015)", Gwangju, Korea, March, 2015. The draft contains the experimental results as well to demonstrate the benefits achieved using the proposed method.
Hope you find the proposed method interesting and useful. Any feedback on the draft is more than welcome.

The details about the draft are as below:
 
Name:                                  draft-bhattacharyya-dice-less-on-coap
Revision:                 00
Title:                                  Lightweight Establishment of Secure Session (LESS) on CoAP
Document date:                 2015-04-17
Group:                                  Individual Submission
Pages:                                  15
URL:            http://www.ietf.org/internet-drafts/draft-bhattacharyya-dice-less-on-coap-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bhattacharyya-dice-less-on-coap/
Htmlized:       http://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00


Abstract:
  This draft presents an experimental work proposing a lightweight
  secure session establishment scheme to mutually authenticate two
  endpoints and share the session key. It works on symmetric
  cryptosystem with pre-shared secret between the endpoints during
  provisioning. The main algorithm is proposed as a generic concept.
  This draft further describes how the generic concept can be modeled
  as simple CoAP request/response pairs. Thus the proposed scheme
  enables CoAP with inherent security which might be useful for object
  security without requiring any secure transport. Still further, this
  draft demonstrates how the scheme could be integrated with the
  record encryption mechanism of DTLS-PSK. It reuses the DTLS session
  parameter structure without any modification. Thus channel security
  for the whole application message can be provided. So the scheme is
  a cross-layer mechanism such that the session establishment is
  performed in CoAP and channel encryption is performed in the
  transport layer reusing only the record encryption mechanism of
  DTLS-PSK. The scheme uses all standard encryption libraries. The
  lightweight nature and performance improvement is demonstrated with
  some supporting comparative results.


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 0037A94865257E2A_=-- From nobody Sat Apr 18 20:37:30 2015 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 283091ACEDE for ; Sat, 18 Apr 2015 20:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.35 X-Spam-Level: ** X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, 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 AQ5YZyClsohj for ; Sat, 18 Apr 2015 20:37:26 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 581781ACEDD for ; Sat, 18 Apr 2015 20:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1429414644; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=t4wdVXLbuKDFamCwAWTuyGlCMeeW7ai5T/7/eGaxSIA=; b=iit+BRDz0wgVyDUgjfpUgqOE9xE40EYK5H983gcLzEbvfjxYfqEvTFpgtqw+MR9UFnywx9FpOIEG1JJHMet63VvKfsLir1ZvSEi5e+QdmO/lv4n3NZzHj2SMnRGWgjmFQaDcGAAk9nz0IVNbRrlwBF9H00OzoAKG0iF6IjOvjyE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R491e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g06005; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.22.54.68(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 19 Apr 2015 11:37:20 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 19 Apr 2015 10:52:44 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: Poll for interim meeting time Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: Hannes Tschofenig Subject: [Ace] Poll for interim meeting time X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 03:37:28 -0000 Hello all, Several people indicated the needs to have an interim meeting in May to help advance the harmonized actors and problem description draft. I created a doodle poll for this interim meeting: http://doodle.com/a2es7bk8tg4eaavp Options are 19th(Tuesday), 20th(Wednesday), 21st(Thursday), 26th(Tuesday), 27th(Wednesday), 28th(Thursday) May, GMT 14:00 ~ 16:00. Please indicate your availability in the doodle poll. Thanks, Kind Regards Kepeng =D4=DA 2/4/15 1:06 am=A3=AC "Hannes Tschofenig" =D0=B4=C8=EB: >That's a good idea, Michael. > >It would also set a hard deadline for folks to agree on the text. > >> I wonder if a virtual interim might help advance this, and reduce the >>time >> needs at the next meeting? > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Sat Apr 18 23:16:10 2015 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 6AEB11AD352 for ; Sat, 18 Apr 2015 23:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 quc2yXw1f-LA for ; Sat, 18 Apr 2015 23:16:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F45D1AD355 for ; Sat, 18 Apr 2015 23:16:06 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-5c-553348242328 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 99.59.19337.42843355; Sun, 19 Apr 2015 08:16:04 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Sun, 19 Apr 2015 08:16:03 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Kepeng Li Thread-Topic: [Ace] Poll for interim meeting time Thread-Index: AQHQelIrNmOjBAa9kkSLPdSKvCd0GJ1TunSA Date: Sun, 19 Apr 2015 06:16:03 +0000 Message-ID: <27B462AC-FCD1-4DCA-AA85-EEED5A53BACD@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-1E2F68A9-93CC-4E69-970C-3FC4030F0EEA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvja6Kh3GowcteQYvv33qYLZbuvMdq cXl+kQOzx8S3H1k8Fm/az+axZMlPpgDmKC6blNSczLLUIn27BK6Mu+0LWAuWGVb837uCqYHx lX4XIyeHhICJxJPVj9kgbDGJC/fWA9lcHEICRxkllu+4wQrhLGaU2HNoPjtIFZuAi8SDhkdM ILaIgJbEnytXwWxmgSCJKSums4LYwgIGEk3LZrND1BhKfJk8jw3CNpLourkbLM4ioCrxfeVp MJtXwF5i8dluxi5GDqBlZhJLm4VAwpwC5hJLV84FK2EEOu77qTVQq8Qlbj2ZzwRxtIjEw4un oR4QlXj5+B/YzcwCkxklpi9bwQYxX1Di5MwnLBMYRWYh6Z+FrG4WkjqIIk2J/d3LoWxFiSnd D9khbGuJGb8OskHYphKvj35kRFazgJFjFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgFB7c 8lt1B+PlN46HGAU4GJV4eBNcjEOFWBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8q zUktPsTIxMEp1cDYM1tJSCDg5Z29/fPfJrbKXY5RFXj57lh0gJX8n2XrnhXIyvPt6tJabslz t6BCUzLrd2jRCX6mSw/8nvm/erXbKcLHvtHS1U3MfQpve24KR67z/UUrZ7tvyM+LmfThFPv1 rp4o4dk1Zalije5L7eL3NNho7TZaXDazcJcM+9LypdLH+JRVm5VYijMSDbWYi4oTAdPW7Aaj AgAA Archived-At: Cc: Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] Poll for interim meeting time X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 06:16:09 -0000 --Apple-Mail-1E2F68A9-93CC-4E69-970C-3FC4030F0EEA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgS2VwZW5nLA0KDQpJIHRoaW5rIHRoZSB0cmVhZCB5b3UgcXVvdGUgbWF5IGJlIG9ic29sZXRl LCBzZWUgbW9yZSByZWNlbnQgbWFpbHMgYnkgQ2Fyc3RlbiBhbmQgSGFubmVzLiANCg0KVGhlIGVk aXRpbmcgdGVhbSBoYXMgaGFkIHR3byBtZWV0aW5ncyBhbmQgZXNzZW50aWFsbHkgY29udmVyZ2Vk IG9uIHNlY3Rpb25zIDEtMiBpbmNsdWRpbmcgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFncmVlZCBp biBEYWxsYXMuIFdlIGhhZCBhIHRoaXJkIG1lZXRpbmcgc2NoZWR1bGVkIGZvciBsYXN0IFRodXJz ZGF5IGJ1dCBpcyBwb3N0cG9uZWQgdW50aWwgdGhpcyBUaHVyc2RheSBiZWNhdXNlIG9mIGxhY2sg b2YgdGltZSB0byBwcm9ncmVzcyB0aGUgd29yay4gSW5zdGVhZCB3ZSBwbGFuIHRvIGhhdmUgaW50 ZXJyaW0gZW1haWwgcmV2aWV3IGJlZm9yZSBuZXh0IG1lZXRpbmcuIElmIHRoZSBwcm9ncmVzcyBj b250aW51ZXMgYXMgaXQgc3RhcnRlZCBJIHNlZSBubyByZWFzb24gd2h5IHdlIGNvdWxkbid0IGNv bnZlcmdlIHNvbWV0aW1lIGluIE1heSwgd2hpY2ggd2hhdCBJIHVuZGVyc3Rvb2QgaXMgdGhlIGRl YWRsaW5lIGdpdmVuIHRvIHRoZSBlZGl0aW5nIHRlYW0uIA0KDQpJJ20gbm90IHN1cmUgYW4gaW50 ZXJyaW0gbWVldGluZyB3b3VsZCBjb250cmlidXRlIHRvIHRoZSBwcm9ncmVzcywgYnV0IGNvdWxk IGFjdHVhbGx5IHJlb3BlbiB0aGluZ3MgYWxyZWFkeSBjb25jbHVkZWQuIA0KDQpZb3UgaGF2ZSBn aXZlbiB0aGUgZWRpdGluZyB0ZWFtIGEgdGFzayBhbmQgYSBkZWFkbGluZSwgd2h5IG5vdCBnaXZl IHRoZW0gYSBjaGFuY2UgdG8gY29tcGxldGUgdGhlIHRhc2sgb24gdGltZT8gDQoNCg0KQmVzdCBy ZWdhcmRzLA0KR8O2cmFuDQoNCg0KDQoNCj4gT24gMTkgYXByIDIwMTUsIGF0IDA1OjM3LCBLZXBl bmcgTGkgPGtlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tPiB3cm90ZToNCj4gDQo+IEhlbGxvIGFs bCwNCj4gDQo+IFNldmVyYWwgcGVvcGxlIGluZGljYXRlZCB0aGUgbmVlZHMgdG8gaGF2ZSBhbiBp bnRlcmltIG1lZXRpbmcgaW4gTWF5IHRvDQo+IGhlbHAgYWR2YW5jZSB0aGUgaGFybW9uaXplZCBh Y3RvcnMgYW5kIHByb2JsZW0gZGVzY3JpcHRpb24gZHJhZnQuDQo+IA0KPiBJIGNyZWF0ZWQgYSBk b29kbGUgcG9sbCBmb3IgdGhpcyBpbnRlcmltIG1lZXRpbmc6DQo+IGh0dHA6Ly9kb29kbGUuY29t L2EyZXM3Yms4dGc0ZWFhdnANCj4gDQo+IA0KPiBPcHRpb25zIGFyZSAxOXRoKFR1ZXNkYXkpLCAy MHRoKFdlZG5lc2RheSksIDIxc3QoVGh1cnNkYXkpLCAyNnRoKFR1ZXNkYXkpLA0KPiAyN3RoKFdl ZG5lc2RheSksIDI4dGgoVGh1cnNkYXkpIE1heSwgR01UIDE0OjAwIH4gMTY6MDAuDQo+IA0KPiBQ bGVhc2UgaW5kaWNhdGUgeW91ciBhdmFpbGFiaWxpdHkgaW4gdGhlIGRvb2RsZSBwb2xsLg0KPiAN Cj4gVGhhbmtzLA0KPiANCj4gS2luZCBSZWdhcmRzDQo+IEtlcGVuZw0KPiANCj4gDQo+IOWcqCAy LzQvMTUgMTowNiBhbe+8jCAiSGFubmVzIFRzY2hvZmVuaWciIDxoYW5uZXMudHNjaG9mZW5pZ0Bn bXgubmV0PiDlhpnlhaU6DQo+IA0KPj4gVGhhdCdzIGEgZ29vZCBpZGVhLCBNaWNoYWVsLg0KPj4g DQo+PiBJdCB3b3VsZCBhbHNvIHNldCBhIGhhcmQgZGVhZGxpbmUgZm9yIGZvbGtzIHRvIGFncmVl IG9uIHRoZSB0ZXh0Lg0KPj4gDQo+Pj4gSSB3b25kZXIgaWYgYSB2aXJ0dWFsIGludGVyaW0gbWln aHQgaGVscCBhZHZhbmNlIHRoaXMsIGFuZCByZWR1Y2UgdGhlDQo+Pj4gdGltZQ0KPj4+IG5lZWRz IGF0IHRoZSBuZXh0IG1lZXRpbmc/DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBBY2UgbWFpbGluZyBsaXN0DQo+PiBBY2VAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQWNl IG1haWxpbmcgbGlzdA0KPiBBY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2UNCg== --Apple-Mail-1E2F68A9-93CC-4E69-970C-3FC4030F0EEA Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9jCCBfIw ggPaoAMCAQICED5j3SSNCPxYeGdCFol+BckwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjIyMDky NjE0WhcNMTcxMjIyMDkyNjEzWjBrMREwDwYDVQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPR8O2cmFu IFNlbGFuZGVyMSowKAYJKoZIhvcNAQkBFhtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20xEDAO BgNVBAUTB2VyYWdvc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCSU5mmTfwCXmA8 +o6zD0QBUzHdSI8Nnh1/IJqdUCNMsXGhyh13VB0fb/dlvGxNuFK7EKzKAmV54EVajL+FRucgxen9 lcC7bp4f1qd3au9kgOXYKzHuw9btR1xuqWG+fvzrZGaSAt2bewZenaZnyZWxoX9o7ia2ZviWktr0 frBlXciopyIlMnIgZ4D4eif47wlcX/ZPATYvm+AkdIH6/PqkY/8Cq3FMILYvrRvO5X1przyuLH+d suuETUeGbbHQrU+C2DKJnE6xVm4K9nXBvpcfkdKVQuqqg7O71Sd1QRDyt6BCXjrSZ4prRy/n26DU 6FMcIn2DkeXdWnm8SpxxoE/zAgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEF BQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYB BQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1 YWxjYXYyLmNlcjAmBgNVHREEHzAdgRtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20wVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0G A1UdDgQWBBSB4nTbn3t1sB2zhLxonZW3Hhv9/zAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52 cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBANSVTbxCbSceXCp/tX+UCloB 5q5UI743Q5vKV+h+TB86caGnHBuBtHatVJTD/k+myt8+B+Iu60M2UrX3gBmwSTW6Y8MZhtXYijOM OPvKVyqHkf9ikVMWDBKG+b6O9UB+EomtcfZ7cElXCu/AjXW4Q7CZWVwPrJORLec6mfER9usYEa0O x+meWW5sRDKVHTFgVgsub3+4ouzgOQpsqGrQydYhovIptNPalWGSSTMYpW+r6rukSQ/sUjl54pCA SZj5zs9mQu9fhRtm4I+9HcBNSe1+yq6ECW0Zvc82ynYTFx3w0Art1hmmnd7euM17JzpORrh3y07D ey0wc3RoP4z4ISNffsC+z+jVMl54H1PYYiDuHiPf+cMorlMXFPs7rTFgZS/mY1B2v+qZP9O9k4i/ g4HPQlsJgnWxC5TWluMsOHzQS35FR+oei/35aDwNYvdPixeWNhUmkR4vtfydjpLW+3eKyxcf0Hf/ SVJuzMYrnssBFe+jYNGJYGvdOFjJFffqKCcRocJ0l25ALTVDtv3kpZap6YZXaBAeYTncGWVyv9te bhtILVdqlO7sLtP3zAGZ46bPTW/54F7TOwZ+kfI0vptFgJN5iAA8GwOvhBatrNw9oA9dM2ioAlBb iD3gQ8Fz7Mxq/5AkpSdt3Gzxd7HNwhi5GIkuyPtq1U7B/o19KWC7MYICljCCApICAQEwTjA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQ PmPdJI0I/Fh4Z0IWiX4FyTAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNTA0MTkwNjE2MDNaMCMGCSqGSIb3DQEJBDEWBBQvNCAzvSFr5Qm8 jRI5+sKNBvMgcDBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+Y90kjQj8WHhnQhaJfgXJMF8GCyqGSIb3 DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIQPmPdJI0I/Fh4Z0IWiX4FyTANBgkqhkiG9w0BAQEFAASCAQAjcwNBamyR 2D9/r97YNR1IiqawEABi4i4fdbmnJF8cJeICCwlJ6SDJ5dUCCRUJ1DBGY8U/b7Y8jw77bwnqAsOs 7MR6HLfuOAf7qJf1581s00/Cnzm7F9DnlMiST6jxQbQoas5uGHq5OrIkDRtSBdeImA5+e8UJz0B0 vuPXyKpAs8jAVES3ystjQEPA/lM6ez1U7+m17TA0ELtOMGGx3YeSOZR5L0iRjXIg8qYbFf1koer+ T5IeoV5vXLxveRG9pqLmVTen4iBhp/3QPO5kNosoxzM/tbB+lJF6wLxeaoa3iGnoi+jKzBlXwXyG Mz31g7Tw03G5Yg5fRMEH0MIgQb6EAAAAAAAA --Apple-Mail-1E2F68A9-93CC-4E69-970C-3FC4030F0EEA-- From nobody Sat Apr 18 23:20:18 2015 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 494D31AD368 for ; Sat, 18 Apr 2015 23:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2I_PXgiIyA5T for ; Sat, 18 Apr 2015 23:20:16 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B0D1AD36A for ; Sat, 18 Apr 2015 23:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t3J6K7eY000115; Sun, 19 Apr 2015 08:20:07 +0200 (CEST) Received: from alma.local (p5DC7F099.dip0.t-ipconnect.de [93.199.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lV1Gv1MpJz2vFx; Sun, 19 Apr 2015 08:20:07 +0200 (CEST) Date: Sun, 19 Apr 2015 08:20:06 +0200 From: Carsten Bormann To: =?utf-8?Q?G=C3=B6ran_Selander?= , Kepeng Li Message-ID: In-Reply-To: <27B462AC-FCD1-4DCA-AA85-EEED5A53BACD@ericsson.com> References: <27B462AC-FCD1-4DCA-AA85-EEED5A53BACD@ericsson.com> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55334916_6bc9da3b_2525" Archived-At: Cc: Hannes Tschofenig , "=?utf-8?Q?Ace=40ietf.org?=" Subject: Re: [Ace] Poll for interim meeting time X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 06:20:17 -0000 --55334916_6bc9da3b_2525 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 19 Apr 2015 at 08:16:20, G=C3=B6ran Selander (goran.selander=40ericsso= n.com) wrote: I'm not sure an interrim meeting would contribute to the progress, but co= uld actually reopen things already concluded.=C2=A0 +1 We could use an interim meeting, though, to put a lid on the work on the = informational documents and finally refocus on the standards work. =C2=A0= The end-of-May timing should be about right for that. Gr=C3=BC=C3=9Fe, Carsten --55334916_6bc9da3b_2525 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On = 19 Apr 2015 at 08:16:20, G=C3=B6ran Selander (goran.selander@ericsson.com) wrote:
I'm not sure an interrim meeting would contribute = to the progress, but could actually reopen things already concluded. 

+1

We could use an interim meeting, though, to put a lid on the= work on the informational documents and finally refocus on the standards wo= rk.  The end-of-May timing should be about right for that.

Gr=C3=BC=C3=9Fe, Carsten

--B_3512301632_1410347-- From nobody Sun Apr 19 04:25:45 2015 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 D52EF1AC442 for ; Sun, 19 Apr 2015 04:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 xvCE1NxDxMjy for ; Sun, 19 Apr 2015 04:25:42 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B6C1AC3D6 for ; Sun, 19 Apr 2015 04:25:41 -0700 (PDT) Received: by qkhg7 with SMTP id g7so176053596qkh.2 for ; Sun, 19 Apr 2015 04:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JYDNSzAvMUYWPMQIKNCu1xLtD/EerUGUrglzMonOqRY=; b=iv3+LLRACeGmN9byhP7OWsVkJnmAtj/jLkDhvpjRM6r7Iy68MjgcEsByaTxfDRZ0GE 6IuKOc+bFWrADlkhbrqlkVVShvgc1hljFQ4Z670+iV9KWxoOAp3VK7ChLsVjPnmhf3Fl 8ajQSvgDUhG2jarNCk863Gr53pKhlYRNy82OSAUiDKMMgIcktnUIDjzAmQSl76qsTQI/ ee+6oKsX8OFk+sJ4dWKa4n95DTAUSpE+15jG8U50RfabzRIQaImZSTLghJf6jcM0klRh kjQF3XrpO5PYhYKWowWjkQer5RsWEWSeF4FBRG72QpKmAvNeofaEmzs3fFBwVzpHVt0Q h6AQ== X-Received: by 10.140.98.245 with SMTP id o108mr12245366qge.36.1429442740988; Sun, 19 Apr 2015 04:25:40 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id j93sm12050897qkh.29.2015.04.19.04.25.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Apr 2015 04:25:39 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-A07F2C2E-51FA-4ECA-AAC0-76522FD380FF Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sun, 19 Apr 2015 07:25:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <27B462AC-FCD1-4DCA-AA85-EEED5A53BACD@ericsson.com> To: Kepeng Li Archived-At: Cc: Hannes Tschofenig , Carsten Bormann , =?utf-8?Q?G=C3=B6ran_Selander?= , "Ace@ietf.org" Subject: Re: [Ace] Poll for interim meeting time X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 11:25:44 -0000 --Apple-Mail-A07F2C2E-51FA-4ECA-AAC0-76522FD380FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Apr 19, 2015, at 3:20 AM, "Kepeng Li" wrot= e: >=20 > >We could use an interim meeting, though, to put a lid on the work on the i= nformational documents and finally refocus on the standards work. The end-o= f-May timing should be about right for that. >=20 > Yes, we can use the meeting to discuss some open issues raised from your d= esign team. >=20 > It can help people outside the design team to understand what you have con= cluded, what are the considerations behind, etc. +1 I agree with Kepeng. This may help with broader involvement from the WG. Kathleen=20 >=20 > I don=E2=80=99t think it has any harm.=20 >=20 > If we don=E2=80=99t have big open issues, that is also fine and the meetin= g can be shorter. >=20 > Kind Regards > Kepeng > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Carsten Bormann > =E6=97=A5=E6=9C=9F: Sunday, 19 April, 2015 2:20 pm > =E8=87=B3: G=C3=B6ran Selander , Li Kepeng > =E6=8A=84=E9=80=81: "Ace@ietf.org" , Hannes Tschofenig > =E4=B8=BB=E9=A2=98: Re: [Ace] Poll for interim meeting time >=20 >> On 19 Apr 2015 at 08:16:20, G=C3=B6ran Selander (goran.selander@ericsson.= com) wrote: >> I'm not sure an interrim meeting would contribute to the progress, but co= uld actually reopen things already concluded.=20 >=20 > +1 >=20 > We could use an interim meeting, though, to put a lid on the work on the i= nformational documents and finally refocus on the standards work. The end-o= f-May timing should be about right for that. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail-A07F2C2E-51FA-4ECA-AAC0-76522FD380FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Apr 19, 2015, at 3:20 AM, "Kepeng Li" <kepeng.lkp@alibaba-inc.com> wrote:

>We could use an interim meeting, thoug= h, to put a lid on the work on the informational documents and finally refoc= us on the standards work.  The end-of-May timing should be about right f= or that.

Yes, we can use the meeting to discuss som= e open issues raised from your design team.

It can h= elp people outside the design team to understand what you have concluded, wh= at are the considerations behind, etc.

+1

I agree with Kepeng.  This may help with broade= r involvement from the WG.

Kathleen 

I don=E2=80=99t think it has an= y harm. 

If we don=E2=80=99t have big open iss= ues, that is also fine and the meeting can be shorter.

<= div>Kind Regards
Kepeng
 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Carsten Bo= rmann <cabo@tzi.org>
=E6=97=A5=E6=9C=9F: Sunday, 19 April, 2015 2:= 20 pm
=E8=87=B3: G=C3=B6ran Sela= nder <goran.selander@erics= son.com>, Li Kepeng <kepeng.lkp@alibaba-inc.com>
=E6=8A= =84=E9=80=81: "Ace@ietf.org" <= ;ace@ietf.org>, Hannes Tschofenig <= ;hannes.tschofenig@gmx.net&= gt;
=E4=B8=BB=E9=A2=98: Re: [Ace= ] Poll for interim meeting time

<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:1= 3px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On 19 Apr 2015= at 08:16:20, G=C3=B6ran Selander (goran.selander@ericsson.com) wrote:
<= div>I'm not sure an interrim meeting would contribut= e to the progress, but could actually reopen things already concluded. 

+1

We could use an interim meeting, though, to put a lid on t= he work on the informational documents and finally refocus on the standards w= ork.  The end-of-May timing should be about right for that.

Gr=C3=BC=C3=9Fe, Carsten

____________________= ___________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/lis= tinfo/ace
= --Apple-Mail-A07F2C2E-51FA-4ECA-AAC0-76522FD380FF-- From nobody Sun Apr 19 06:10:38 2015 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 B91EA1B2BF7 for ; Sun, 19 Apr 2015 06:10:37 -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 v8FD6KjhnyWr for ; Sun, 19 Apr 2015 06:10:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101D61B2BF2 for ; Sun, 19 Apr 2015 06:10:35 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-3f-5533a9492cd5 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.1C.28835.949A3355; Sun, 19 Apr 2015 15:10:34 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Sun, 19 Apr 2015 15:10:33 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , Kepeng Li Thread-Topic: [Ace] Poll for interim meeting time Thread-Index: AQHQelIrNmOjBAa9kkSLPdSKvCd0GJ1TunSAgAABIgCAAJQzAA== Date: Sun, 19 Apr 2015 13:10:33 +0000 Message-ID: References: <27B462AC-FCD1-4DCA-AA85-EEED5A53BACD@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_D15974982D63Cgoranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM+Jvja7XSuNQg0edTBbfv/UwWxyZcpfV YunOe6wWl+cXObB4THz7kcVj8ab9bB5Llvxk8pi2KDOAJYrLJiU1J7MstUjfLoEr4/sXvYKP IhXdB/8zNTBOEeli5OSQEDCRmL/oMBOELSZx4d56ti5GLg4hgaOMEufaZjNBOIsZJc4ce8wM UsUm4CLxoOERWIeIgJfEhv6DQHEODmaBIInulVogYWEBA4mmZbPZIUoMJb5MnscGYTtJ7P34 gxXEZhFQlXi38A5YDa+AhcT6czsYIXbNYJSY134ebBengJnEnuezWEBsRqDrvp9aA7aXWUBc 4taT+VBXC0gs2QNRLyEgKvHy8T+wBaICehIrrzexQcSVJNYe3s4C0RsrMefAe1aIxYISJ2c+ YZnAKDYLydhZSMpmISmbBfampsT6XfoQJYoSU7ofskPYGhKtc+ZC2dYSvzfcZUVWs4CRYxWj aHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYAQf3PLbagfjweeOhxgFOBiVeHgTXIxDhVgTy4or cw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWBJhHLimO/JhxcVHv1Q+ +r9vLkh8V357+7pVipq5E9uebFQTMLtx6HFjamPCWoE9q5n8bqyYU+f5mSHe5ZbEaxNmxs32 izVe1pdLPc2Im+tiUyT7SPPRUZbtDwKu6iut3Pxh0v8D12/qmpQoz9l+/xybbtyvvpsqj28v Sag84VUWbJLhoeZQrsRSnJFoqMVcVJwIAOshezrBAgAA Archived-At: Cc: Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] Poll for interim meeting time X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 13:10:37 -0000 --_000_D15974982D63Cgoranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpXZSBjb3VsZCB1c2UgYW4gaW50ZXJpbSBtZWV0aW5nLCB0aG91Z2gsIHRvIHB1dCBhIGxpZCBv biB0aGUgd29yayBvbiB0aGUgaW5mb3JtYXRpb25hbCBkb2N1bWVudHMgYW5kIGZpbmFsbHkgcmVm b2N1cyBvbiB0aGUgc3RhbmRhcmRzIHdvcmsuICBUaGUgZW5kLW9mLU1heSB0aW1pbmcgc2hvdWxk IGJlIGFib3V0IHJpZ2h0IGZvciB0aGF0Lg0KDQpJIGFncmVlLiBUaGF0IHdvdWxkIHRoZW4gbW9y ZSBwcmVjaXNlbHkgZGVmaW5lIHRoZSBkZWFkbGluZSBmb3IgdGhlIHByb2JsZW0gZGVzY3JpcHRp b24gZHJhZnQgdG8gYWxsb3cgcmV2aWV3IGJlZm9yZSB0aGUgaW50ZXJpbSBtZWV0aW5nLg0KDQpC ZXN0IHJlZ2FyZHMsDQpHw7ZyYW4NCg== --_000_D15974982D63Cgoranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVj NGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxzdHlsZT5i b2R5e2ZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweH08L3N0eWxlPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgaWQ9ImJs b29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1z aXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdo dDogYXV0bzsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij5XZSBjb3VsZCB1c2UgYW4gaW50ZXJpbSBtZWV0aW5nLCB0aG91 Z2gsIHRvIHB1dCBhIGxpZCBvbiB0aGUgd29yayBvbiB0aGUgaW5mb3JtYXRpb25hbCBkb2N1bWVu dHMgYW5kIGZpbmFsbHkgcmVmb2N1cyBvbiB0aGUgc3RhbmRhcmRzIHdvcmsuICZuYnNwO1RoZSBl bmQtb2YtTWF5IHRpbWluZyBzaG91bGQgYmUgYWJvdXQgcmlnaHQgZm9yIHRoYXQuPC9zcGFuPjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JIGFncmVlLiBUaGF0IHdvdWxkIHRoZW4gbW9yZSBwcmVjaXNlbHkgZGVmaW5lIHRoZSBk ZWFkbGluZSBmb3IgdGhlIHByb2JsZW0gZGVzY3JpcHRpb24gZHJhZnQgdG8gYWxsb3cgcmV2aWV3 IGJlZm9yZSB0aGUgaW50ZXJpbSBtZWV0aW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj5Hw7ZyYW48L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D15974982D63Cgoranselanderericssoncom_-- From nobody Thu Apr 23 01:43:27 2015 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 3ABC51A8979 for ; Thu, 23 Apr 2015 01:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, 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 DXnCAxj4WwV1 for ; Thu, 23 Apr 2015 01:43:23 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 234D71A899C for ; Thu, 23 Apr 2015 01:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1429778589; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=o27zV9F20NOEOW5hYkFoMFZzBQ9ZaOAdLkGCkOgWBqo=; b=bDB+0BJpcuun0TI4vysdm0Pu/XXKp8CQDcNfFDJAElrTT0wmA6pgL+pC4Ni+77y0jX+G1uCOf91gAlX1zmF72ZVtXxR3McRiNJm+xQ0C9wcfPsBVzGGOTKyDl+4ymvnv2pQQNyVDMeYegwTjEqzKcegl78CExdLXmYvxX5DzYYw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g06010; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=5; RT=5; SR=0; Received: from 10.22.56.145(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Thu, 23 Apr 2015 16:43:04 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 23 Apr 2015 01:42:56 +0800 From: "Kepeng Li" To: Kathleen Moriarty , "Ace@ietf.org" Message-ID: Thread-Topic: [Ace] Poll for interim meeting time References: <27B462AC-FCD1-4DCA-AA85-EEED5A53BACD@ericsson.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3512598184_5147961" Archived-At: Cc: Hannes Tschofenig , Carsten Bormann , =?ISO-8859-1?B?R/ZyYW4=?= Selander Subject: Re: [Ace] Poll for interim meeting time 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, 23 Apr 2015 08:43:27 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3512598184_5147961 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello all, We have same number of participants for the call on 26th and 27th May. I just choose 27th May, Wednesday, GMT 14:00 ~ 16:00 for our call. I will send the call bridge information later. Thanks, Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Kathleen Moriarty =E6=97=A5=E6=9C=9F: Sunday, 19 April, 2015 7:25 pm =E8=87=B3: Li Kepeng =E6=8A=84=E9=80=81: Carsten Bormann , G=C3=B6ran Selander , Hannes Tschofenig , "Ace@ietf.org" =E4=B8=BB=E9=A2=98: Re: [Ace] Poll for interim meeting time Sent from my iPhone On Apr 19, 2015, at 3:20 AM, "Kepeng Li" wrote= : >> >We could use an interim meeting, though, to put a lid on the work on th= e >> informational documents and finally refocus on the standards work. The >> end-of-May timing should be about right for that. >=20 > Yes, we can use the meeting to discuss some open issues raised from your > design team. >=20 > It can help people outside the design team to understand what you have > concluded, what are the considerations behind, etc. +1 I agree with Kepeng. This may help with broader involvement from the WG. Kathleen=20 >=20 > I don=E2=80=99t think it has any harm. >=20 > If we don=E2=80=99t have big open issues, that is also fine and the meeting can= be > shorter. >=20 > Kind Regards > Kepeng > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Carsten Bormann > =E6=97=A5=E6=9C=9F: Sunday, 19 April, 2015 2:20 pm > =E8=87=B3: G=C3=B6ran Selander , Li Kepeng > > =E6=8A=84=E9=80=81: "Ace@ietf.org" , Hannes Tschofenig > > =E4=B8=BB=E9=A2=98: Re: [Ace] Poll for interim meeting time >=20 > On 19 Apr 2015 at 08:16:20, G=C3=B6ran Selander (goran.selander@ericsson.com) > wrote: > =20 >> I'm not sure an interrim meeting would contribute to the progress, but c= ould >> actually reopen things already concluded. > +1 >=20 > We could use an interim meeting, though, to put a lid on the work on the > informational documents and finally refocus on the standards work. The > end-of-May timing should be about right for that. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --B_3512598184_5147961 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hello all,

We have same number of participants for the call on 26th and 27th May.=

I just choose 27th May, Wednesday, GMT 14:00 ~ 16:= 00 for our call.

I will send the call bridge inform= ation later.

Thanks,

Kind = Regards
Kepeng

=E5=8F=91= =E4=BB=B6=E4=BA=BA: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
=E6=97=A5=E6=9C=9F: Sunday, 19 April, 2015 7:25 pm
=E8=87=B3: Li Kepeng <kepeng.lkp@alibaba-inc.com>
=E6=8A=84=E9=80=81: Carsten Bormann <cabo@t= zi.org>, G=C3=B6ran Selander <goran.selander@ericsson.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "Ace@ietf.org" <ace= @ietf.org>
=E4=B8=BB=E9=A2=98: Re: [Ace= ] Poll for interim meeting time


Sent from my iPhone

On Apr 19, 2015, at 3:20 AM, "Kepeng = Li" <kepeng.lkp@alibaba-inc.c= om> wrote:

>We coul= d use an interim meeting, though, to put a lid on the work on the informatio= nal documents and finally refocus on the standards work.  The end-of-Ma= y timing should be about right for that.

Yes, we ca= n use the meeting to discuss some open issues raised from your design team.<= /div>

It can help people outside the design team to under= stand what you have concluded, what are the considerations behind, etc.

+1

I agree with Kepeng= .  This may help with broader involvement from the WG.

Kathleen 

= I don’t think it has any harm. 

If we do= n’t have big open issues, that is also fine and the meeting can be sho= rter.

Kind Regards
Kepeng
 = ;

=E5=8F=91=E4=BB=B6=E4=BA=BA: Carsten= Bormann <cabo@tzi.org>
=E6=97=A5=E6=9C=9F: Sunday, 19 April, 2015 2:20 pm
=E8=87=B3: G=C3=B6ran Selander <goran.selander@ericsson.com>, Li Kepeng = <kepeng.lkp@alibaba-inc.com>
=E6=8A=84=E9=80=81: "Ace@ietf.org" <ace@ietf.org= >, Hannes Tschofenig <h= annes.tschofenig@gmx.net>
=E4=B8=BB=E9=A2=98: <= /span> Re: [Ace] Poll for interim meeting time

=
On 19= Apr 2015 at 08:16:20, G=C3=B6ran Selander (goran.selander@ericsson.com) wrote:
I'm not sure an interrim meeting would contribute to= the progress, but could actually reopen things already concluded. 

+1

We could use an interim meeting, though, to put a lid on the w= ork on the informational documents and finally refocus on the standards work= .  The end-of-May timing should be about right for that.

Gr=C3=BC=C3=9Fe, Carsten

=
_______________= ________________________________
Ace mailing list
= Ace@ietf.org
https://www.ietf.org/mailman/li= stinfo/ace
= --B_3512598184_5147961-- From nobody Fri Apr 24 06:10:26 2015 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 F116E1B2F33 for ; Fri, 24 Apr 2015 06:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oavZs_lKRoz1 for ; Fri, 24 Apr 2015 06:10:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D464E1B2F30 for ; Fri, 24 Apr 2015 06:10:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 78C15E1A0 for ; Fri, 24 Apr 2015 09:22:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A1B0E63B86; Fri, 24 Apr 2015 09:10:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8F2C5636A2 for ; Fri, 24 Apr 2015 09:10:20 -0400 (EDT) From: Michael Richardson To: ace@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Subject: [Ace] new use case... only half :-) 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, 24 Apr 2015 13:10:25 -0000 --=-=-= Content-Type: text/plain Now, is this constrained? Probably not very. http://www.nytimes.com/2015/04/23/business/international/audi-to-test-plan-to-deliver-amazon-packages-to-drivers-trunks.html?FRANKFURT >Almost since the invention of the automobile, people have been using >cars for more than just getting from place to place. The car is also a place >to eat, to sleep and soon, it appears, to receive packages. >Audi, the German carmaker, said Wednesday that it would begin testing a >system in Munich next month that would allow people to order goods from >Amazon and have them delivered by DHL, the German package delivery service, >to the trunk of their parked car. >The idea is not completely new. Volvo Cars said more than a year ago that it >was testing a similar system. A Volvo spokesman said Wednesday that the >company has finished its testing and expected to announce soon that it would >be offering the service to consumers in Sweden, where Volvo has its highest >market share. Newer Volvo cars are already equipped with technology that >would enable package delivery to vehicles, the spokesman said. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTpAvICLcPvd0N1lAQLH2Qf+NwZci95VuFgt14z7AVamk2Zu3x4aw0ES 8/IKzwxjXQhv8IEP/Udo/Wd0psgA0rIKHc+2ecQfdAPcU8UYme7/J+7v2heNorlC ShTCgnKQjFZnesQVoMPYn+zVs38e4LjgFSjktSQx/aLr0zawahDxIdBl83uh57Wl ofk1eJ93owFPrfEBUG45F2iEmyEq+8ETerBc+0qP4lApM4VNTzs7tk+SsadIJ7bC ZFORr3XoSiAIK3U6NkCxefM8NPSV3wt/pMwAD+aS9Q4JhnBlzkWz/iZM+nGtT5eC Cenpf/mtIfp9OLUhLgUYmDZUWxACujKeauVcreJaIxxFbiBFa1zZSw== =MF+E -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 24 09:27:14 2015 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 C6CF61B2B9F for ; Fri, 24 Apr 2015 09:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 3fkqMuCjr9qU for ; Fri, 24 Apr 2015 09:27:07 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550C61ACD59 for ; Fri, 24 Apr 2015 09:27:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 25C0FE2038; Fri, 24 Apr 2015 12:27:06 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 07481-01; Fri, 24 Apr 2015 12:27:04 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 19C7BE2036; Fri, 24 Apr 2015 12:27:04 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3OGR315030932; Fri, 24 Apr 2015 12:27:03 -0400 From: Derek Atkins To: Michael Richardson References: <2589.1429881020@sandelman.ca> Date: Fri, 24 Apr 2015 12:27:03 -0400 In-Reply-To: <2589.1429881020@sandelman.ca> (Michael Richardson's message of "Fri, 24 Apr 2015 09:10:20 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] new use case... only half :-) 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, 24 Apr 2015 16:27:11 -0000 Hi, Michael Richardson writes: > Now, is this constrained? Probably not very. By some definitions yes, by other definitions no. It's a powered device, so the power budget is generally unlimited. Similarly, the heat budget is practically unlimited. However there are size, weight, and cost constraints, which means that they will still probably use "low end" devices. I doubt they'll have an i7 or even a Xeon in there. More likely they'll use a low-end ARM (Cortex-M) or possibly even an MSP430 or 8051! -derek > http://www.nytimes.com/2015/04/23/business/international/audi-to-test-plan-to-deliver-amazon-packages-to-drivers-trunks.html?FRANKFURT > >>Almost since the invention of the automobile, people have been using >>cars for more than just getting from place to place. The car is also a place >>to eat, to sleep and soon, it appears, to receive packages. > >>Audi, the German carmaker, said Wednesday that it would begin testing a >>system in Munich next month that would allow people to order goods from >>Amazon and have them delivered by DHL, the German package delivery service, >>to the trunk of their parked car. > >>The idea is not completely new. Volvo Cars said more than a year ago that it >>was testing a similar system. A Volvo spokesman said Wednesday that the >>company has finished its testing and expected to announce soon that it would >>be offering the service to consumers in Sweden, where Volvo has its highest >>market share. Newer Volvo cars are already equipped with technology that >>would enable package delivery to vehicles, the spokesman said. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 24 11:22:47 2015 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 3899E1B2FE8 for ; Fri, 24 Apr 2015 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ugg7lDXXVj0w for ; Fri, 24 Apr 2015 11:22:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594551B2FD2 for ; Fri, 24 Apr 2015 11:22:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C7E1203C0; Fri, 24 Apr 2015 14:34:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 81BA163B86; Fri, 24 Apr 2015 14:22:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6A0A463784; Fri, 24 Apr 2015 14:22:43 -0400 (EDT) From: Michael Richardson To: Derek Atkins In-Reply-To: References: <2589.1429881020@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Cc: ace@ietf.org Subject: Re: [Ace] new use case... only half :-) 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, 24 Apr 2015 18:22:46 -0000 --=-=-= Content-Type: text/plain Derek Atkins wrote: >> Now, is this constrained? Probably not very. > By some definitions yes, by other definitions no. It's a powered > device, so the power budget is generally unlimited. Similarly, the > heat budget is practically unlimited. > However there are size, weight, and cost constraints, which means that > they will still probably use "low end" devices. I doubt they'll have > an i7 or even a Xeon in there. More likely they'll use a low-end ARM > (Cortex-M) or possibly even an MSP430 or 8051! The handheld that the DHL person has is likely at least as powerful as two generation smartphone (i.e. HTC G2/iPhone 4). That's an aweful lot. With 3G connectivity at multiple megabits. The vehicles have at least equivalent devices in the dashboard, which is where the trunk control would be, and also have 3G/LTE connectivity. I see no technical reason why one can't go the entire OAUTH2 route for this kind of thing. But, as you say, I could be wrong. The trunk lock mechanism might be an 8051, true, but I think it will talk to another component in the vehicle, not directly to the DHL handheld. >> http://www.nytimes.com/2015/04/23/business/international/audi-to-test-plan-to-deliver-amazon-packages-to-drivers-trunks.html?FRANKFURT >> >>> Almost since the invention of the automobile, people have been using >>> cars for more than just getting from place to place. The car is also >>> a place to eat, to sleep and soon, it appears, to receive packages. >> >>> Audi, the German carmaker, said Wednesday that it would begin testing >>> a system in Munich next month that would allow people to order goods >>> from Amazon and have them delivered by DHL, the German package >>> delivery service, to the trunk of their parked car. >> >>> The idea is not completely new. Volvo Cars said more than a year ago >>> that it was testing a similar system. A Volvo spokesman said >>> Wednesday that the company has finished its testing and expected to >>> announce soon that it would be offering the service to consumers in >>> Sweden, where Volvo has its highest market share. Newer Volvo cars >>> are already equipped with technology that would enable package >>> delivery to vehicles, the spokesman said. >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ Ace mailing list >> Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace > -- > Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer > and Internet Security Consultant > _______________________________________________ Ace mailing list > Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTqJ84CLcPvd0N1lAQKAUQgAqLeOflQmQxi+KDhWNVbneUS4uI7O8NQc NkISjvGNuCp793f36ki4td/O6vz5kqVSnK+0B48hy/E6cPosaYF5s4cQOgX5rgcH cAatW/PAVkMFcTXCp1S7C2HyeF0y0R2CtFQTilKtWd0SDdpSvGMq6wsNpOO2ngb3 Bqt5sbXWAtM9qjYR1QryIGiYjUO9/Wjscql8rOWfNY3aVUNs0vcxZrfL65/6c8Gn WLmmqiHTueyHiMVP09t9BLllfkCvJhZBh8TnsbilLy5Dkw7dV9WKnXSzvVl0C/rJ wHlY3489DHg3N3P7JMMM037CJzUqN7exq7VCViQe0tC15YezkpTQXw== =cLt/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 24 12:54:18 2015 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 8937A1A049A for ; Fri, 24 Apr 2015 12:54:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 mTQpBkDkvr0o for ; Fri, 24 Apr 2015 12:54:15 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 500091A03E3 for ; Fri, 24 Apr 2015 12:54:15 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 90DE13321D4; Fri, 24 Apr 2015 15:54:14 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 85EC33321D3; Fri, 24 Apr 2015 15:54:14 -0400 (EDT) Received: from imshyb02.MITRE.ORG (129.83.29.3) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 24 Apr 2015 15:54:13 -0400 Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 24 Apr 2015 15:54:14 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Fri, 24 Apr 2015 15:54:13 -0400 Received: from BN1PR09MB0244.namprd09.prod.outlook.com (25.160.80.17) by BN1PR09MB0244.namprd09.prod.outlook.com (25.160.80.17) with Microsoft SMTP Server (TLS) id 15.1.148.16; Fri, 24 Apr 2015 19:54:12 +0000 Received: from BN1PR09MB0244.namprd09.prod.outlook.com ([25.160.80.17]) by BN1PR09MB0244.namprd09.prod.outlook.com ([25.160.80.17]) with mapi id 15.01.0148.008; Fri, 24 Apr 2015 19:54:12 +0000 From: "Kim, William G" To: Michael Richardson , Derek Atkins Thread-Topic: [Ace] new use case... only half :-) Thread-Index: AQHQfpAYN1fmRqlip0+ry22Trp0tRZ1cWfslgAAgNID//9Z+AA== Date: Fri, 24 Apr 2015 19:54:12 +0000 Message-ID: References: <2589.1429881020@sandelman.ca> <4017.1429899763@sandelman.ca> In-Reply-To: <4017.1429899763@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.160.51.88] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0244; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(51704005)(479174004)(5001770100001)(86362001)(66066001)(99286002)(122556002)(2950100001)(4000180100001)(15975445007)(102836002)(1720100001)(15974865002)(19580405001)(19580395003)(2656002)(76176999)(77156002)(62966003)(50986999)(54356999)(106116001)(46102003)(36756003)(87936001)(40100003)(92566002)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR09MB0244; H:BN1PR09MB0244.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:BN1PR09MB0244; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0244; x-forefront-prvs: 05568D1FF7 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2015 19:54:12.3197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0244 X-OriginatorOrg: mitre.org Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] new use case... only half :-) 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, 24 Apr 2015 19:54:17 -0000 VmVyeSBpbnRlcmVzdGluZy4gSSB0aGluayB0aGlzIGlzIHNvbWV3aGF0IG1vcmUgc3RyZWFtbGlu ZWQgdXNlIGNhc2Ugc2luY2UNCnRoZSBjb25zdHJhaW5lZCB0cnVuayBsb2NrL3NlbnNvciBpcyBj b21wbGV0ZWx5IGludGVncmF0ZWQgaW50byB0aGUgY2FyDQppdHNlbGYgLS0gdGhlIGNvbnN0cmFp bmVkIHRydW5rIGRldmljZSBmdWxseSB0cnVzdHMgdGhlIHVuY29uc3RyYWluZWQNCmRhc2hib2Fy ZCBzeXN0ZW0gYWxyZWFkeS4gSXQgY291bGQgYmUgYSBnb29kIGV4YW1wbGUgb2YgaG93IGEgY29u c3RyYWluZWQNCmRldmljZSByZWxpZXMgb24gYSB1bmNvbnN0cmFpbmVkIGF1dGhvcml6YXRpb24g c2VydmVyIHdpdGggYSBidWlsdC1pbg0KdHJ1c3QgcmVsYXRpb25zaGlwLiBCdXQgdGhlbiBJIHdv dWxkIGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBkZXZvbHZlcw0KaW50byBzdHJhaWdodGZvcndh cmQgdHJhZGl0aW9uYWwgT0F1dGggMi4wIGJldHdlZW4gdGhlIHVuY29uc3RyYWluZWQNCmRldmlj ZXMsIGFuZCBwZXJoYXBzIG5vdCBtdWNoIHdvdWxkIGJlIG5vdmVsIGZvciBBQ0UgZm9yIHRoaXMg c3BlY2lmaWMgdXNlDQpjYXNlPw0KDQotV2lsbGlhbQ0KDQpPbiA0LzI0LzE1LCAyOjIyIFBNLCAi TWljaGFlbCBSaWNoYXJkc29uIiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCg0KPg0K PkRlcmVrIEF0a2lucyA8ZGVyZWtAaWh0ZnAuY29tPiB3cm90ZToNCj4gICAgPj4gTm93LCBpcyB0 aGlzIGNvbnN0cmFpbmVkPyBQcm9iYWJseSBub3QgdmVyeS4NCj4NCj4gICAgPiBCeSBzb21lIGRl ZmluaXRpb25zIHllcywgYnkgb3RoZXIgZGVmaW5pdGlvbnMgbm8uICBJdCdzIGEgcG93ZXJlZA0K PiAgICA+IGRldmljZSwgc28gdGhlIHBvd2VyIGJ1ZGdldCBpcyBnZW5lcmFsbHkgdW5saW1pdGVk LiAgU2ltaWxhcmx5LCB0aGUNCj4gICAgPiBoZWF0IGJ1ZGdldCBpcyBwcmFjdGljYWxseSB1bmxp bWl0ZWQuDQo+DQo+ICAgID4gSG93ZXZlciB0aGVyZSBhcmUgc2l6ZSwgd2VpZ2h0LCBhbmQgY29z dCBjb25zdHJhaW50cywgd2hpY2ggbWVhbnMNCj50aGF0DQo+ICAgID4gdGhleSB3aWxsIHN0aWxs IHByb2JhYmx5IHVzZSAibG93IGVuZCIgZGV2aWNlcy4gIEkgZG91YnQgdGhleSdsbA0KPmhhdmUN Cj4gICAgPiBhbiBpNyBvciBldmVuIGEgWGVvbiBpbiB0aGVyZS4gIE1vcmUgbGlrZWx5IHRoZXkn bGwgdXNlIGEgbG93LWVuZA0KPkFSTQ0KPiAgICA+IChDb3J0ZXgtTSkgb3IgcG9zc2libHkgZXZl biBhbiBNU1A0MzAgb3IgODA1MSENCj4NCj5UaGUgaGFuZGhlbGQgdGhhdCB0aGUgREhMIHBlcnNv biBoYXMgaXMgbGlrZWx5IGF0IGxlYXN0IGFzIHBvd2VyZnVsIGFzIHR3bw0KPmdlbmVyYXRpb24g c21hcnRwaG9uZSAoaS5lLiBIVEMgRzIvaVBob25lIDQpLiBUaGF0J3MgYW4gYXdlZnVsIGxvdC4g V2l0aA0KPjNHDQo+Y29ubmVjdGl2aXR5IGF0IG11bHRpcGxlIG1lZ2FiaXRzLg0KPg0KPlRoZSB2 ZWhpY2xlcyBoYXZlIGF0IGxlYXN0IGVxdWl2YWxlbnQgZGV2aWNlcyBpbiB0aGUgZGFzaGJvYXJk LCB3aGljaCBpcw0KPndoZXJlIHRoZSB0cnVuayBjb250cm9sIHdvdWxkIGJlLCBhbmQgYWxzbyBo YXZlIDNHL0xURSBjb25uZWN0aXZpdHkuDQo+DQo+SSBzZWUgbm8gdGVjaG5pY2FsIHJlYXNvbiB3 aHkgb25lIGNhbid0IGdvIHRoZSBlbnRpcmUgT0FVVEgyIHJvdXRlIGZvcg0KPnRoaXMNCj5raW5k IG9mIHRoaW5nLiAgQnV0LCBhcyB5b3Ugc2F5LCBJIGNvdWxkIGJlIHdyb25nLg0KPg0KPlRoZSB0 cnVuayBsb2NrIG1lY2hhbmlzbSBtaWdodCBiZSBhbiA4MDUxLCB0cnVlLCBidXQgSSB0aGluayBp dCB3aWxsIHRhbGsNCj50bw0KPmFub3RoZXIgY29tcG9uZW50IGluIHRoZSB2ZWhpY2xlLCBub3Qg ZGlyZWN0bHkgdG8gdGhlIERITCBoYW5kaGVsZC4NCj4NCj4gICAgPj4gDQo+aHR0cDovL3d3dy5u eXRpbWVzLmNvbS8yMDE1LzA0LzIzL2J1c2luZXNzL2ludGVybmF0aW9uYWwvYXVkaS10by10ZXN0 LXBsYW4NCj4tdG8tZGVsaXZlci1hbWF6b24tcGFja2FnZXMtdG8tZHJpdmVycy10cnVua3MuaHRt bD9GUkFOS0ZVUlQNCj4gICAgPj4NCj4gICAgPj4+IEFsbW9zdCBzaW5jZSB0aGUgaW52ZW50aW9u IG9mIHRoZSBhdXRvbW9iaWxlLCBwZW9wbGUgaGF2ZSBiZWVuDQo+dXNpbmcNCj4gICAgPj4+IGNh cnMgZm9yIG1vcmUgdGhhbiBqdXN0IGdldHRpbmcgZnJvbSBwbGFjZSB0byBwbGFjZS4gVGhlIGNh ciBpcw0KPmFsc28NCj4gICAgPj4+IGEgcGxhY2UgdG8gZWF0LCB0byBzbGVlcCBhbmQgc29vbiwg aXQgYXBwZWFycywgdG8gcmVjZWl2ZQ0KPnBhY2thZ2VzLg0KPiAgICA+Pg0KPiAgICA+Pj4gQXVk aSwgdGhlIEdlcm1hbiBjYXJtYWtlciwgc2FpZCBXZWRuZXNkYXkgdGhhdCBpdCB3b3VsZCBiZWdp bg0KPnRlc3RpbmcNCj4gICAgPj4+IGEgc3lzdGVtIGluIE11bmljaCBuZXh0IG1vbnRoIHRoYXQg d291bGQgYWxsb3cgcGVvcGxlIHRvIG9yZGVyDQo+Z29vZHMNCj4gICAgPj4+IGZyb20gQW1hem9u IGFuZCBoYXZlIHRoZW0gZGVsaXZlcmVkIGJ5IERITCwgdGhlIEdlcm1hbiBwYWNrYWdlDQo+ICAg ID4+PiBkZWxpdmVyeSBzZXJ2aWNlLCB0byB0aGUgdHJ1bmsgb2YgdGhlaXIgcGFya2VkIGNhci4N Cj4gICAgPj4NCj4gICAgPj4+IFRoZSBpZGVhIGlzIG5vdCBjb21wbGV0ZWx5IG5ldy4gVm9sdm8g Q2FycyBzYWlkIG1vcmUgdGhhbiBhIHllYXINCj5hZ28NCj4gICAgPj4+IHRoYXQgaXQgd2FzIHRl c3RpbmcgYSBzaW1pbGFyIHN5c3RlbS4gQSBWb2x2byBzcG9rZXNtYW4gc2FpZA0KPiAgICA+Pj4g V2VkbmVzZGF5IHRoYXQgdGhlIGNvbXBhbnkgaGFzIGZpbmlzaGVkIGl0cyB0ZXN0aW5nIGFuZCBl eHBlY3RlZA0KPnRvDQo+ICAgID4+PiBhbm5vdW5jZSBzb29uIHRoYXQgaXQgd291bGQgYmUgb2Zm ZXJpbmcgdGhlIHNlcnZpY2UgdG8gY29uc3VtZXJzDQo+aW4NCj4gICAgPj4+IFN3ZWRlbiwgd2hl cmUgVm9sdm8gaGFzIGl0cyBoaWdoZXN0IG1hcmtldCBzaGFyZS4gTmV3ZXIgVm9sdm8gY2Fycw0K PiAgICA+Pj4gYXJlIGFscmVhZHkgZXF1aXBwZWQgd2l0aCB0ZWNobm9sb2d5IHRoYXQgd291bGQg ZW5hYmxlIHBhY2thZ2UNCj4gICAgPj4+IGRlbGl2ZXJ5IHRvIHZlaGljbGVzLCB0aGUgc3Bva2Vz bWFuIHNhaWQuDQo+ICAgID4+DQo+ICAgID4+DQo+ICAgID4+IC0tDQo+ICAgID4+IE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlDQo+ V29ya3MNCj4gICAgPj4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPiAgICA+Pg0KPiAgICA+ Pg0KPiAgICA+Pg0KPiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBBY2UgbWFpbGluZyBsaXN0DQo+ICAgID4+IEFjZUBpZXRmLm9yZyBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPg0KPiAgICA+IC0tDQo+ICAgID4g ICAgICAgIERlcmVrIEF0a2lucyA2MTctNjIzLTM3NDUgZGVyZWtAaWh0ZnAuY29tIHd3dy5paHRm cC5jb20NCj5Db21wdXRlcg0KPiAgICA+IGFuZCBJbnRlcm5ldCBTZWN1cml0eSBDb25zdWx0YW50 DQo+DQo+ICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gQWNlIG1haWxpbmcgbGlzdA0KPiAgICA+IEFjZUBpZXRmLm9yZyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPg0KPi0tDQo+TWljaGFlbCBSaWNoYXJkc29uIDxt Y3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2 NiBJb1QgY29uc3VsdGluZyA9LQ0KPg0KPg0KPg0KDQo= From nobody Sat Apr 25 05:11:02 2015 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 21FA01A040C for ; Sat, 25 Apr 2015 05:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 MrSpeRgPyDjL for ; Sat, 25 Apr 2015 05:10:55 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCEB1A03C7 for ; Sat, 25 Apr 2015 05:10:53 -0700 (PDT) Received: by labbd9 with SMTP id bd9so51963090lab.2 for ; Sat, 25 Apr 2015 05:10:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+GGXB41L2arJDJTQs2V53iC2jio63nl6NBNiYDCr4Ug=; b=XLfVh+/oDQ+ev5KygMWvfinUljx2eisEGGjtiy7vk51U3pMWF2p8+OqZLblp2rnfyK 9qfr5JoD4oFEJKm2viz+u3cK6qrbDdGm1ges3VeURm9a+/gOUsxF2gPa7QvyGw6OkbO4 O5tXX94c442nuhN86GpW35NhGpnv7Lyo5RRyJSYfKHqfSapjoeM+hHO4Mvzr/qOFbsAe xeNxLXSV4nS5gyFgd7DWBQRtFW910hfJDU+9ArNTTu4dUlXlkDiTA1saS4Vh9fxZ0LV+ wXzvybbWu5GzbpYySxqfoQZubKaB0FHaGdxvsRQb2UN3UbFZmepreu9nQI7oHVYZ4c6+ sCQw== X-Gm-Message-State: ALoCoQlMJw6PM7VmC1696FJlt9oxWo7JCS62wn7dENmqngyGIcBXuEfIs0N7aXsYMtFWkxE9Ar16 MIME-Version: 1.0 X-Received: by 10.152.36.40 with SMTP id n8mr2577273laj.121.1429963852343; Sat, 25 Apr 2015 05:10:52 -0700 (PDT) Received: by 10.152.111.103 with HTTP; Sat, 25 Apr 2015 05:10:52 -0700 (PDT) In-Reply-To: References: <2589.1429881020@sandelman.ca> <4017.1429899763@sandelman.ca> Date: Sat, 25 Apr 2015 14:10:52 +0200 Message-ID: From: Samuel Erdtman To: "Kim, William G" Content-Type: multipart/alternative; boundary=089e0160a9d47601ed05148b676c Archived-At: Cc: Michael Richardson , Derek Atkins , "ace@ietf.org" Subject: Re: [Ace] new use case... only half :-) 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, 25 Apr 2015 12:11:01 -0000 --089e0160a9d47601ed05148b676c Content-Type: text/plain; charset=UTF-8 Hi , It might not be a super constraint use case but it is very similar to "Remotely letting in a visitor" ( http://tools.ietf.org/html/draft-ietf-ace-usecases-03#section-2.2.3). It might even be slightly more constraint since the car might be offline (no cellular network connection) when a request comes to open the trunk for a package. Best Regards //Samuel On Fri, Apr 24, 2015 at 9:54 PM, Kim, William G wrote: > Very interesting. I think this is somewhat more streamlined use case since > the constrained trunk lock/sensor is completely integrated into the car > itself -- the constrained trunk device fully trusts the unconstrained > dashboard system already. It could be a good example of how a constrained > device relies on a unconstrained authorization server with a built-in > trust relationship. But then I would agree with you that this devolves > into straightforward traditional OAuth 2.0 between the unconstrained > devices, and perhaps not much would be novel for ACE for this specific use > case? > > -William > > On 4/24/15, 2:22 PM, "Michael Richardson" wrote: > > > > >Derek Atkins wrote: > > >> Now, is this constrained? Probably not very. > > > > > By some definitions yes, by other definitions no. It's a powered > > > device, so the power budget is generally unlimited. Similarly, the > > > heat budget is practically unlimited. > > > > > However there are size, weight, and cost constraints, which means > >that > > > they will still probably use "low end" devices. I doubt they'll > >have > > > an i7 or even a Xeon in there. More likely they'll use a low-end > >ARM > > > (Cortex-M) or possibly even an MSP430 or 8051! > > > >The handheld that the DHL person has is likely at least as powerful as two > >generation smartphone (i.e. HTC G2/iPhone 4). That's an aweful lot. With > >3G > >connectivity at multiple megabits. > > > >The vehicles have at least equivalent devices in the dashboard, which is > >where the trunk control would be, and also have 3G/LTE connectivity. > > > >I see no technical reason why one can't go the entire OAUTH2 route for > >this > >kind of thing. But, as you say, I could be wrong. > > > >The trunk lock mechanism might be an 8051, true, but I think it will talk > >to > >another component in the vehicle, not directly to the DHL handheld. > > > > >> > > > http://www.nytimes.com/2015/04/23/business/international/audi-to-test-plan > >-to-deliver-amazon-packages-to-drivers-trunks.html?FRANKFURT > > >> > > >>> Almost since the invention of the automobile, people have been > >using > > >>> cars for more than just getting from place to place. The car is > >also > > >>> a place to eat, to sleep and soon, it appears, to receive > >packages. > > >> > > >>> Audi, the German carmaker, said Wednesday that it would begin > >testing > > >>> a system in Munich next month that would allow people to order > >goods > > >>> from Amazon and have them delivered by DHL, the German package > > >>> delivery service, to the trunk of their parked car. > > >> > > >>> The idea is not completely new. Volvo Cars said more than a year > >ago > > >>> that it was testing a similar system. A Volvo spokesman said > > >>> Wednesday that the company has finished its testing and expected > >to > > >>> announce soon that it would be offering the service to consumers > >in > > >>> Sweden, where Volvo has its highest market share. Newer Volvo cars > > >>> are already equipped with technology that would enable package > > >>> delivery to vehicles, the spokesman said. > > >> > > >> > > >> -- > > >> Michael Richardson , Sandelman Software > >Works > > >> -= IPv6 IoT consulting =- > > >> > > >> > > >> > > >> _______________________________________________ Ace mailing list > > >> Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace > > > > > -- > > > Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com > >Computer > > > and Internet Security Consultant > > > > > _______________________________________________ Ace mailing list > > > Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace > > > >-- > >Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --089e0160a9d47601ed05148b676c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi ,

It might not be a super constraint= use case but it is very similar to "Remotely letting in a visitor&quo= t; (http://tools.ietf.org/html/draft-ietf-ace-usecases-03#section-2.2.= 3). It might even be slightly more constraint since the car might be of= fline (no cellular network connection) when a request comes to open the tru= nk for a package.

Best Regards
//Samuel<= /div>


On Fri, Apr 24, 2015 at 9:54 PM, Kim, William G = <wkim@mitre.org&= gt; wrote:
Very interesting. I thi= nk this is somewhat more streamlined use case since
the constrained trunk lock/sensor is completely integrated into the car
itself -- the constrained trunk device fully trusts the unconstrained
dashboard system already. It could be a good example of how a constrained device relies on a unconstrained authorization server with a built-in
trust relationship. But then I would agree with you that this devolves
into straightforward traditional OAuth 2.0 between the unconstrained
devices, and perhaps not much would be novel for ACE for this specific use<= br> case?

-William

On 4/24/15, 2:22 PM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:

>
>Derek Atkins <derek@ihtfp.com= > wrote:
>=C2=A0 =C2=A0 >> Now, is this constrained? Probably not very.
>
>=C2=A0 =C2=A0 > By some definitions yes, by other definitions no.=C2= =A0 It's a powered
>=C2=A0 =C2=A0 > device, so the power budget is generally unlimited.= =C2=A0 Similarly, the
>=C2=A0 =C2=A0 > heat budget is practically unlimited.
>
>=C2=A0 =C2=A0 > However there are size, weight, and cost constraints= , which means
>that
>=C2=A0 =C2=A0 > they will still probably use "low end" dev= ices.=C2=A0 I doubt they'll
>have
>=C2=A0 =C2=A0 > an i7 or even a Xeon in there.=C2=A0 More likely the= y'll use a low-end
>ARM
>=C2=A0 =C2=A0 > (Cortex-M) or possibly even an MSP430 or 8051!
>
>The handheld that the DHL person has is likely at least as powerful as = two
>generation smartphone (i.e. HTC G2/iPhone 4). That's an aweful lot.= With
>3G
>connectivity at multiple megabits.
>
>The vehicles have at least equivalent devices in the dashboard, which i= s
>where the trunk control would be, and also have 3G/LTE connectivity. >
>I see no technical reason why one can't go the entire OAUTH2 route = for
>this
>kind of thing.=C2=A0 But, as you say, I could be wrong.
>
>The trunk lock mechanism might be an 8051, true, but I think it will ta= lk
>to
>another component in the vehicle, not directly to the DHL handheld.
>
>=C2=A0 =C2=A0 >>
>http://www.nytimes.com/2015/04/23/busines= s/international/audi-to-test-plan
>-to-deliver-amazon-packages-to-drivers-trunks.html?FRANKFURT
>=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >>> Almost since the invention of the automobile= , people have been
>using
>=C2=A0 =C2=A0 >>> cars for more than just getting from place t= o place. The car is
>also
>=C2=A0 =C2=A0 >>> a place to eat, to sleep and soon, it appear= s, to receive
>packages.
>=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >>> Audi, the German carmaker, said Wednesday th= at it would begin
>testing
>=C2=A0 =C2=A0 >>> a system in Munich next month that would all= ow people to order
>goods
>=C2=A0 =C2=A0 >>> from Amazon and have them delivered by DHL, = the German package
>=C2=A0 =C2=A0 >>> delivery service, to the trunk of their park= ed car.
>=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >>> The idea is not completely new. Volvo Cars s= aid more than a year
>ago
>=C2=A0 =C2=A0 >>> that it was testing a similar system. A Volv= o spokesman said
>=C2=A0 =C2=A0 >>> Wednesday that the company has finished its = testing and expected
>to
>=C2=A0 =C2=A0 >>> announce soon that it would be offering the = service to consumers
>in
>=C2=A0 =C2=A0 >>> Sweden, where Volvo has its highest market s= hare. Newer Volvo cars
>=C2=A0 =C2=A0 >>> are already equipped with technology that wo= uld enable package
>=C2=A0 =C2=A0 >>> delivery to vehicles, the spokesman said. >=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >> --
>=C2=A0 =C2=A0 >> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
>Works
>=C2=A0 =C2=A0 >> -=3D IPv6 IoT consulting =3D-
>=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 >> _______________________________________________ = Ace mailing list
>=C2=A0 =C2=A0 >> Ace@ietf.org= ht= tps://www.ietf.org/mailman/listinfo/ace
>
>=C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com
>Computer
>=C2=A0 =C2=A0 > and Internet Security Consultant
>
>=C2=A0 =C2=A0 > _______________________________________________ Ace = mailing list
>=C2=A0 =C2=A0 > Ace@ietf.org https:= //www.ietf.org/mailman/listinfo/ace
>
>--
>Michael Richardson <mcr+I= ETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>
>
>

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

--089e0160a9d47601ed05148b676c-- From nobody Sat Apr 25 16:03:53 2015 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 A86281AD0CB for ; Sat, 25 Apr 2015 16:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 cm_blpCzFV4d for ; Sat, 25 Apr 2015 16:03:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A711AD0C7 for ; Sat, 25 Apr 2015 16:03:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 02259203B1 for ; Sat, 25 Apr 2015 19:15:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D25AE63B86; Sat, 25 Apr 2015 19:03:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BB1D0636A2 for ; Sat, 25 Apr 2015 19:03:47 -0400 (EDT) From: Michael Richardson To: "ace@ietf.org" In-Reply-To: References: <2589.1429881020@sandelman.ca> <4017.1429899763@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Subject: Re: [Ace] new use case... only half :-) 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, 25 Apr 2015 23:03:51 -0000 Kim, William G wrote: > Very interesting. I think this is somewhat more streamlined use case > since the constrained trunk lock/sensor is completely integrated into > the car itself -- the constrained trunk device fully trusts the > unconstrained dashboard system already. It could be a good example of > how a constrained device relies on a unconstrained authorization server > with a built-in trust relationship. But then I would agree with you > that this devolves into straightforward traditional OAuth 2.0 between > the unconstrained devices, and perhaps not much would be novel for ACE > for this specific use case? This is a good point: in the context where the trunk opening device communicates *directly* with the DHL handheld, and the unconstrained dashboard system is powered off, then ACE would apply. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Apr 29 02:48:07 2015 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 82C8B1A9077 for ; Wed, 29 Apr 2015 02:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 X9XmUykJMW32 for ; Wed, 29 Apr 2015 02:48:03 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DEB1A9102 for ; Wed, 29 Apr 2015 02:47:59 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so42754579ied.1 for ; Wed, 29 Apr 2015 02:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=IHKpxyOI0ZRr0vF7OW2i4ZNJpWsM8vfgjTgSNBno2ew=; b=y0KF2BG1WYHk+lN8yI6rRwGsOb37x8m7d5/r2X5gl9exqc0Nh9JtDgndw4rjly+it1 JYmxUVUpK1xrHMJIMcIXexIYMhTUhQXMafxyDTz4pzfv1zy/9GpZJPknLLnnX+RaGV95 5r4or1lMcRlThiQAf5Q1mjgKPZHK3gNNEXjm3ltWSKcC08QogzagPCrWuqBvpl0HXqoQ 55MJIo8p5Q+Q4YK12hor4iJ/tTHGX6NCF0ZSI12lwGiQ4X/QLZjWCxPJwA0DJA+GyUtw kueDHyl2ERTNUCvOFvgEyNDpTUWoD58IVjdLWaopPjYeoQj7EODBJpwY86FQwfvoxIEK A4Pg== X-Received: by 10.42.105.3 with SMTP id t3mr1139652ico.47.1430300879115; Wed, 29 Apr 2015 02:47:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.167.79 with HTTP; Wed, 29 Apr 2015 02:47:38 -0700 (PDT) From: Renzo Navas Date: Wed, 29 Apr 2015 11:47:38 +0200 Message-ID: To: Ace@ietf.org Content-Type: multipart/alternative; boundary=20cf303dd346d258c80514d9df04 Archived-At: Subject: [Ace] gerdes-ace-dcaf-authorize (DTLS PSK Generation Methods) 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, 29 Apr 2015 09:48:05 -0000 --20cf303dd346d258c80514d9df04 Content-Type: text/plain; charset=UTF-8 Hello Steffi and DCAF authors, I was reading the DCAF draft and I think I find nomenclature mismatch (on section 6.1): 6.1 . DTLS PSK Transfer The DTLS PSK is generated by AS and transmitted to C and S using a secure channel. "generated by AS" might be "generated by SAM" (or generated by The AM). I think "AS" was the nomenclature used on version 00 of the draft. Also I want to say that its great that the document draft-gerdes-ace-actors-04 the WG is arriving to a nomenclature merge with the draft-seitz-ace-problem-description-03, as discussed on Dallas IETF. So in the end if the next version of DCAF aligns with Actors, the SAM will be AS again :) I want to mention that I have a UseCase when I need to bootstrap C into an unknown network (but possibly federated with the trusted home-network of C) so I cannot assume a pre-established secured channel between C and CAM :(. I am working on an mutually-authenticated secured bootstraping solution. Possibly only using symmetrc criptography. Thanks again Steffi for you work, Have a good week Ace WG, and labour day! Renzo NAVAS, Telecom Bretagne (France) --20cf303dd346d258c80514d9df04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Steffi and DCAF authors,

I was re= ading the DCAF draft and I think I find nomenclature mismatch (on section 6= .1):

 =
 6.1.  DTLS PSK Transfer


     The DTLS PSK is generated by AS and transmitted to C and S using a
     secure channel.


"generated by AS&=
quot; might be "generated by=C2=A0SAM" (or generated by The AM). I thi=
nk "AS" was the nomenclature used on version 00 of the draft.

<=
pre class=3D"" style=3D"margin-top:0px;margin-bottom:0px">Also I want to say that its =
great that the document=C2=A0draft-gerdes-ace-actors-04 the WG is arriving =
to a nomenclature merge with the=C2=A0draft-seitz-ace-problem-description-0=
3, as discussed on Dallas IETF.

So in the end if the next version of=
 DCAF aligns with Actors, the SAM will be AS again :)


I want to mention that=
 I have a UseCase when I need to bootstrap C into an unknown network (but p=
ossibly federated with the trusted home-network of C) so I cannot assume a =
pre-established secured channel between C and CAM :(.
I am working on an=
 mutually-authenticated secured bootstraping solution. Possibly only using =
symmetrc criptography.

Thanks again Steffi for you work, 
Have a good week Ace WG, and labour day!

Renzo NAVAS,
Telecom Bretagne (France=
)

--20cf303dd346d258c80514d9df04-- From nobody Wed Apr 29 04:42:51 2015 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 86AED1A884F for ; Wed, 29 Apr 2015 04:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 Dvwzqmyi9Jo0 for ; Wed, 29 Apr 2015 04:42:47 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 76E181A87E1 for ; Wed, 29 Apr 2015 04:42:47 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 95C0C62F for ; Wed, 29 Apr 2015 13:42:46 +0200 (CEST) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t3TBgk8L002180 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 29 Apr 2015 13:42:46 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 3854C2F for ; Wed, 29 Apr 2015 13:42:46 +0200 (CEST) Message-ID: <5540C3B5.6000109@sics.se> Date: Wed, 29 Apr 2015 13:42:45 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ace@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040405010208060908010900" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09OlLGKV6 - df46268d2063 - 20150429 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09OlLGKV6&m=df46268d2063&t=20150429&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09OlLGKV6&m=df46268d2063&t=20150429&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09OlLGKV6&m=df46268d2063&t=20150429&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] gerdes-ace-dcaf-authorize (DTLS PSK Generation Methods) 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, 29 Apr 2015 11:42:50 -0000 This is a cryptographically signed message in MIME format. --------------ms040405010208060908010900 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 04/29/2015 11:47 AM, Renzo Navas wrote: > > I want to mention that I have a UseCase when I need to bootstrap C into= an unknown network (but possibly federated with the trusted home-network= of C) so I cannot assume a pre-established secured channel between C and= CAM :(. > I am working on an mutually-authenticated secured bootstraping solution= =2E Possibly only using symmetrc criptography. > > This sounds intriguing, if you do not have a security relation between C = and CAM, who did the enrollment of C? I would assume that as RqP enrolls C it should be able to provision a=20 security relation between C and CAM. Or is it the case that RqP does not = know which CAM to use? Perhaps you could describe you use case in more detail so that your=20 bootstrapping problem become more clear. Regards, 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 --------------ms040405010208060908010900 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 BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 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 bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA0MjkxMTQyNDVaMCMGCSqGSIb3DQEJBDEW BBT3PP/ElSmOM96jQUWOyz9YtBY66jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAcScsV8YQz5o1EoGb+W335N67Gr9L1zr53rA4RhyURIFEpCIHtBlSqAoKzdFUcFD1xBhi wgpiqB5ExgXzvAIwycmd/nhrS7ZGo64PreR8k/L5IJXTfDFbmas/CZWZ1rR2I4WZ2Lous4Ir b9gHhs68Ib7d5yDkzV4TaP8H4NH6aXEQilh1tehMrwBlxFJCIckKyg74TVfG/081cDzFkZuM 0nU+znGpk3Or+NLLgGYKjT4clkbW+spzPoMw6mGq/iRoz5JDtYaHzLp+lf62jr8YLevGrOub vhZemzdlY+7ASvDxL8j7Czt+pLDxQFuj00ee/7LeedWEMz/52vn+rHWRIgAAAAAAAA== --------------ms040405010208060908010900-- From nobody Wed Apr 29 05:22:59 2015 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 7E73D1B2C4C for ; Wed, 29 Apr 2015 05:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_BEST=2.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 wE1Tba4Yttpg for ; Wed, 29 Apr 2015 05:22:56 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D951A8A54 for ; Wed, 29 Apr 2015 05:22:55 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so116525305igb.0 for ; Wed, 29 Apr 2015 05:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vRTNpeXsJgg+zrxjsRRi5vIkcABsUPbmtaBAD7FfwMI=; b=GfRoQ0vI8PoocvsBDoU6lz5Bj7dZm8brFancn+eQohT/ZBLjU78tP0tK33+m1pL1Xe ANos9X0Vee/VYVC08JQZfM2X7GGHkshJ5wJP3v7vFNUrismDWgMHVp152leJu2Cht2Jk dIphtx2kiPd+BVneJ2aA4r3b3OQ6W3pxijiA6SoEPoRWJU+E0iaYWJZ49EJZHQP45h2w b1fJXG3ByzrzUGWd39XDvqS7VxPLVi+6kWzmaa3DQekNKHfzwlu1s8WINEdvfI7n+32D 2pt9I49o1j5qvjGXwmHGw+cwe0njX4pRo37L5+grh/VpxkRqt1Hw3jUiwjgEK9e91e9Y Nfsw== X-Received: by 10.107.132.42 with SMTP id g42mr27856489iod.25.1430310175286; Wed, 29 Apr 2015 05:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.167.79 with HTTP; Wed, 29 Apr 2015 05:22:34 -0700 (PDT) In-Reply-To: <5540C3B5.6000109@sics.se> References: <5540C3B5.6000109@sics.se> From: Renzo Navas Date: Wed, 29 Apr 2015 14:22:34 +0200 Message-ID: To: Ludwig Seitz Content-Type: multipart/alternative; boundary=001a113f3d1ceaac320514dc0920 Archived-At: Cc: ace Subject: Re: [Ace] gerdes-ace-dcaf-authorize (DTLS PSK Generation Methods) 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, 29 Apr 2015 12:22:57 -0000 --001a113f3d1ceaac320514dc0920 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ludwig I will try later to describe in more detail my scenario, for the moment I confirme that * C and CAM DO HAVE a previous security relation (for instance a PSK or on a Public-key setting the public key of the other) In DCAF model C an CAM have an already a secured DTLS session. In my UC, C bootstraps from zero. And I have intermediate nodes between C and his CAM. If I try to map my UC to DCAF nomenclature, this intermediate node can be (S+SAM) So you cannot trust S+SAM yet, and S+SAM also needs to assure if he can trust C. * C is constrained * S+SAM are not constrained It think the architecture will be like this: [ C ] ------unsecured channel------ [man in the middle] ----------------[ S+SAM ] -------secured channel ------------ [CAM] So C has NOT a previous security relation with S+SAM (shared cryptographic material), but: * SAM and CAM trust each other. * C trust CAM (but there is not a secure channel) So my goal : * C and (S+SAM) securely mutually-authenticate each other (using in some way CAM) * Now I can try also to secure the channel between C and (S+SAM) The draft that best maps this scenario is (EAP-over-CoAP): https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-01 Thank you for your interest if I have not been clear I 'll work on it. Regards, Renzo On Wed, Apr 29, 2015 at 1:42 PM, Ludwig Seitz wrote: > On 04/29/2015 11:47 AM, Renzo Navas wrote: > >> >> I want to mention that I have a UseCase when I need to bootstrap C into >> an unknown network (but possibly federated with the trusted home-network= of >> C) so I cannot assume a pre-established secured channel between C and CA= M >> :(. >> I am working on an mutually-authenticated secured bootstraping solution. >> Possibly only using symmetrc criptography. >> >> >> > This sounds intriguing, if you do not have a security relation between C > and CAM, who did the enrollment of C? > > I would assume that as RqP enrolls C it should be able to provision a > security relation between C and CAM. Or is it the case that RqP does not > know which CAM to use? > > Perhaps you could describe you use case in more detail so that your > bootstrapping problem become more clear. > > Regards, > > Ludwig > > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=C3=A4gen 17 > SE-223 70 Lund > > Phone +46(0)70-349 92 51 > http://www.sics.se > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a113f3d1ceaac320514dc0920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ludwig I will try later to describe in more detail my s= cenario, for the moment I confirme that

* C and CAM DO HAVE a previo= us security relation (for instance a PSK or on a Public-key setting the pub= lic key of the other)

In DCAF model C an CAM have an already a = secured DTLS session.

In my UC, C bootstraps from zero. And I have i= ntermediate nodes between C and his CAM.

If I try to map my UC to DC= AF nomenclature, this intermediate node can be =C2=A0(S+SAM)
So you cann= ot trust S+SAM yet, and S+SAM also needs to assure if he can trust C.
* C is constrained
* S+SAM are not constrained

It think the arc= hitecture will be like this:

[ C ] ------unsecured channel------ [ma= n in the middle] ----------------[ S+SAM ] =C2=A0-------secured channel ---= --------- [CAM]

So C has NOT a previous security r= elation with S+SAM (shared cryptographic material), but:

* = =C2=A0SAM and CAM trust each other.
=C2=A0* C trust CAM (but there is no= t a secure channel)

So my goal :
* C and (S+SAM) securely mutuall= y-authenticate each other (using in some way CAM)
* Now I can try also t= o secure the channel between C and (S+SAM)


The draft that best m= aps this scenario is (EAP-over-CoAP):

https://tools.ie= tf.org/html/draft-marin-ace-wg-coap-eap-01

Thank you for your in= terest if I have not been clear I 'll work on it.

Regards,
Renzo






=




On Wed, Apr 29, 2015 at 1:42 PM, Ludwig Seitz = <ludwig@sics.se&= gt; wrote:
On 04/= 29/2015 11:47 AM, Renzo Navas wrote:

I want to mention that I have a UseCase when I need to bootstrap C into an = unknown network (but possibly federated with the trusted home-network of C)= so I cannot assume a pre-established secured channel between C and CAM :(.=
I am working on an mutually-authenticated secured bootstraping solution. Po= ssibly only using symmetrc criptography.



 This sounds intriguing, if you do not have a security relation between C an= d CAM, who did the enrollment of C?

I would assume that as RqP enrolls C it should be able to provision a secur= ity relation between C and CAM. Or is it the case that RqP does not know wh= ich CAM to use?

Perhaps you could describe you use case in more detail so that your bootstr= apping problem become more clear.

Regards,

Ludwig

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelev=C3=A4gen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se


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


--001a113f3d1ceaac320514dc0920-- From nobody Wed Apr 29 05:44:53 2015 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 F13651B2C86 for ; Wed, 29 Apr 2015 05:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_BEST=2.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 mirZckN6oaAR for ; Wed, 29 Apr 2015 05:44:51 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EBD1B2C87 for ; Wed, 29 Apr 2015 05:44:51 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so40856462ieb.3 for ; Wed, 29 Apr 2015 05:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=T/s2Ie/i1p+/lufNtYBBNgnyK/Io+AZkkzkRGE5Ox2c=; b=VglEMdE3bLAY3WaTsl5sqxIdbihbvFQBf9VCUqaeJAz1qV2Jo7Zr1JdWaDjfBQE/QZ 1aQoprYmXTnTyJy3T0GCHqG6sQima1l9tXFPGAt9Dh0qYy63eNImZi0+KZPEKaWmm8QU HPgx6GMKvH8MrAclyC9Gbc7KmEl+avvhD7nVtAEPC9zJ9VMOOTnMgJgh2eBS9xyJkfTr a/bqq8sZvu6z3/PiMM3PyxgeYwtPMqrx+Y/A0RaPT15ddrXFXzsd55JHFcaCaeRIzVzk fhoc6XWPTEVdmxtZq0lF0gprx7gXacI7McFis4W9zdWrIzULc7N6y+UUuO7yQVih37uJ WjBQ== X-Received: by 10.43.24.76 with SMTP id rd12mr3172863icb.84.1430311490615; Wed, 29 Apr 2015 05:44:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.167.79 with HTTP; Wed, 29 Apr 2015 05:44:30 -0700 (PDT) In-Reply-To: References: <5540C3B5.6000109@sics.se> From: Renzo Navas Date: Wed, 29 Apr 2015 14:44:30 +0200 Message-ID: To: Ludwig Seitz Content-Type: multipart/alternative; boundary=bcaec51dd02d50ffb50514dc58ad Archived-At: Cc: ace Subject: Re: [Ace] gerdes-ace-dcaf-authorize (DTLS PSK Generation Methods) 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, 29 Apr 2015 12:44:53 -0000 --bcaec51dd02d50ffb50514dc58ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry I think my schema is confusing. to clarify: * The "man-in-the-middle" is an active attacker. * C and (S+SAM) do not need a relay to communicate (they are one-hop, on that side of the schema I'm on a radio star-topology and S+SAM is the central node) On Wed, Apr 29, 2015 at 2:22 PM, Renzo Navas wrote: > Hi Ludwig I will try later to describe in more detail my scenario, for th= e > moment I confirme that > > * C and CAM DO HAVE a previous security relation (for instance a PSK or o= n > a Public-key setting the public key of the other) > > In DCAF model C an CAM have an already a secured DTLS session. > > In my UC, C bootstraps from zero. And I have intermediate nodes between C > and his CAM. > > If I try to map my UC to DCAF nomenclature, this intermediate node can be > (S+SAM) > So you cannot trust S+SAM yet, and S+SAM also needs to assure if he can > trust C. > > * C is constrained > * S+SAM are not constrained > > It think the architecture will be like this: > > [ C ] ------unsecured channel------ [man in the middle] ----------------[ > S+SAM ] -------secured channel ------------ [CAM] > > So C has NOT a previous security relation with S+SAM (shared cryptographi= c > material), but: > > * SAM and CAM trust each other. > * C trust CAM (but there is not a secure channel) > > So my goal : > * C and (S+SAM) securely mutually-authenticate each other (using in some > way CAM) > * Now I can try also to secure the channel between C and (S+SAM) > > > The draft that best maps this scenario is (EAP-over-CoAP): > > https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-01 > > Thank you for your interest if I have not been clear I 'll work on it. > > Regards, > > Renzo > > > > > > > > > > > > On Wed, Apr 29, 2015 at 1:42 PM, Ludwig Seitz wrote: > >> On 04/29/2015 11:47 AM, Renzo Navas wrote: >> >>> >>> I want to mention that I have a UseCase when I need to bootstrap C into >>> an unknown network (but possibly federated with the trusted home-networ= k of >>> C) so I cannot assume a pre-established secured channel between C and C= AM >>> :(. >>> I am working on an mutually-authenticated secured bootstraping solution= . >>> Possibly only using symmetrc criptography. >>> >>> >>> >> This sounds intriguing, if you do not have a security relation between C >> and CAM, who did the enrollment of C? >> >> I would assume that as RqP enrolls C it should be able to provision a >> security relation between C and CAM. Or is it the case that RqP does not >> know which CAM to use? >> >> Perhaps you could describe you use case in more detail so that your >> bootstrapping problem become more clear. >> >> Regards, >> >> Ludwig >> >> -- >> Ludwig Seitz, PhD >> SICS Swedish ICT AB >> Ideon Science Park >> Building Beta 2 >> Scheelev=C3=A4gen 17 >> SE-223 70 Lund >> >> Phone +46(0)70-349 92 51 >> http://www.sics.se >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> > --bcaec51dd02d50ffb50514dc58ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry I think my schema is confusing. to clarify:
* The= "man-in-the-middle" is an active attacker.
* C and (S+SAM) do= not need a relay to communicate (they are one-hop, on that side of the sch= ema I'm on a radio star-topology and S+SAM is the central node)

On Wed, Apr 29, 201= 5 at 2:22 PM, Renzo Navas <renzoefra@gmail.com> wrote:
=
Hi Ludwig I will try later = to describe in more detail my scenario, for the moment I confirme that
<= br>* C and CAM DO HAVE a previous security relation (for instance a PSK or = on a Public-key setting the public key of the other)

In DCAF mo= del C an CAM have an already a secured DTLS session.

In my UC, C boo= tstraps from zero. And I have intermediate nodes between C and his CAM.
=
If I try to map my UC to DCAF nomenclature, this intermediate node can = be =C2=A0(S+SAM)
So you cannot trust S+SAM yet, and S+SAM also needs to = assure if he can trust C.

* C is constrained
* S+SAM are not cons= trained

It think the architecture will be like this:

[ C ] --= ----unsecured channel------ [man in the middle] ----------------[ S+SAM ] = =C2=A0-------secured channel ------------ [CAM]

So= C has NOT a previous security relation with S+SAM (shared cryptographic ma= terial), but:

* =C2=A0SAM and CAM trust each other.
=C2=A0= * C trust CAM (but there is not a secure channel)

So my goal :
* = C and (S+SAM) securely mutually-authenticate each other (using in some way = CAM)
* Now I can try also to secure the channel between C and (S+SAM)

The draft that best maps this scenario is (EAP-over-CoAP):

https://tools.ietf.org/html/draft-marin-ace= -wg-coap-eap-01

Thank you for your interest if I have not been c= lear I 'll work on it.

Regards,

Renzo











On Wed, Apr 29, 2015 at 1:42 PM, Ludwig Seitz <= ;ludwig@sics.se>= wrote:
On 04/29/2015 11:47 AM, Renzo Navas wrote:

I want to mention that I have a UseCase when I need to bootstrap C into an = unknown network (but possibly federated with the trusted home-network of C)= so I cannot assume a pre-established secured channel between C and CAM :(.=
I am working on an mutually-authenticated secured bootstraping solution. Po= ssibly only using symmetrc criptography.



 This sounds intriguing, if you do not have a security relation between C an= d CAM, who did the enrollment of C?

I would assume that as RqP enrolls C it should be able to provision a secur= ity relation between C and CAM. Or is it the case that RqP does not know wh= ich CAM to use?

Perhaps you could describe you use case in more detail so that your bootstr= apping problem become more clear.

Regards,

Ludwig

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelev=C3=A4gen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se


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



--bcaec51dd02d50ffb50514dc58ad-- From nobody Wed Apr 29 13:13:10 2015 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 9501C1A1A0B for ; Wed, 29 Apr 2015 13:13:08 -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_40=-0.001, HELO_EQ_DE=0.35] 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 J4xm1_67joxa for ; Wed, 29 Apr 2015 13:13:06 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A149A1A0378 for ; Wed, 29 Apr 2015 13:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t3TKD31G027552 for ; Wed, 29 Apr 2015 22:13:03 +0200 (CEST) Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lcWHL6wthzDbKJ; Wed, 29 Apr 2015 22:13:02 +0200 (CEST) Message-ID: <55413B4D.4050801@tzi.org> Date: Wed, 29 Apr 2015 22:13:01 +0200 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] Actors draft/Problem draft merged 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, 29 Apr 2015 20:13:08 -0000 The design team that worked on merging the actors and the problem description draft has completed*) its work. We submit draft-gerdes-actors-05 with the intent to have it adopted as a WG draft. -- WG chairs, please issue the call for adoption. -- WG, you can start sending in your support or comments while that is going on. *) We haven't tried to touch the axis from the asymptote, so all of us have some minor issues left. But we think it is more important now to get input from the wider WG so we can finish this off, and we can calibrate these small things within the WG consensus process. Gruesse, Carsten From nobody Wed Apr 29 17:53:27 2015 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 860E61A8F45 for ; Wed, 29 Apr 2015 17:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, 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 ePs7PjMq7Q9a for ; Wed, 29 Apr 2015 17:53:25 -0700 (PDT) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id E172C1A8A7F for ; Wed, 29 Apr 2015 17:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430355204; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=3PB4bkKTdGZ8s1mDuKdZf9boY5ftXLPrfl7B9I0Af/E=; b=kNbkUzTHB/qf7Uy/ErXPIp54KwawnezoPjaGoB7687aKVSUrKDRnAIF4eKFJNQW0Z5u1ajaxO3w8VEwTyLlvf8zcuqP42iPHaX1NAAVC52x67YrQ3ud4B7sls+9hvK26EGMjT+B00VmldwrngOhR4fj74cWUuq1g+8fiQ+vj2+8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R701e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03021; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.1.151.150(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.161) by smtp.aliyun-inc.com(127.0.0.1); Thu, 30 Apr 2015 08:53:21 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 30 Apr 2015 08:53:17 +0800 From: "Kepeng Li" To: Carsten Bormann , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Actors draft/Problem draft merged References: <55413B4D.4050801@tzi.org> In-Reply-To: <55413B4D.4050801@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] Actors draft/Problem draft merged 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, 30 Apr 2015 00:53:26 -0000 > We submit draft-gerdes-actors-05 with the intent to have it adopted as a >WG draft. Glad to see that. > WG chairs, please issue the call for adoption. Let me check with Hannes. > We haven't tried to touch the axis from the asymptote, so all of us have some minor issues left. Maybe you can send out the issues for discussion. Thanks, Kind Regards Kepeng =D4=DA 30/4/15 4:13 am=A3=AC "Carsten Bormann" =D0=B4=C8=EB: >The design team that worked on merging the actors and the problem >description draft has completed*) its work. We submit >draft-gerdes-actors-05 with the intent to have it adopted as a WG >draft. > >-- WG chairs, please issue the call for adoption. > >-- WG, you can start sending in your support or comments while that is >going on. > >*) We haven't tried to touch the axis from the asymptote, so all of us > have some minor issues left. But we think it is more important now > to get input from the wider WG so we can finish this off, and we can > calibrate these small things within the WG consensus process. > >Gruesse, Carsten > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Wed Apr 29 21:55:07 2015 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 E756D1AC3C8 for ; Wed, 29 Apr 2015 21:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 eEFADtYZGhrB for ; Wed, 29 Apr 2015 21:55:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691731A92FB for ; Wed, 29 Apr 2015 21:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t3U4svFC016367; Thu, 30 Apr 2015 06:54:57 +0200 (CEST) Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lcksY1TsqzDbdX; Thu, 30 Apr 2015 06:54:57 +0200 (CEST) Message-ID: <5541B59F.9000702@tzi.org> Date: Thu, 30 Apr 2015 06:54:55 +0200 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Kepeng Li References: <55413B4D.4050801@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Actors draft/Problem draft merged 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, 30 Apr 2015 04:55:06 -0000 Kepeng Li wrote: >> > We haven't tried to touch the axis from the asymptote, so all of us have some minor issues left. > > Maybe you can send out the issues for discussion. Sure -- after WG adoption... Grüße, Carsten From nobody Thu Apr 30 12:12:36 2015 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 F33BD1A8733 for ; Thu, 30 Apr 2015 12:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8MjeyvvwhqhY for ; Thu, 30 Apr 2015 12:12:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA121A00EC for ; Thu, 30 Apr 2015 12:12:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EB1A203AF for ; Thu, 30 Apr 2015 15:24:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 95EA263B86; Thu, 30 Apr 2015 15:12:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7BE13636B6 for ; Thu, 30 Apr 2015 15:12:31 -0400 (EDT) From: Michael Richardson To: ace X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Subject: [Ace] draft-gerdes-ace-actors-05 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, 30 Apr 2015 19:12:35 -0000 --=-=-= Content-Type: text/plain I have read draft-gerdes-ace-actors-05. I concur with adopting it. I suggest that the abstract might include words like: This document provides terminology, and elements of an architecture / a problem statement, for authentication and authorization in these networks. **The terminology defined is mapped to related OAUTH and UMA terms.** I think that having the word OAUTH in the abstract will be useful. I see that the title is in fact: "An **architecture** for authorization in constrained environments" the "actor" part, which is terminology is a necessary part of getting into the architecture. I am very happy with the result. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVUJ+n4CLcPvd0N1lAQL9ZAf+PyRNdcWlagG6Ec9oiOPD19x2RfcBqdMx JRxDVlGUgKiBi/Rq1vfKdGsKn9iBez9g256QeMnkmp7HLUwNT3d/7bmduCEYNEi2 d+110FQsldDMx4UmW+Ifm8sYVfQ1QFgcCrlAfE7Ed249cHwu4sMINNJSt4GcPbyb ds8dASS+LkBxclK17sMHs4DRSRe4SApsUCvkU1OGx53nRQMdK1/gwFJVuXIYmDjb rPBV6RDjZBioGn70n87Seong4U/0iPGfdwwnqsNBliwzrk72RiS5dGUrGvSGtn1z Tv/9hYrkwHMRNi3dJ9N0liYBnmPHUv5ze9JwRQarqJSKrTkXTyu5vQ== =Le5f -----END PGP SIGNATURE----- --=-=-=--