From nobody Thu Sep 4 01:12:52 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7804A1A0049 for ; Thu, 4 Sep 2014 01:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.856 X-Spam-Level: X-Spam-Status: No, score=0.856 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 GNvlJMNdhNV6 for ; Thu, 4 Sep 2014 01:12:35 -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 941F71A001E for ; Thu, 4 Sep 2014 01:12:35 -0700 (PDT) Received: from [217.140.96.21] by 3capp-gmx-bs62.server.lan (via HTTP); Thu, 4 Sep 2014 10:12:33 +0200 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ace@ietf.org Content-Type: text/html; charset=UTF-8 Date: Thu, 4 Sep 2014 10:12:33 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:9kO+BJQyrG0R6xZH5/8JmeWw0XLbssE1eG36IQJ3HAq PAYnGTwb3krMKzGMfPR4QP7/FXSeGRQLV3VISDXYoX/hCYJXJC dsyMvKEHyW+4KPahjIPpmihC3B4ceK7YrL0e1dYbmlpxBUFopx lxSivd2tb6yLPBL3FdzdBjPIpKFbcH0qKDTAWANYh1tyeXTIPD VLu+RmtB7t2Im1bjMYwkivqkZxZVuhUtgraeBC3PdFUKAuKQPZ H5roZ2xamPzmjfQmvIsbAB42Ku2Q90PUq/bIblLIFGkcNeDWk/ uFnngI= X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ace/ZC2sWARTIcWguvDN-cqtkrAWFHs Subject: [Ace] Webex Conference Call about "How to Select Hardware for IoT Systems?" --> *** Friday, 12th September *** X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Sep 2014 08:12:38 -0000

The Webinar will take place on Friday, 12th September 1pm BST.

As soon as I get access to the Webex credentials for the ACE working group setup I will distribute it.

Ciao
Hannes

-------- Forwarded Message --------
Subject: [Ace] Webex Conference Call about "How to Select Hardware for
IoT Systems?"
Date: Sat, 23 Aug 2014 14:24:51 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Ace@ietf.org <Ace@ietf.org>

Hi all,

Various groups in the IETF currently standardize technology for use with
constrained devices and the choice of hardware impacts the design of
Internet of Things (IoT) systems. To provide guidance RFC 7228
"Terminology for Constrained-Node Networks" defines three classes of
devices depending on their RAM and flash memory size. Class 0
characterizes devices that have less than 10 KiB of RAM and less than
100 KiB of flash memory and RFC 7228 adds "... most likely they will not
have the resources required to communicate directly with the Internet in
a secure manner." For others even class 2 with ~ 50 KiB of RAM and ~ 250
KiB of flash memory is too constrained.

With the increasing commercial interest in IoT the question about a
reasonable hardware configuration surfaces again and again. At IETF#90 I
offered to bring a hardware expert along. Peter Aldworth, a hardware
engineer with more than 19 years of experience, will lead the discussion
at an upcoming webinar.

Please indicate your availability here:
http://moreganize.com/bzTrVxhqaHp

Ciao
Hannes

From nobody Thu Sep 11 06:20:23 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8867C1A6F2B for ; Thu, 11 Sep 2014 06:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] 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 YPXXQyisOG3W for ; Thu, 11 Sep 2014 06:20:12 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 556C91A6F8D for ; Thu, 11 Sep 2014 06:20:11 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id D5C886D0 for ; Thu, 11 Sep 2014 15:20:09 +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 s8BDK9EH019730 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Sep 2014 15:20:09 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 6418518 for ; Thu, 11 Sep 2014 15:20:09 +0200 (CEST) Message-ID: <5411A188.6070906@sics.se> Date: Thu, 11 Sep 2014 15:20:08 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "ace@ietf.org" References: <4A2D1F85-3F11-4AFA-A7FD-76619EBA3132@automatedlogic.com> In-Reply-To: <4A2D1F85-3F11-4AFA-A7FD-76619EBA3132@automatedlogic.com> X-Forwarded-Message-Id: <4A2D1F85-3F11-4AFA-A7FD-76619EBA3132@automatedlogic.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090609080900050706060205" X-Bayes-Prob: 0.5049 (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.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09MNNk94x - 5c27790a7c41 - 20140911 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MNNk94x&m=5c27790a7c41&t=20140911&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MNNk94x&m=5c27790a7c41&t=20140911&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MNNk94x&m=5c27790a7c41&t=20140911&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/xhd-9nGW2ck8judtMGur8_cw-Ug Subject: [Ace] Fwd: Re: Feedback on building automation use case for ACE IETF X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Sep 2014 13:20:16 -0000 This is a cryptographically signed message in MIME format. --------------ms090609080900050706060205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hello, in Toronto Dave Robin promised us to provide feedback on building=20 automation use cases from the perspective of the BACnet committee. FYI here is what he sent me: -------- Forwarded Message -------- Subject: Feedback on building automation use case for ACE IETF From: Dave Robin In Toronto, I mentioned that the BACnet committee had had a meeting in the past to analyze all uses of broadcast and multicast in the building automation industry. We came up with this list: ------ From the September 22, 2010 web conference and the IT-WG Summit (Sept 21-23, 2011) ----- - Initial bootstrap (DHCP, link-local) - Small deployments with no central name/discovery server (mDNS, link-loc= al) - Change-of-Value reporting with many subscribers are more efficiently handled by multicast - Lighting: Group commands that must be executed quickly (e.g. "turn on the 5th floor lights") *- Reflashing/Updating: Large identical transfers to large numbers of recipients. ** Time sync * Sharing of widely-used data (outside air temperature, current electrical demand) * Device discovery/binding (Who-Is?) * Object discovery (Who-Has?) * Unsubscribed event notification ("For whomever might care... something bad happened") * Router announcement (I-Am-Router-To...) * Route discovery (Who-Is-Router-To...?) * Device announcement (I'm here... I'm still here <-- discouraged) * Private transfer (in use, but no *standard* uses) * Text message (in use, but no *standard* uses) ------------------------ The "reflashing" use case is the one that I was trying to remember in Toronto. I knew there was at least one other strong use case besides just lighting commands. From our experience, reflashing/patching/updating even a small wireless device, for example, is a brutal thing to do over constrained networks, taking thousands of times the normal operating bandwidth. Doing this to large groups of devices simultaneously is a tremendous time saver - comparing "an hour" to to "many days" for completion. But of course, this needs to be done securely! So it's would be a use case for ACE. Thanks, Dave -- Dave Robin Sr. Research Engineer Automated Logic | Building & Industrial Systems | United Technologies +1(770)795-4888 --------------ms090609080900050706060205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTExMzIwMDhaMCMGCSqGSIb3DQEJBDEW BBQRI8OMeTnnbfI+n8Z5VJ7pzjMm3zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEATkBaaom5j2CO8PhuZgHYpTAyArqY8m+A06x5U9KuWQm+fl3U9z0Si4u8fV6kpuIHrPID 8n2e1XP/zTfk3lQj64clkyq6xWbNiUDAzc2wW35Gf15v8T24gZK9jJh3zyH2UDktw+1VILBE gOW6Ekhwmq3/EI6UstQ4u7u9CvFxAdKUQBfoKXejZK8nn0yMdGe42a/kK5RAr6qxg5mk7O1Z GG97KrHyenFgXZX5m0wMTJIeyjd21Qh8BkY5/dqVyjBn2e+ARslNgO+wmLU9PJgF1jYHPWgK ouskYIDfkIoIVsLowjzs2Ii4DjoE7iMJqvEKxDrIcS3RZiOAoP1LgBDR0wAAAAAAAA== --------------ms090609080900050706060205-- From nobody Thu Sep 11 07:37:54 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4791A0AE2 for ; Thu, 11 Sep 2014 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 jQpHm8qRgQYA for ; Thu, 11 Sep 2014 07:37:44 -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 6EA031A00DA for ; Thu, 11 Sep 2014 07:37:44 -0700 (PDT) Received: from [192.168.10.162] ([207.47.25.82]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0McUnM-1Xjkub41gm-00HexS for ; Thu, 11 Sep 2014 16:37:42 +0200 Message-ID: <5411B3B3.6090709@gmx.net> Date: Thu, 11 Sep 2014 16:37:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <1421119808.24258.1410445648665.JavaMail.nobody@jva2tc112.webex.com> In-Reply-To: <1421119808.24258.1410445648665.JavaMail.nobody@jva2tc112.webex.com> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <1421119808.24258.1410445648665.JavaMail.nobody@jva2tc112.webex.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="51r9TRR8vTLpHAOg4594fTRsQx87T0Lv5" X-Provags-ID: V03:K0:rRiEz8n7bvXwOx+3f4HeZqnaEnIeluA1qvGhD2k+nYCUPsVhJvI keqSauopGkZ+/crhLOp1NhuhOhEfzj+OaB3EpWgMQx4sVOsdCAvtdj19fEYxwa36ysQA689 eGll2TSR9uucVnfrB/1orp+dLtTbDQd+DxG2uiapzjxt6Bhek5DB3utOj5w4l1Y1+VFIiyn ChIMfUClTI79M5YyALr+A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0j0DG9FJ3UyV2-HTspMM4W0wlI4 Subject: [Ace] WebEx meeting info: How to Select Hardware for IoT Systems? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Sep 2014 14:37:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --51r9TRR8vTLpHAOg4594fTRsQx87T0Lv5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, here is the webex information for our conference call tomorrow. We am looking forward to an interesting discussion. Ciao Hannes & Kepeng ----------------------- *How to Select Hardware for IoT Systems?* Friday, September 12, 2014 1:00 pm | GMT Summer Time (London, GMT+01:00) | 1 hr Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=3Dm1b9d0bcee385ebb169b4fb5631b7ab5= 3 Meeting number: 642 573 373 Meeting password: foobar Join by phone: +1-877-668-4493* Call-in toll free number (US/Canada) +1-650-479-3208* Call-in toll number (US/Canada) Access code: 642 573 373 Toll-free calling restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=3Dm5e23b4523c843310775c5e9c55f2f8e= 4 Can't join the meeting? Contact support: https://ietf.webex.com/ietf/mc --51r9TRR8vTLpHAOg4594fTRsQx87T0Lv5 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 iQEcBAEBCgAGBQJUEbOzAAoJEGhJURNOOiAtnagH/3bZTJJFq3NQn1kbIHVi0ebI iYCen2ozXJpgPTUa6zRmZWPbvBZhFUd5diQAeIBe4KfDSKPVM4C8EP/3/tghPj2q x0BCAWolR7P8ICUFEpIvZtth/4AmS9y6gzB7H8nLzxSbbPTQavnQcp3vhjJne3lz YcU0RayapRIxczRbO7haweqBssxIyJxCg2R3wlMsblpMu8wWihBdoP984sd2fqbU o/lrPsY1hlkCFcRqtbuDWPlwL9ZsMGxs8VbW9Y+WfA3cWUJWPBPorZMDHesPByTZ 17cMBeOdglGbGyr7H9jxc0t8X12uIM6kUUSamrpFLbzNNR7arSNtMA+b902dayU= =utGz -----END PGP SIGNATURE----- --51r9TRR8vTLpHAOg4594fTRsQx87T0Lv5-- From nobody Fri Sep 12 14:51:41 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162C11A00EF for ; Fri, 12 Sep 2014 14:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 boTkU7JsLESr for ; Fri, 12 Sep 2014 14:51:28 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525871A00E8 for ; Fri, 12 Sep 2014 14:51:25 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id a13so60938igq.0 for ; Fri, 12 Sep 2014 14:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=UDcJbNHNn+vQHX//cU8VqXLpqm8nP018gMe0h4oSPXo=; b=n5TUStHptv+ERhdqLXc29Tp2eFDzBHWF2ACQ72OvQyg6tBSfes2EJRnmuIgd1TFg9B asBaFQhQmrRyZSG6BqPfMMCEHCZ1keukDgY7a2/384m85DJdGjaa++oIcliKlXwXeUZ8 zu00wo1gkbO/sqv746MAaHJ3exazbBSg4+rJxrrg/+KiTK8rve0uuFS3e1r8637bLLG/ TZi2EVWaAyuF/t6uIzevQ/yyARSXVHvojw1WUTxJiBocDved0+YiMEOSx1UGSTg6fBV6 ePR+zQKXpCKsvlCwFexdzDm/S2nNQpGGYXUExbzdxeAGkvGu5S1B4qp2qLKk5rC2sCK5 0DEg== X-Received: by 10.50.117.6 with SMTP id ka6mr5704461igb.48.1410558684705; Fri, 12 Sep 2014 14:51:24 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id w8sm2589095igl.13.2014.09.12.14.51.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 14:51:24 -0700 (PDT) Message-ID: <54136AD8.6000402@gmail.com> Date: Fri, 12 Sep 2014 17:51:20 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "Ace@ietf.org" References: <1421119808.24258.1410445648665.JavaMail.nobody@jva2tc112.webex.com> <5411B3B3.6090709@gmx.net> In-Reply-To: <5411B3B3.6090709@gmx.net> Content-Type: multipart/alternative; boundary="------------090403070307080201030500" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/QYUwU3UwHKhwB6PR_CPvwre4uYs Subject: [Ace] some notes of the ARM call and tentative conclusions drawn for ACE (Re: WebEx meeting info: How to Select Hardware for IoT Systems?) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Sep 2014 21:51:33 -0000 This is a multi-part message in MIME format. --------------090403070307080201030500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes: Thanks for facilitating the ARM call. Please find below some notes that I wrote down based on the ARM presentation by Peter Aldworth (I had to leave the call at 9:05am EDT and do not know whether it ran longer). {Note: based on notes, since no access to presentation slides material (yet)} Notes: * silicon area is only tiny portion of hardware bill of material cost; indirect cost, such as code density, much more important * lifetime cost, such as battery lifetime and capability of, e.g., upgrading the device, much more important * development and deployment cost could be lowered by code reuse and debugging, etc., tools are nice to have, but for huge quantities again amortized cost relatively low * per-device MCU prices {with 128-256kB programming memory; 16kB-32kB SRAM} in the market (with low volume) seem to favor 32-bit processors (8-bit: $3.40-$9; 16-bit: $3-$40; 32-bit: $1.80-$9) -- extremely wide range in price points, but many vendors in ecosystem * cost of crypto processor [f/u. question Ludwig Seitz]: hardware-assist reduces code footprint, since functionality in hardware; no significant increase in cost at all * power consumption significantly benefits from crypto acceleration in hardware (e.g., less memory access) * energy cost [f/u. question Dan Romascanu]: various mechanisms to reduce energy during sleep mode (e.g. just SRAM, clock alive; processor does not run,, etc. * RAM cost [f/u. question Dominique Barthel]: RAM cost far less important than cost of # PINs, volume * Generally, perceived as mistake to optimize on cost Tentative conclusions, based on these notes, for ACE-related discussions: * potential need to reconsider relevance of device classes that have popped up in some device capability discussions in the past (including SRAM cost) * inclusion of crypto accelerator has barely impact on overall cost (including generic multiplier) * focus should be on total lifecycle cost and functionality offered (provisioning, upgrade, etc.) * need more detail on energy consumption crypto operations (and, perhaps, time latencies) Overall, presentation seems to suggest one can view all crypto building blocks as commodities for IoT security architectural deliberations with IETF ACE. On 9/11/2014 10:37 AM, Hannes Tschofenig wrote: > Hi all, > > here is the webex information for our conference call tomorrow. > We am looking forward to an interesting discussion. > > Ciao > Hannes & Kepeng > > ----------------------- > > *How to Select Hardware for IoT Systems?* > Friday, September 12, 2014 > 1:00 pm | GMT Summer Time (London, GMT+01:00) | 1 hr > > Join WebEx meeting > https://ietf.webex.com/ietf/j.php?MTID=m1b9d0bcee385ebb169b4fb5631b7ab53 > > Meeting number: 642 573 373 > Meeting password: foobar > > > Join by phone: > +1-877-668-4493* Call-in toll free number (US/Canada) > +1-650-479-3208* Call-in toll number (US/Canada) > Access code: 642 573 373 > > Toll-free calling restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=m5e23b4523c843310775c5e9c55f2f8e4 > > Can't join the meeting? Contact support: > https://ietf.webex.com/ietf/mc > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------090403070307080201030500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Hannes:

Thanks for facilitating the ARM call.

Please find below some notes that I wrote down based on the ARM presentation by Peter Aldworth (I had to leave the call at 9:05am EDT and do not know whether it ran longer).
{Note: based on notes, since no access to presentation slides material (yet)}

Notes:
* silicon area is only tiny portion of hardware bill of material cost; indirect cost, such as code density, much more important
* lifetime cost, such as battery lifetime and capability of, e.g., upgrading the device, much more important
* development and deployment cost could be lowered by code reuse and debugging, etc., tools are nice to have, but for huge quantities again amortized cost relatively low
* per-device MCU prices {with 128-256kB programming memory; 16kB-32kB SRAM} in the market (with low volume) seem to favor 32-bit processors
(8-bit: $3.40-$9; 16-bit: $3-$40; 32-bit: $1.80-$9) -- extremely wide range in price points, but many vendors in ecosystem
* cost of crypto processor [f/u. question Ludwig Seitz]: hardware-assist reduces code footprint, since functionality in hardware; no significant increase in cost at all
* power consumption significantly benefits from crypto acceleration in hardware (e.g., less memory access)
* energy cost [f/u. question Dan Romascanu]: various mechanisms to reduce energy during sleep mode (e.g. just SRAM, clock alive; processor does not run,, etc.
* RAM cost [f/u. question Dominique Barthel]: RAM cost far less important than cost of # PINs, volume
* Generally, perceived as mistake to optimize on cost

Tentative conclusions, based on these notes, for ACE-related discussions:
* potential need to reconsider relevance of device classes that have popped up in some device capability discussions in the past (including SRAM cost)
* inclusion of crypto accelerator has barely impact on overall cost (including generic multiplier)
* focus should be on total lifecycle cost and functionality offered (provisioning, upgrade, etc.)
* need more detail on energy consumption crypto operations (and, perhaps, time latencies)

Overall, presentation seems to suggest one can view all crypto building blocks as commodities for IoT security architectural deliberations with IETF ACE.

On 9/11/2014 10:37 AM, Hannes Tschofenig wrote:

Hi all,

here is the webex information for our conference call tomorrow.
We am looking forward to an interesting discussion.

Ciao
Hannes & Kepeng

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

*How to Select Hardware for IoT Systems?*
Friday, September 12, 2014
1:00 pm  |  GMT Summer Time (London, GMT+01:00)  |  1 hr

Join WebEx meeting
https://ietf.webex.com/ietf/j.php?MTID=m1b9d0bcee385ebb169b4fb5631b7ab53

Meeting number: 	642 573 373
Meeting password: 	foobar


Join by phone:
+1-877-668-4493* Call-in toll free number (US/Canada)
+1-650-479-3208* Call-in toll number (US/Canada)
Access code: 642 573 373

Toll-free calling restrictions:
http://www.webex.com/pdf/tollfree_restrictions.pdf


Add this meeting to your calendar:
https://ietf.webex.com/ietf/j.php?MTID=m5e23b4523c843310775c5e9c55f2f8e4

Can't join the meeting? Contact support:
https://ietf.webex.com/ietf/mc

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

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

--------------090403070307080201030500-- From nobody Mon Sep 15 01:50:26 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2811A0271 for ; Mon, 15 Sep 2014 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 nizL7-29TclB for ; Mon, 15 Sep 2014 01:50:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 D97851A026F for ; Mon, 15 Sep 2014 01:50:23 -0700 (PDT) Received: from [192.168.131.128] ([80.92.116.66]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MBnSJ-1XaqeQ2pIF-00AoEc for ; Mon, 15 Sep 2014 10:50:21 +0200 Message-ID: <5416A84C.9050301@gmx.net> Date: Mon, 15 Sep 2014 10:50:20 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a8njxQWrr7JUHTsFeklkkPOPPFLMQvCek" X-Provags-ID: V03:K0:HnVPGZgNw8MSmciDE6YvgbeOIbB0qq9vCOJzbKV56Odz+pQZbXN fU8y1ojNGB/NRunNfLA5F9WtGd1NurIlZt/Z2IMSG7xnXospjTBvCFWpmPzm5MymWRUXSiX jW3edS8Igvu21qtz//1nzDFfcBChbHVM5QmcXnw7YH3liq/FPDjhUr377ZwMXCOFtdC3OBf azv8t3BnJvTqrdfqN8gtw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ace/qybWuaU3nBJ9VVzBD-fG_AlJQKI Subject: [Ace] Slides and Recording of the Webinar X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Sep 2014 08:50:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a8njxQWrr7JUHTsFeklkkPOPPFLMQvCek Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, as requested, here are the slides and the recording of the webinar. Slides: http://www.tschofenig.priv.at/ace/IoT-HardwareTalk.pdf Webex: http://www.tschofenig.priv.at/ace/IoT-HardwareTalk.wmv http://www.tschofenig.priv.at/ace/IoT-HardwareTalk.mp4 Ciao Hannes --a8njxQWrr7JUHTsFeklkkPOPPFLMQvCek 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 iQEcBAEBCgAGBQJUFqhMAAoJEGhJURNOOiAt4o4IAICVp6RkaR9Y1erM1/XP1J8c FO2MsmubK/kkWxvTz+f6/D8Ft+bQTQ674IIm/534SkxxHRPNuSxo2fhPeAt/990o fkWRpSApk9h00Uy8GbwmsnPxiiS1+PUPyGZhEX85goPUAK/5beBGsFS2A7XK9hAY vpjBsPeLChZZVM9q4hvDwdNSV4ZK+16aiAFfSJh9tH4VrxL23r60WuelLnl0EWDd hCpDrJ8S8NtMWGR/5YL7SjdUgm01NtDlZPdcC5zwkejuIuvrAhtaxtvG+U0OkM/P za0W+Bv/uGhpK7sIhYh251dy5NIg9+StDZyyHAha3LeXaaMC3tXGgAaCWsh4dhY= =fkHp -----END PGP SIGNATURE----- --a8njxQWrr7JUHTsFeklkkPOPPFLMQvCek-- From nobody Wed Sep 24 00:06:44 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33881A883F for ; Wed, 24 Sep 2014 00:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 wXQQ9p832XsJ for ; Wed, 24 Sep 2014 00:06:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15921A88E1 for ; Wed, 24 Sep 2014 00:06:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJW15695; Wed, 24 Sep 2014 07:06:39 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 24 Sep 2014 08:06:38 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.205]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 15:06:33 +0800 From: Likepeng To: "ace@ietf.org" Thread-Topic: Next step for use case document Thread-Index: Ac/XxhJj1SXsKBa6RAi9F96goWJ5xA== Date: Wed, 24 Sep 2014 07:06:33 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25819F1DE@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F25819F1DESZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/NVGvQifeR3JVri62kqvwpNCLL0M Subject: [Ace] Next step for use case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Sep 2014 07:06:42 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25819F1DESZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks all for the feedbacks to the use case document: http://datatracker.ietf.org/doc/draft-seitz-ace-usecases/ Hannes and I went through the feedbacks in the mailing list. In summary, we feel that there is no consensus to adopt the current version= of this document. Considering that use case document is our charter item, and this is the onl= y viable candidate, our plan is to ask authors to update the draft accordin= g to the received feedbacks so far and we will initiate another call-for-ad= option for the new version. Also, kindly remind you to contribute your texts to the use case document. Thanks, Kind Regards Kepeng & Hannes --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25819F1DESZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks all for the feedbacks to= the use case document:

http://datatracker.ietf.org/doc/draf= t-seitz-ace-usecases/

Hannes and I went through the f= eedbacks in the mailing list.

In summary, we feel that there = is no consensus to adopt the current version of this document.

Considering that use case docum= ent is our charter item, and this is the only viable candidate, our plan is= to ask authors to update the draft according to the received feedbacks so = far and we will initiate another call-for-adoption for the new version.

Also, kindly remind you to cont= ribute your texts to the use case document.

Thanks,

Kind Regards<= /p>

Kepeng & Hannes<= /span>

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F25819F1DESZXEMA501MBSchi_-- From nobody Mon Sep 29 06:08:38 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788C1A1BD7 for ; Mon, 29 Sep 2014 06:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 a_0vlYUjnoZY for ; Mon, 29 Sep 2014 06:08:33 -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 6CE6D1A1B85 for ; Mon, 29 Sep 2014 06:08:31 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-98-542959cdd2db Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3A.CF.24955.DC959245; Mon, 29 Sep 2014 15:08:29 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.188]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Mon, 29 Sep 2014 15:08:28 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Likepeng , Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] Next step for use case document Thread-Index: AQHP2+Z2zMYxzyxQtE+FAIirW36spQ== Date: Mon, 29 Sep 2014 13:08:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7A9B5148E951F040B35AD8F03AF64868@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje7ZSM0Qgx8TVCy+f+thtli68x6r xZ7DTcwOzB6LN+1n82g58pbVY8mSn0wBzFFcNimpOZllqUX6dglcGSdaPrIWdBpVNLz4w9zA +Eqji5GTQ0LARGLTvnfMELaYxIV769m6GLk4hASOMkq0L53ACOEsYZT4tGMTI0gVm4CrxIEH 75hAbBGBIok5516wdDFycAgLGEm8OSUCETaWaDi4kB3C1pPYtmsfC4jNIqAq0TzhCtgyXgEL icUTOsBqGIEWfz+1Bmwks4C4xK0n85kgDhKQWLLnPNRxohIvH/9jBbFFgWZ+mnIOqkZRov1p AyNEr57EjalT2CBsa4nOrsdQM7Ulli18DbVXUOLkzCcsExhFZyFZNwtJ+ywk7bOQtM9C0r6A kXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBMHdzyW3UH4+U3jocYBTgYlXh4FfZqhAix JpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYzhUly+T3OBjLX uld/q55R+WxZ9NED1+xN3wuqh7So5Kp0a4oURAl8k/8WvUNh/pRd3+6GBRzMdzrDPkcl5lvX Yf0JPrYd57I6nTZs8tHX5BNiN+xqlLY6sW+2Om/rnqOGwgHu1eKd0e8+bWhr1ylum5neeo9r b4iElOF+z/+BSWI3rW8kKrEUZyQaajEXFScCAANmyDiKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1hfljA26Kgh9hnRljNWsPWmEr5Y Subject: Re: [Ace] Next step for use case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Sep 2014 13:08:35 -0000 Dear WG chairs and all, Please find below some further suggestions for content of the use case document. Apologies for the lengthy mail. I propose that some use case in the draft should highlight the need for a solution that supports secure store and forward. Here are a set of use cases supporting this, the first one is based on interviews with people working with utilities. The others use cases show that this is not an isolated example. (There is no need to include all use cases in the draft.) Utility data collection - - - A utility company is updating its old utility distribution network with advanced meters and new communication systems, known as an Advanced Metering Infrastructure (AMI). AMI refers to a system that measures, collects and analyzes usage, and interacts with metering devices such as electricity meters, gas meters, heat meters, and water meters, through various communication media either on request (on-demand) or on pre-defined schedules. Based on this technology, new services make it possible for consumers to control their utility consumption and reduce costs by supporting new tariff models from utility companies, and more accurate and timely billing. The technical solution is based on levels of data aggregation between =B3smart meters=B2 located at the consumer premises and the Meter Data Management (MDM) system located at the utility company. Two possible intermediate levels are: - Head-End System (HES) which is hardware and software that receives the stream of meter data and exposes an interface to the MDM. - Data Collection (DC) units located in a local network communicating with a number of smart meters and with a backhaul interface communicating with the HES, e.g. using cellular communication. For reasons of efficiency and cost end-to-end connectivity is not always feasible, so metering data is stored in batches in DC for some time before being forwarded to the HES, and in turn accessed by the MDM. The HES and the DC units may be operated by a third party service operator on behalf of the utility company. One responsibility of the service operator is to make sure that meter readings are performed and delivered to the HES. An example of a Service Level Agreement between the service operator and the utility company is e.g. "at least 95 % of the meters have readings recorded during the last 72 hours=B2. Security properties The utility company wants to verify stored and forwarded metering data with respect to authenticity, integrity and replay. The utility company wants to configure utility meters securely: The devices should be able to verify that a configuration request is authorized, authentic, integrity and replay protected. The utility company wants to be in control of access to plain text metering data. Other parties may be allowed access but at the discretion of the utility company. E.g. the service operator needs access during test or error cases, or for calibrating units on replacement. In particular, it should be possible to confidentiality protect the metering data between smart meter and the utility company's network. (There are also other desirable security properties, the ambition here is not to be exhaustive but to highlight the need for end-to-end authorised access. ) Actually, the drive-by metering use case (section 2.5.1) may require a similar functionality: Drive-by metering data collection - - - The meters communicate with a vehicle-attached base station, which drives by and collects meter readings. The drive-by service could potentially be operated by a third party collecting meter readings on behalf of one or multiple utility companies, and should not have access to plain text meter readings, or not be able to change the readings. Also in this case it may be cost-efficient to upload the readings from the vehicle once the car returns to the 3rd party premises, e.g. over WLAN. This means that the readings need to be stored and later forwarded, and should be protected end-to-end between smart meter and Meter-Data Management system in the respective utility company network analogously to the previous use case. There are other examples where it may be impossible or infeasible to support end-to-end connectivity, e.g. in networks with sleepy devices, in which case a publish-subscribe paradigm may be more natural. Here we pick another application of publish-subscribe: Information Centric Networking (ICN) - - - ICN is a paradigm for data access, changing focus from current host-centric network to an information-centric network. In a host-centric network, the basic idea is to create secure connections to hosts of trusted providers of data. In an information-centric network, on the other hand, it is acceptable that any source (cache) should be equally usable. This requires some mechanism for making each information item trustworthy by itself, which can be achieved for example by signing data. In this case a consumer of an information object could prove its authenticity by verifying the digital signature. Applying ICN to the IoT setting, sensor readings could be protected and stored in arbitrary content nodes, not necessarily only in origin servers; device configuration updates could be protected and stored in proxies, not necessarily only in dedicated configuration servers. Similar security properties apply as in the previous cases. G=F6ran From: Likepeng Date: Wednesday 24 September 2014 09:06 To: "ace@ietf.org" Subject: [Ace] Next step for use case document >Thanks all for the feedbacks to the use case document: >http://datatracker.ietf.org/doc/draft-seitz-ace-usecases/ >=20 >Hannes and I went through the feedbacks in the mailing list. > >=20 >In summary, we feel that there is no consensus to adopt the current >version of this document. >=20 >Considering that use case document is our charter item, and this is the >only viable candidate, our plan is to ask authors to update the draft >according to the received feedbacks so far and we will initiate another >call-for-adoption > for the new version. >=20 >Also, kindly remind you to contribute your texts to the use case document. >=20 >Thanks, >=20 >Kind Regards >Kepeng & Hannes