From nobody Wed Jul 1 00:21: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 9F5911B2A77 for ; Wed, 1 Jul 2015 00:20:59 -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 73bwckwEqY5r for ; Wed, 1 Jul 2015 00:20:58 -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 EE92E1B2A6E for ; Wed, 1 Jul 2015 00:20:54 -0700 (PDT) Received: from [192.168.131.139] ([80.92.122.75]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MEWPx-1ZGY7Z3nVB-00FjsC for ; Wed, 01 Jul 2015 09:20:53 +0200 Message-ID: <559394D5.2000602@gmx.net> Date: Wed, 01 Jul 2015 09:20:53 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VpOmeRhbQXtirHoahJTPqqMw42732C45D" X-Provags-ID: V03:K0:sgrnj2GvL8SU+TelE0fD3gD1azJ1AcaOxAYPafuUswK7SD3t7qC 5nph0qiebgxUST70yeuiY17fJDA8LEA/4O9B0bHhcA1hIx2JizHwjL5VR+9tZJLns9k9V/k pBIC3IjqxM++4Tv/IUw06iGjf8zEYcUoQgW74W48F6gXLCCsmKzI5Y/x2MmewnilTmXHWpp FOL0q9n66XpmjfgqsqTew== X-UI-Out-Filterresults: notjunk:1;V01:K0:1rxjFdXw7Pk=:Rs9l6wXOTa5zTAtAd/5wBR MI5+csRCsElJiYO40tZzKoQgkipmAo+RuysOXlxx7gMWx9jkiyP7la0bSrKaDi6zLnPATZUyS MItT49r2+pddeTU0782Nqh5mNbO0pdmAQSKUxzZvle/vaGpJV9HOshDu37cx7bOdv993VLUtQ e47K0uxFeNmDirciNk41maym7qNz5+EO0M7qiAbfnFJA8en6CeFUYF6YxXo+X12v/5MucgIyG s9gwLWrezDsXMle0r44plTMHtq7ZyT1TamF/OPATK1W0uTjoPN5brWLJR8KGJdjaQUgB3aU6g xrfn76DTVou9ckIZM8pEzJYl3QkuMYIWoQbsrb8Vo8VABDEAMx8orRDgJ0HUPwiixmHJHQoPn 5+qFoQCj5nhtF6Zx4NGr2Wz2b6kXxO3W4p6GYi2vsDlk/xHvUjr1++sST9P4spn8fxezc0W2/ L22/wEsgsaVBnZgaleVC+nUHmuY5DSYO414KTzw1p3tpLWsu1lRsi+Ohy9+xg2Rzc1kpYTESy 0Jaxh4Ple2I+d6fCiUlqYe0h+Gxyn1JDBZDKq082iFZbjhABeEoijzjSlqmLe1Hk3ZeYc0o7S sRxGjvGe6axi4R47YI16dz0MYhKGwAa6kFShnpyitz3VZF8alLHxrNIUmwWO4jGp9m3FJ6E7A glJJzGLwtHpsNft9a08QzWIrYdo3YnFWtOGgYTgBz9LZc+A== Archived-At: Subject: [Ace] Promised Draft Reviews X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 07:20:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VpOmeRhbQXtirHoahJTPqqMw42732C45D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I have just checked the list of persons who volunteered to review the use case/actors document and I had to notice that not much review has been provided so far. I only see a review from Thomas about the use case draft! Actors/Architecture: - Thomas Hardjono - Sean Turner - Sandeep Kumar - Alper Yegin Use Cases: - Carsten Bormann - Thomas Hardjono: http://www.ietf.org/mail-archive/web/ace/current/msg01168.html - Kepeng Li Please have a look at the document so that the authors can incorporate feedback in time for the document submission deadline. Ciao Hannes --VpOmeRhbQXtirHoahJTPqqMw42732C45D 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 iQEcBAEBCgAGBQJVk5TVAAoJEGhJURNOOiAtRnsH/38hNL1SoZLoUz2xi5zcOj2v 6I9pRit5MLb9PvXg4tfQ15iacQhkm7E8XjTmG50rX3GxhmW6BwJJ+n+5pedg1ljn DOa5gdiqe7yp9TVWhbGNxkcHY9psb9HxBzD3sGoteAqQxB9ByZUBt7JW1oUb1hSH dSrVV5oJymN9jKDKOxSt6MxROlPXPHyhIzVjj+XQGvjhHOT3AnVVYQ76dMwZJGyF 3xfjWUBYiCE8Pg5yKOnHBQ+HVH09IoX/rVIxfV6+PdyS9S4Zg60PvENcSLDnFEef /F7Cr1kJgMQUGLAZSxOZHJKAZULqHp/sv/Dfy9TMonwNdu397CbJvc8YI24Kh/Q= =F2IG -----END PGP SIGNATURE----- --VpOmeRhbQXtirHoahJTPqqMw42732C45D-- From nobody Wed Jul 1 00:24: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 62A391B2A9E for ; Wed, 1 Jul 2015 00:24:09 -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 BgLWssT9-ux0 for ; Wed, 1 Jul 2015 00:24:05 -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 A03911B2A9D for ; Wed, 1 Jul 2015 00:24:04 -0700 (PDT) Received: from [192.168.131.139] ([80.92.122.75]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M7pDs-1Yo77500O0-00vLUM for ; Wed, 01 Jul 2015 09:24:03 +0200 Message-ID: <55939592.9050503@gmx.net> Date: Wed, 01 Jul 2015 09:24:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Rp9Gud8g7eE6JRtROfFjDEL3oWq3FbJAn" X-Provags-ID: V03:K0:2t8UX9Vg1I2XvygViBVuvS3xxSmlEq3+yezs3UGi1iwGy1+heJ2 pqLmtJAocAYwztcRkvNqssIppJj/Ul5PasDeXMlkS3aKpDPUbWoJXSCdVgxlg+X+91dSSFJ uXC5XSFZkX7FTeRlz/IFFdgb16DValI1RNMsHAfH2LVkOYRekzghvx4a+GeW2COIkdeS143 zLkCK1Z//istlUixD5f0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:CSmcZ6r9hTY=:mMCh7ToV/e7zeBk+Jhw1o9 Od7Sk6+z9NrKPgR60Pvm+xxc9ECxnwmxhEvI2KSZ512BxQnPzLeJFP5GZ7fMT5jBlSQK4wdQM GMrb8nL/rLKeaw4lykjBzQvFMkoh61Zi3ux5CyNAiBVvEECsdr3uPyZ5yY2d7b/eVPA3DILmd mG4k8t2ojhta5IjD7YleLDpMCaruoZaq/yWj3kzzEQ23uZIW6tbjPP8IZ0i5LLiaghNnCF90V PwGRRiUgIRkBZg9ijMcm5AHk4Ovu7rb7om+IYWIg56qOTG627KLEvotmYv9wmvJvxfpsD3j+/ FUr+IoXEI1grp/+6vB98sN0lDgpm0NvEd82IR5pMylpLDB42gqFkLumfHFArIVvSzMSBJWrWs DLKa+GHCK2GtdmuH57K0bvRLZSb/gb6x/BFDEOBW7NatdpXwTEtGi0QpDKC7fEp1bnCCPc5BO 9bpyQ9uOUnzQGYWJVjCfqzwCZqh+AjqWDkkmeAtHraja9mSz0ogViBzq84IGXN1AacXHlHfz4 Mv1d8cqV1Xitp92elWwe4Ngp7KALjIERVmemuh4MsfF5hwxx1/vxnzfx9KYxSD/52W5rqYK86 HJJFOL3LbxYA1q1mKuRA+wpLdggttCOblohyXqrAVdTwl+PVtV5f7kr9B6S2W67jVFIphAybu mRoJY/zitXZ5c+xkflnCFqwvRmhgkGHRwT7aK2Fw+pY80QA== Archived-At: Subject: [Ace] ACE Interim meeting minutes (May 27, 2015) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 07:24:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Rp9Gud8g7eE6JRtROfFjDEL3oWq3FbJAn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ACE interim meeting minutes: Time: Wednesday, May 27, 2015, 14:00 ~ 15:00 UTC Attendees: Corinna Schmitt, Carsten Bormann, Kepeng Li, Hannes Tschofenig, Alper Yegin, Gord Coulson, Goran Selander, Kethleen Moriarty, Klaus Hartke, Sandeep Kumar, Santosh Chokhani, Sean Turner, Steve Moore, Thomas Hardjono, Ludwig Seitz Notes written by Kepeng Li. 1. Actors draft discussion: Hannes: we have to get more reviews, and we need to update our charter and milestones to include this item. Kathleen: like to see more reviews, more interests, and more energy in this WG. Kepeng: are there any open issues for the actors draft? Carsten: we can discuss the open issues from the review, and after the adoption. Hannes: we need to balance the cost and benefit between symmetric key and asymmetric key. Goran: we need to discuss what are the targeted devices. Hannes: one issue is how to uniquely identify the device. Ludwig: we can use data tracker and wiki to track the open issues. Volunteers to review the actors draft: Thomas Hardjono, Sean Turner, Sandeep Kumar, Alper Yegin. 2. Next step for the use case document. Ludwig: when to make updates for the use case document? Hannes: editors post their response to the list, get rough consensus and make updates accordingly. Volunteers to review the use case draft: Carsten Bormann, Thomas Hardjono, Kepeng Li. 3. AOB Kepeng: have requested 2.5 hours for Prague F2F meeting. Kathleen: want to see more reviews and discussions in the mailing list. --Rp9Gud8g7eE6JRtROfFjDEL3oWq3FbJAn 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 iQEcBAEBCgAGBQJVk5WSAAoJEGhJURNOOiAtuvYIAJ4NcppjirQfKELvJAG1zMWR lBLp8ep6fl6eDY7GgBjvtGK0a2SLw7uobOh8mvLMmoFQ7ORIqB6a4HtqQ+Qq5UDM JSD248xHL7DfRaPG/ygPHDSMbAiqrQAZVv2oagtFpVyPLnO1F3sk7rFhHj2Ejvbl bfSwOgnlgztRjPfVHTgjCDb3K+It+XIHUZNXjYthda3PcvJUSL4tnwPx11mzMaIk jRMRTFz0erqKq38W9MfF9IG/EK1SQY/aGJTCzfKOS3lSa11ZFGMKqGDE71dDaZTl iVQCB2c4l1F5HldwVuZNk/UOgqTh9GTJw8hiXSbyXvneFeIAFZn0MK+d5P+Kkvg= =abrO -----END PGP SIGNATURE----- --Rp9Gud8g7eE6JRtROfFjDEL3oWq3FbJAn-- From nobody Wed Jul 1 03:46: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 6F00B1A873D for ; Wed, 1 Jul 2015 03:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=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 TxIJ8pgx79EG for ; Wed, 1 Jul 2015 03:46:03 -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 011E81A1BBB for ; Wed, 1 Jul 2015 03:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1435747563; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=ERi4FdPgET5HFbPdidE0yVfSLcC2nSrPXrCC8kss68M=; b=mhLMBB9KB6kw1AWxv3BNwKS8fv1cVbgAhojuTS2IGgnQgiqyySKJgFXvAciBiRYJE3v1kVF/FTtBMbBhRYF/vJxSH0xUS+lCNvwyxsEQjBuZ4CFzfuVdb+/2dDkrActmXFAt68iYE9ODopO8bNngAbkW8HOyGAieUn+h1rZhdAM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=c01a14441; MF=kepeng.lkp@alibaba-inc.com; NM=0; PH=DS; RN=1; RT=1; SR=0; Received: from 10.1.152.112(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.159) by smtp.aliyun-inc.com(127.0.0.1); Wed, 01 Jul 2015 18:45:56 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 01 Jul 2015 18:45:51 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: Comments to the ACE use case document Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518621156_7385731" Archived-At: Subject: [Ace] Comments to the ACE 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, 01 Jul 2015 10:46:06 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3518621156_7385731 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hello all, Please find my review comments to the use case document: http://www.ietf.org/id/draft-ietf-ace-usecases-04.txt 1) 2.2.1 Add full spelling for HVAC, that is: (Heating, Ventilation and Air Conditioning). 2) U3.4 Devices are often used with default access control settings. It is not clear what is the authorization problem. Is it desired to have default settings or do we want to change the settings? If it is desired, we should change the sentence to: The wearer of an eHealth device wants his device to have default access control settings. 3) U3.6 Security mechanisms themselves could provide opportunities for denial of service attacks on the device. Denail of service attack can also happen to Authorization Server. My suggestion is to remove "on the device=A1=B0, or add "and Authorization Server=A1= =B0. 4) U1.9 Messages between client and resource server might need to be forwarded over multiple hops. U5.8 Messages between endpoints may need to be stored and forwarded over multiple nodes. It is not clear what is the authorization problem with these two. The sentence sounds like a condition. My suggestion is to change it to somethin= g like: messages between endpoints need to be protected for intergrity and confidentially when they are stored or forwarded over multiple nodes. 5) U1.10 The constrained devices might not always be able to reach the Internet. U5.5 The devices may have intermittent Internet connectivity. U7.3 Some devices do not have direct Internet connection. U7.4 Some devices have wired connection while others use wireless. About these four, it is not clear about the authorization problem. It is a condition. My suggestion is to change it to something like: Some devices do not have direct Internet connection, and can=A1=AFt get authorization decision = in real time. 6) 3.2 Configuration of Access Permission It is important to protect the authorization decisions not to be reused, stolen or intercepted. I suggest adding one bullet as a security consideration: The device should prove its possission of policy decisions when it presents them to Authorization Server. 7) 3.3. Design Considerations for Authorization Solutions I am not sure why this part belongs to Security Considerations. Should it b= e a separate section? Thanks, Kind Regards Kepeng Li (Individual) --B_3518621156_7385731 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hello all,
<= font face=3D"Courier">
Please find my review comments to the use case document:

= 1) 2.2.1 Add full spelling for HVAC, that is: (Heating, Vent= ilation and Air Conditioning).

=
2) U3.4 Devices are often used with default access control settings.<=
/pre>
It is not clear what is the authorization problem. Is=
 it desired to have default settings or do we want to change the settings? I=
f it is desired, we should change the sentence to: 
The wearer of an eHealth device wants his device to have defaul=
t access control settings.

<=
/span>
3) U3.6 Security mechanisms themselves could =
provide opportunities for denial of service attacks on the device.
Denail of service attack can also happen to Authorizati=
on Server. My suggestion is to remove "on the device“, or add "and Aut=
horization Server“.

4) U1.9 Messages between client and resource server might need to be forw=
arded over multiple hops.
   U5.8 Messa=
ges between endpoints may need to be stored and forwarded over multiple node=
s.
It is not clear what is the authorization probl=
em with these two. The sentence sounds like a condition. My suggestion is to=
 change it to something like: messages between endpoints need to be protecte=
d for intergrity and confidentially when they are stored or forwarded over m=
ultiple nodes.

=

5)  U1.1=
0 The constrained devices might not always be able to reach the Internet.
    U5.5 The devic=
es may have intermittent Internet connectivity.
    U7.3 Some devices do not have direct Internet connection.=

    U7.4 Some devices have wired conne=
ction while others use wireless.
About these f=
our, it is not clear about the authorization problem. It is a condition. My =
suggestion is to change it to something like: Some devices do not have direc=
t Internet connection, and can’t get authorization decision in real ti=
me.

6)  3.2 Configuration of Access Permission
It is important to protect the authorization de=
cisions not to be reused, stolen or intercepted.
I suggest adding one bullet as a security consideration: The d=
evice should prove its possission of policy decisions when it presents them =
to Authorization Server.

=

7) 3.3.  Design=
 Considerations for Authorization Solutions
I<=
/span> am not sure why this part belongs to Security Considerations. Sho=
uld it be a separate section?
<=
br>
Thanks,
Kind Regards
Kepeng Li (Individual)

--B_3518621156_7385731-- From nobody Wed Jul 1 06:15: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 B1A521A8830 for ; Wed, 1 Jul 2015 06:15:33 -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 9TCmUIHFnD5K for ; Wed, 1 Jul 2015 06:15:31 -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 C6E5D1A8850 for ; Wed, 1 Jul 2015 06:15:28 -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 t61DFKmw029779; Wed, 1 Jul 2015 15:15:20 +0200 (CEST) Received: from [192.168.1.109] (p57A636A6.dip0.t-ipconnect.de [87.166.54.166]) (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 3mM32J4KTMz3H0F; Wed, 1 Jul 2015 15:15:20 +0200 (CEST) Message-ID: <5593E7E2.1010709@tzi.de> Date: Wed, 01 Jul 2015 15:15:14 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kepeng Li , "ace@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Comments to the ACE 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, 01 Jul 2015 13:15:33 -0000 Hi Kepeng, Thank you for your review. Some comments inline. On 07/01/2015 12:45 PM, Kepeng Li wrote: > Hello all, > > Please find my review comments to the use case document: > http://www.ietf.org/id/draft-ietf-ace-usecases-04.txt > > 1) 2.2.1 Add full spelling for HVAC, that is: (Heating, Ventilation and Air > Conditioning). > > 2) U3.4 Devices are often used with default access control settings. > It is not clear what is the authorization problem. Is it desired to have > default settings or do we want to change the settings? If it is desired, we > should change the sentence to: > The wearer of an eHealth device wants his device to have default access > control settings. U3.4 refers to the problem that users often don't change the default settings. A solution designer needs to keep this in mind. We might change this to "Devices are often used with default access control settings which might threaten the security objectives of the device's users." or something like that. > > 3) U3.6 Security mechanisms themselves could provide opportunities for > denial of service attacks on the device. > Denail of service attack can also happen to Authorization Server. My > suggestion is to remove "on the device“, or add "and Authorization Server“. How about: "Security mechanisms themselves could provide opportunities for denial of service attacks, especially on the constrained devices." > > 4) U1.9 Messages between client and resource server might need to be > forwarded over multiple hops. > U5.8 Messages between endpoints may need to be stored and forwarded over > multiple nodes. > It is not clear what is the authorization problem with these two. The > sentence sounds like a condition. My suggestion is to change it to something > like: messages between endpoints need to be protected for intergrity and > confidentially when they are stored or forwarded over multiple nodes. This is a bit difficult to change. The use cases draft aims at listing problems, not requirements. And we don't know if the principals always need integrity AND confidentiality. The best I can think of is: "Users want their security objectives to be achieved even if the messages between endpoints are forwarded over multiple hops." > > 5) U1.10 The constrained devices might not always be able to reach the > Internet. > U5.5 The devices may have intermittent Internet connectivity. > U7.3 Some devices do not have direct Internet connection. > U7.4 Some devices have wired connection while others use wireless. > About these four, it is not clear about the authorization problem. It is a > condition. My suggestion is to change it to something like: Some devices do > not have direct Internet connection, and can’t get authorization decision in > real time. But the devices might be able to get authorization decisions, just not from a server somewhere in the Internet. They may have a local Authorization Server or may even ask their users if they are available. > > 6) 3.2 Configuration of Access Permission > It is important to protect the authorization decisions not to be reused, > stolen or intercepted. > I suggest adding one bullet as a security consideration: The device should > prove its possission of policy decisions when it presents them to > Authorization Server. I don't really understand this comment. Can you elaborate that? > > 7) 3.3. Design Considerations for Authorization Solutions > I am not sure why this part belongs to Security Considerations. Should it be > a separate section? Section 3.3. derives from the problem summary sections which problems solution designers should consider. Doesn't that fit into a security considerations section? Do you think that the contents don't fit or is the heading a misnomer? Thanks Steffi From nobody Wed Jul 1 07:47: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 5F9171A8912 for ; Wed, 1 Jul 2015 07:47:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 U3Axkix2msoI for ; Wed, 1 Jul 2015 07:47:09 -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 AB6041A8AE4 for ; Wed, 1 Jul 2015 07:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1435762012; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=N67QKFlRZSa5OZ0wqemBJixNjxuzNHli7z1i89f/v4c=; b=N+rKor/7rV2vwx9bAmKXNJl5WhlVJ2VpNYCB7Pw9gzA+e3LMRJhXgS0nt+IAXNVx8rumWTB9btovzBAbs/0sTrg7kgjSXaLgr7ngtO7Llf2O54/dy3MB+v6A8F9eVkPC9htV0ETqeWG5QVwdodUNr9qzXqbBwHMSFh1Vos8RpN8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R731e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=c01a14439; MF=kepeng.lkp@alibaba-inc.com; NM=0; PH=DS; RN=2; RT=2; SR=0; Received: from 10.22.56.172(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Wed, 01 Jul 2015 22:46:50 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 01 Jul 2015 22:46:45 +0800 From: "Kepeng Li" To: Stefanie Gerdes , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Comments to the ACE use case document References: <5593E7E2.1010709@tzi.de> In-Reply-To: <5593E7E2.1010709@tzi.de> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] Comments to the ACE 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, 01 Jul 2015 14:47:12 -0000 Hi Steffi, Thanks for the feedback. Please find my comments inline. And I add another new comment: Section 2.2, in case of renting a house, we should consider a new authorziation problem below: U2.X The home owners want to grant access permissions to a party in a specified timeframe. We have U2.4 which talks about granting temporary access permissions, but to me, temporary usually means one-time permission, it is different from one year permission. Kind Regards Kepeng =D4=DA 1/7/15 9:15 pm=A3=AC "Stefanie Gerdes" =D0=B4=C8=EB: >Hi Kepeng, > >Thank you for your review. Some comments inline. > >On 07/01/2015 12:45 PM, Kepeng Li wrote: >> Hello all, >>=20 >> Please find my review comments to the use case document: >> http://www.ietf.org/id/draft-ietf-ace-usecases-04.txt >>=20 >> 1) 2.2.1 Add full spelling for HVAC, that is: (Heating, Ventilation and >>Air >> Conditioning). >>=20 >> 2) U3.4 Devices are often used with default access control settings. >> It is not clear what is the authorization problem. Is it desired to have >> default settings or do we want to change the settings? If it is >>desired, we >> should change the sentence to: >> The wearer of an eHealth device wants his device to have default access >> control settings. > >U3.4 refers to the problem that users often don't change the default >settings. A solution designer needs to keep this in mind. We might >change this to "Devices are often used with default access control >settings which might threaten the security objectives of the device's >users." or something like that. OK. > >>=20 >> 3) U3.6 Security mechanisms themselves could provide opportunities for >> denial of service attacks on the device. >> Denail of service attack can also happen to Authorization Server. My >> suggestion is to remove "on the device=A1=B0, or add "and Authorization >>Server=A1=B0. > >How about: "Security mechanisms themselves could provide opportunities >for denial of service attacks, especially on the constrained devices." OK. > >>=20 >> 4) U1.9 Messages between client and resource server might need to be >> forwarded over multiple hops. >> U5.8 Messages between endpoints may need to be stored and forwarded >>over >> multiple nodes. >> It is not clear what is the authorization problem with these two. The >> sentence sounds like a condition. My suggestion is to change it to >>something >> like: messages between endpoints need to be protected for intergrity and >> confidentially when they are stored or forwarded over multiple nodes. > >This is a bit difficult to change. The use cases draft aims at listing >problems, not requirements. And we don't know if the principals always >need integrity AND confidentiality. The best I can think of is: "Users >want their security objectives to be achieved even if the messages >between endpoints are forwarded over multiple hops." In fact, we already have several sentences about intergrity and confidentiality, e.g. U1.2, U1.3, U1.4, U1.6. But the new wording is fine with me. > >>=20 >> 5) U1.10 The constrained devices might not always be able to reach the >> Internet. >> U5.5 The devices may have intermittent Internet connectivity. >> U7.3 Some devices do not have direct Internet connection. >> U7.4 Some devices have wired connection while others use wireless. >> About these four, it is not clear about the authorization problem. It >>is a >> condition. My suggestion is to change it to something like: Some >>devices do >> not have direct Internet connection, and can=A1=AFt get authorization >>decision in >> real time. > >But the devices might be able to get authorization decisions, just not >from a server somewhere in the Internet. They may have a local >Authorization Server or may even ask their users if they are available. Maybe we need a better wording. My point is, we should make it clear, what is the authorization problem if the device does not have internet connection. Something like: The devices need to be authorized even if the devices do not have direct Internet connection. > >>=20 >> 6) 3.2 Configuration of Access Permission >> It is important to protect the authorization decisions not to be reused, >> stolen or intercepted. >> I suggest adding one bullet as a security consideration: The device >>should >> prove its possission of policy decisions when it presents them to >> Authorization Server. > >I don't really understand this comment. Can you elaborate that? For example, I got the room key (authorization decision) from the hotel. But it is lost and picked up by Guest A. Guest A got my room key and entered my room. We should aviod this situation to happen. So I propose the add one security consideration bullet above. > >>=20 >> 7) 3.3. Design Considerations for Authorization Solutions >> I am not sure why this part belongs to Security Considerations. Should >>it be >> a separate section? > >Section 3.3. derives from the problem summary sections which problems >solution designers should consider. Doesn't that fit into a security >considerations section? Do you think that the contents don't fit or is >the heading a misnomer? >From the content, it talks about how to enforce and update ploicies, how to revoke decisions, usabilities, etc. It does not really fit into a security consideration. It seems to me design considerations and security considerations should be in parallel sections. > >Thanks >Steffi From nobody Wed Jul 1 08:40: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 85DF01A90A7 for ; Wed, 1 Jul 2015 08:40:11 -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 hmCPkMd2o2qE for ; Wed, 1 Jul 2015 08:40:10 -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 DDA511A9090 for ; Wed, 1 Jul 2015 08:40: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 t61Fe1VX002562; Wed, 1 Jul 2015 17:40:01 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:9996:78eb:bf93:fe5c] (unknown [IPv6:2001:638:708:30da:9996:78eb:bf93:fe5c]) (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 3mM6FD6mr6z3GfN; Wed, 1 Jul 2015 17:40:00 +0200 (CEST) Message-ID: <559409CA.3040008@tzi.de> Date: Wed, 01 Jul 2015 17:39:54 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kepeng Li , "ace@ietf.org" References: <5593E7E2.1010709@tzi.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Comments to the ACE 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, 01 Jul 2015 15:40:11 -0000 Hi Kepeng, Thank you for your comments. On 07/01/2015 04:46 PM, Kepeng Li wrote: > Hi Steffi, > > Thanks for the feedback. > > Please find my comments inline. > > And I add another new comment: > > Section 2.2, in case of renting a house, we should consider a new > authorziation problem below: > > U2.X The home owners want to grant access permissions to a party in a > specified timeframe. > > > We have U2.4 which talks about granting temporary access permissions, but > to me, temporary usually means one-time permission, it is different from > one year permission. I would think that temporary can also mean a one year permission, but I guess we can just change U2.4 to "The home owners want to grant access permissions to a party in a specified timeframe." > > 在 1/7/15 9:15 pm， "Stefanie Gerdes" 写入: >> >> On 07/01/2015 12:45 PM, Kepeng Li wrote: >>> >>> 5) U1.10 The constrained devices might not always be able to reach the >>> Internet. >>> U5.5 The devices may have intermittent Internet connectivity. >>> U7.3 Some devices do not have direct Internet connection. >>> U7.4 Some devices have wired connection while others use wireless. >>> About these four, it is not clear about the authorization problem. It >>> is a >>> condition. My suggestion is to change it to something like: Some >>> devices do >>> not have direct Internet connection, and can’t get authorization >>> decision in >>> real time. >> >> But the devices might be able to get authorization decisions, just not >>from a server somewhere in the Internet. They may have a local >> Authorization Server or may even ask their users if they are available. > > Maybe we need a better wording. My point is, we should make it clear, what > is the authorization problem if the device does not have internet > connection. > > Something like: The devices need to be authorized even if the devices do > not have direct Internet connection. But the problem at this point is that they don't always have the Internet connection. How about: "The constrained devices might not always be able to reach the Internet but still need to enact the authorization policies of their principals."? > >> >>> >>> 6) 3.2 Configuration of Access Permission >>> It is important to protect the authorization decisions not to be reused, >>> stolen or intercepted. >>> I suggest adding one bullet as a security consideration: The device >>> should >>> prove its possission of policy decisions when it presents them to >>> Authorization Server. >> >> I don't really understand this comment. Can you elaborate that? > > For example, I got the room key (authorization decision) from the hotel. > But it is lost and picked up by Guest A. Guest A got my room key and > entered my room. > > We should aviod this situation to happen. So I propose the add one > security consideration bullet above. I agree that we should avoid this to happen, but it seems to me that this is a very specific implementation detail. There will be a lot of requirements that solutions must meet, but the use cases document is not about requirements. The items listed in 3.2, 3.3 and 3.4 derive from the problem summary sections and just summarize them. > >> >>> >>> 7) 3.3. Design Considerations for Authorization Solutions >>> I am not sure why this part belongs to Security Considerations. Should >>> it be >>> a separate section? >> >> Section 3.3. derives from the problem summary sections which problems >> solution designers should consider. Doesn't that fit into a security >> considerations section? Do you think that the contents don't fit or is >> the heading a misnomer? > > From the content, it talks about how to enforce and update ploicies, how > to revoke decisions, usabilities, etc. It does not really fit into a > security consideration. > > It seems to me design considerations and security considerations should be > in parallel sections. As I said above, the sections 3.2 and 3.3 and 3.4 are just summarizing the problem summary sections. To make this a bit more understandable, we divided the summary into three sections. It will be very difficult to keep the focus of the draft (the listing of authorization problems) if we have a distinct design consideration section. Best regards, Steffi From nobody Wed Jul 1 16:28:37 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 DA63F1B2C2E for ; Wed, 1 Jul 2015 16:28:35 -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 LH1ii8zti5pb for ; Wed, 1 Jul 2015 16:28:34 -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 0F69E1B2C2F for ; Wed, 1 Jul 2015 16:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1435793304; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=RuOQXkQyibzoxKS59gQxf9Y/ZFw6lRDPWni2F/5XjnY=; b=dTagdsNL4Vz+HGs63Ku+u9JeXZMEbWYT6BtKk4PbgweY33ga/aqFE9CEaJl8BO6hVDO1iOWty/5ejbcOQpKthoFHRwVrB5jiVjAgTva4mXlMKvnLhNIcfhMHBzGXt9buKyckA/f6hc0oSYgWWz4a13/B8oH4lTO4b+5BkYu1LeU= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=c01a14439; MF=kepeng.lkp@alibaba-inc.com; NM=0; PH=DS; RN=2; RT=2; SR=0; Received: from 10.22.61.45(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Thu, 02 Jul 2015 07:28:22 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 02 Jul 2015 07:28:17 +0800 From: "Kepeng Li" To: Stefanie Gerdes , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Comments to the ACE use case document References: <5593E7E2.1010709@tzi.de> <559409CA.3040008@tzi.de> In-Reply-To: <559409CA.3040008@tzi.de> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] Comments to the ACE 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, 01 Jul 2015 23:28:36 -0000 Hi Steffi, Thanks for your feedback. My comments are inline. Another editorial one: "want=A1=B0 is missing in the sentence below. U6.4 Sports equipment owners to protect the confidentiality of their data for privacy reasons. Kind Regards Kepeng =D4=DA 1/7/15 11:39 pm=A3=AC "Stefanie Gerdes" =D0=B4=C8=EB: >Hi Kepeng, > >Thank you for your comments. > >On 07/01/2015 04:46 PM, Kepeng Li wrote: >> Hi Steffi, >>=20 >> Thanks for the feedback. >>=20 >> Please find my comments inline. >>=20 >> And I add another new comment: >>=20 >> Section 2.2, in case of renting a house, we should consider a new >> authorziation problem below: >>=20 >> U2.X The home owners want to grant access permissions to a party in a >> specified timeframe. >>=20 >>=20 >> We have U2.4 which talks about granting temporary access permissions, >>but >> to me, temporary usually means one-time permission, it is different from >> one year permission. > >I would think that temporary can also mean a one year permission, but I >guess we can just change U2.4 to "The home owners want to grant access >permissions to a party in a specified timeframe." OK. Fine with me. > >>=20 >> =D4=DA 1/7/15 9:15 pm=A3=AC "Stefanie Gerdes" =D0=B4=C8=EB: >>> >>> On 07/01/2015 12:45 PM, Kepeng Li wrote: >>>> >>>> 5) U1.10 The constrained devices might not always be able to reach >>>>the >>>> Internet. >>>> U5.5 The devices may have intermittent Internet connectivity. >>>> U7.3 Some devices do not have direct Internet connection. >>>> U7.4 Some devices have wired connection while others use wireless. >>>> About these four, it is not clear about the authorization problem. It >>>> is a >>>> condition. My suggestion is to change it to something like: Some >>>> devices do >>>> not have direct Internet connection, and can=A1=AFt get authorization >>>> decision in >>>> real time. >>> >>> But the devices might be able to get authorization decisions, just not >>>from a server somewhere in the Internet. They may have a local >>> Authorization Server or may even ask their users if they are available. >>=20 >> Maybe we need a better wording. My point is, we should make it clear, >>what >> is the authorization problem if the device does not have internet >> connection. >>=20 >> Something like: The devices need to be authorized even if the devices do >> not have direct Internet connection. > >But the problem at this point is that they don't always have the >Internet connection. How about: "The constrained devices might not >always be able to reach the Internet but still need to enact the >authorization policies of their principals."? OK, fine with me. > >>=20 >>> >>>> >>>> 6) 3.2 Configuration of Access Permission >>>> It is important to protect the authorization decisions not to be >>>>reused, >>>> stolen or intercepted. >>>> I suggest adding one bullet as a security consideration: The device >>>> should >>>> prove its possission of policy decisions when it presents them to >>>> Authorization Server. >>> >>> I don't really understand this comment. Can you elaborate that? >>=20 >> For example, I got the room key (authorization decision) from the hotel. >> But it is lost and picked up by Guest A. Guest A got my room key and >> entered my room. >>=20 >> We should aviod this situation to happen. So I propose the add one >> security consideration bullet above. > >I agree that we should avoid this to happen, but it seems to me that >this is a very specific implementation detail. There will be a lot of >requirements that solutions must meet, but the use cases document is not >about requirements. The items listed in 3.2, 3.3 and 3.4 derive from the >problem summary sections and just summarize them. Let me find an alternative proposal. > >>=20 >>> >>>> >>>> 7) 3.3. Design Considerations for Authorization Solutions >>>> I am not sure why this part belongs to Security Considerations. Should >>>> it be >>>> a separate section? >>> >>> Section 3.3. derives from the problem summary sections which problems >>> solution designers should consider. Doesn't that fit into a security >>> considerations section? Do you think that the contents don't fit or is >>> the heading a misnomer? >>=20 >> From the content, it talks about how to enforce and update ploicies, how >> to revoke decisions, usabilities, etc. It does not really fit into a >> security consideration. >>=20 >> It seems to me design considerations and security considerations should >>be >> in parallel sections. > >As I said above, the sections 3.2 and 3.3 and 3.4 are just summarizing >the problem summary sections. To make this a bit more understandable, we >divided the summary into three sections. It will be very difficult to >keep the focus of the draft (the listing of authorization problems) if >we have a distinct design consideration section. How about this, change the title to "Authorization Considerations=A1=B0? Then it sounds more like a security consideration. > >Best regards, >Steffi From nobody Tue Jul 7 03:12:43 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 A35161A884D for ; Tue, 7 Jul 2015 03:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 PpGZLw5S-6HO for ; Tue, 7 Jul 2015 03:12:39 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60FA1A1DBD for ; Tue, 7 Jul 2015 03:12:38 -0700 (PDT) Received: from VI1PR04MB0896.eurprd04.prod.outlook.com (10.161.106.16) by VI1PR04MB0863.eurprd04.prod.outlook.com (10.161.104.13) with Microsoft SMTP Server (TLS) id 15.1.213.14; Tue, 7 Jul 2015 10:12:22 +0000 Received: from AM3PR04CA0050.eurprd04.prod.outlook.com (10.242.16.50) by VI1PR04MB0896.eurprd04.prod.outlook.com (10.161.106.16) with Microsoft SMTP Server (TLS) id 15.1.207.19; Tue, 7 Jul 2015 10:12:21 +0000 Received: from AM1FFO11FD055.protection.gbl (2a01:111:f400:7e00::116) by AM3PR04CA0050.outlook.office365.com (2a01:111:e400:8814::50) with Microsoft SMTP Server (TLS) id 15.1.207.19 via Frontend Transport; Tue, 7 Jul 2015 10:12:21 +0000 Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from mail.philips.com (206.191.240.52) by AM1FFO11FD055.mail.protection.outlook.com (10.174.65.74) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Tue, 7 Jul 2015 10:12:20 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.87]) by DBXPRD9003HT001.MGDPHG.emi.philips.com ([141.251.25.206]) with mapi id 14.16.0488.000; Tue, 7 Jul 2015 10:12:19 +0000 From: "Kumar, Sandeep" To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-somaraju-ace-multicast-00.txt Thread-Index: AQHQuBnkwRuRd23Ux0ClPpHtNVFm353PyKrw Date: Tue, 7 Jul 2015 10:12:19 +0000 Message-ID: References: <20150706183041.15459.73558.idtracker@ietfa.amsl.com> In-Reply-To: <20150706183041.15459.73558.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.108] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD055; 1:GGqAJuMTKurQWBSADFTh/z0qYdZbONfI1jS2jDAYWa5N7hNCvssZFsOyrJkQadA/7ZX9aiPhEnuZHEN0ysKi07yWLfXv/lkzrKlNNXhlENhilrZW4dO/f3/ks8ZMigZedipUt3c3oU4xVEDY1qu3zQVnnGwMYP+bYxFViiPZ4Et29kiLBy/mGcRn8GGkn81lHNSoqzyWQDSdrk9WVMsgawNietn6/9O+ZgdDF1NLhh/hYjEKCmLSTyybG73dAXc98A+yYXK4FnvQVPqmekWgBw== X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(374574003)(199003)(85714005)(189002)(377424004)(13464003)(377454003)(50986999)(6806004)(62966003)(101416001)(2351001)(19580405001)(86362001)(54356999)(77156002)(76176999)(46102003)(33656002)(87936001)(2656002)(230783001)(55846006)(450100001)(102836002)(15975445007)(106466001)(110136002)(189998001)(107886002)(92566002)(66066001)(105586002)(104016003)(5001960100002)(2501003)(23676002)(106116001)(47776003)(19580395003)(2950100001)(50466002)(2920100001)(2900100001)(5003600100002)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB0896; H:mail.philips.com; FPR:; SPF:None; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB0896; 2:67NUOr8GKuE/dAn+i3OPUmfnvmdEpeAxW/+/W3JzqpkXqE76Iu87YiWmiJCocp//; 3:guPh9aZldue9y2vFFowK7FvSREpd+Ks7+TRD1ytXrrQsLcNQiquJphQP7dET4JMvGk3d+Yl2Cp+epiHyAKF1DfX+RyXOm0i8Z2yZz0aoWwAyCHLJdfOgNKnVTUkAE4i/HMVz0/ni8+A2SKwnyd4E6IzJRFadxsPdtuR04BpPqaVPfx/vyA5C7dKStUOhM4S4QS06PSLvVNeLC4ATu4kLo2o5bVdb91SR+6g56Llho2Ge8vUntdgTjS8dStnWyVtD; 25:GFfYS3C2v6Knnpw7P1jSpcuGazGwXJ6Tm7yhx10ZcTgbFdhDiIM23nLHDlhKCQ4dFuF9ALjehdstKf6BdshEFrbDO0F/YzunJiVN73SFKF8GoFbAnIdfuUm8VNh3cZS8fegNq/Z5To0ozYB5fBstypyvn24negli3kjge6tJz6cg/FT7KBoLpsFlQvBtGNx3byqcZOejMe/CsrXdFQHbvd3Vi3eU/4ml8WefwW94quJtnDnjG1BZq9j1ksEfOuxKVXBBPt8I9HcdMi1X/Gwivw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB0896; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB0863; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB0896; 20:dtwJ7FVpnvTYro2KahPEO6jwr5QWH+Z0oF2cVedpomt14vfAhPKTkuxHGhdc0Qebp3krAvl4fGtRP1UGLIXcIbF35DnNlrszyegKwFs7WxLb89DnNnuZCn3aKorLfqxl4r9TTHUbAWkDOJKZsDf2KT2lZrJLNtce+ipO8zh8/2y1+1gfTRNqQ9cvZ33M6jZZAA53xZv9o/cOPYijFavkZl2LjqSGiXwDxY5zNoX4KdMsTiVG0UZoh39fjVVo8pn2eJAp7LH/WKUqvOPNLkxeh8y6l/Afma945iE2RmCiJU64NwiBdDESIcGyrEeRPfxMbdnSKt72Suhh+HnkA6Z7VYocLNpPYgeLiqlHfS77z1XHNOYMRaAowL1hwsLrPG7hiXydWhr6pcNlpFcozsEDAfsrRZU8/UCDEskRNqxAO1WJfnnAJda/BpECTtMlp2BT0bVnWHm6sfAr515Uc0BnDvN9bhrW3m/+lBIYWqGJHf4mmNB9X2kwvUAgnLBsnvUd; 4:F+Z4pyulgdp5mcJKRTOjM4DXeA/TXkZvYG0yVZNDG+wTEHDKmGTK1nEdh+xSnuGYkX1rFL7ppKAF7OKHgqs4xvJuvYlibgwRbxk9ME73+cy0XViGF04JUOpHVYC9x0eXXjFrjsftEPMpQ/j7Wor33VVOsIBpkkjAngb89afVIVtjGOp7yGVaA+8lJYoZdupo65y9Qf3c44H+TZU/+5yBBUIv2QpvqEFIxr4xqmSQdv7RjhDFicffjS0nsYPOicclNGO2xy2zBJBvxN8AbIoGuk9KmF01EY+7rrfZ1GisN0s= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:VI1PR04MB0896; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB0896; X-Forefront-PRVS: 0630013541 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA0TUIwODk2OzIzOlYvLzNuNXVHRis5SjFPVTRET2QxeU9TdUdK?= =?utf-8?B?Y2dSbS9uUjNhKzdvUFV0U1M5K0kxU2daVHF3Nk5pRm9MS3lGNC8rSlFxa21S?= =?utf-8?B?VTVBdDNJSkdUVHZQVDNiaXRpU1QyWVdOS1VuZWcwTDFpYjhydS9CZGJGdmJL?= =?utf-8?B?ZzhwSWhMaEtySU5XRWQ1M0FsaWdxQXFIZU50OVU0T2hHeUJ0Y1E1MDQ0SitD?= =?utf-8?B?Zk4xSWZHbVlTTnYrV0k0THh0YUhUQTBoZXFzc0FOL016NHZiMFpFdHIzRGNr?= =?utf-8?B?bHJwNG5VVDV4MzdXMGRzNHVwa0ZmYVBWVFBobEpER1FabmRibkUzVEVTOXdD?= =?utf-8?B?NE9mQmxWS1VlZmFRaEEzZ3NSODk5WDB1RTlTWGxMbzhJT0dEMCsyaDJkSis3?= =?utf-8?B?cEZIK0F2Y3hlSDRVRytOYVZYZ2FmUk9kUW9jTnNDQm9rdVY3NTZqK0x1Wk84?= =?utf-8?B?WHhiZHU3VDNGamJyM3cwSUVFOWUwbXpRMVJ1SGNPdjcrZkF2K001NlpSUnZR?= =?utf-8?B?enBuRTI4NHlmSEF1b2R3MmxPTjh6OURQYWFUN0xweWViRG9CZ1lVa0JwbFk3?= =?utf-8?B?VUUyM2ExTzkvYXFEZzJRKzFMNWNlSVpuWk54V25aV04xVzN2SHZLTVh3SnJV?= =?utf-8?B?TUtCTTREcTJZNHVwaGNlVzhBb2pKaW1jMzJ3OGE0eU1mYTFIakwwYlVpV0g2?= =?utf-8?B?cFMwNEpqSGVVU0RKRVBuMWlzd3NmVkJuSDJBT1NSMHJBdGtTaVV1STAvSWxp?= =?utf-8?B?bU45bDZyK2tkclNNaHNDZVppekJoTU90ZGJNbi9TNEg0MGNuY1lmQ1l5bGRp?= =?utf-8?B?amhHbGhUMVlKcHpOQ2o1Z3hCbnQ2Z2ZCckZoVU9DaGd6UWtseFlrbXhTbGd5?= =?utf-8?B?c1VIMlZwSUE1R1FBVHlyOWZhS01ScW4vQVZjMzY5WS8xczlNZVNyUFQwaHZ4?= =?utf-8?B?OFNHYTk0MG5HS1U3S2Nyc3J0YmZyTHdnQVRjRkpEMHE4RTVUQzBtOEtNL3k2?= =?utf-8?B?YlZub2l1RTBMZ0VORkpYRTlIZ3RIY0wyZ3l0blJiUDYrYnpqUlZxU0QwUE1D?= =?utf-8?B?Y0Mwb1kvYS9hSEtDN0cyK005ckgrOW96UncyMGFQQUM3Y2hmYUZrQ2VvbVVi?= =?utf-8?B?TTdtdDc3V3ZQNHVyN3ZhVWx3VlIyVnFxaUxOM3p0b3pUYmFVNS9CMTRxajZX?= =?utf-8?B?bnA3NUpMb2pnRWlIQUdFN1RnY0w1anJoZFFTeWJPRi9FZUtMQnJSTzhnVVgr?= =?utf-8?B?M2Z0N3J4VWZrQy9YM2Z1cjNVQmtTSzFqZUNmUXUxdm4xc2p6YjFWQzYwYXRj?= =?utf-8?B?SGRsbFJCVERqU0QzaHhzSmgrWGpMclNZa1R3a0pQbjlUNHlsWDFUa1M2eTZO?= =?utf-8?B?UE5jeExCYktrNHEvMWVOQzRITFFyUFg5NmErVUNFMkVIS1BXbThHYXJsa1k3?= =?utf-8?B?UnJWUUo1SWJLQWw2bDJyYUVLOXRMc1plbW9TZkV3ZUQ5NUM2YmEwVXdXN2Ni?= =?utf-8?B?SnZFNlNuYUtCWC9jODRZWlg5QWtvRjlsYXF5NHdmUFR3WFlQSDBhdWc3MUlu?= =?utf-8?B?STcxMGNNTUZDQ3M3eDFTQ0J0SHhKNkp0VVF5Zmg3NkRCeDFnZEdITHdlZ2dv?= =?utf-8?B?Ymt4Y0wxNUpQS0NWMkwyVzZOQUs4V3VSVThRZ3lwTmlZQ1ZWbmRoOUwza0pS?= =?utf-8?Q?lEHKu0P2bZb9HwwXhM=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB0896; 5:JcNk12zOR5rs+0yLogeiDxGvP+tCD7MtzPN3fxghQpqjwxsiUQ/+ofnIGg3A4/VqbYs9Sof10XsxrqK5Z9U1I0RNMaXlsTcSz04ZqxJxvRVpTVB1rb7hJo74HV5DhBSpVty2v1VbMKWKmg36oG9/wA==; 24:QDCqchjzhrQvSuzqGVuthj5Iyd3tjZVman+U1hbXlHZ4t5FasvZfZIZmZpu+bvXyL/fmzk16EgDXhn/p8bhQJZE+8U3GDd0D8Yfi+s2tjh0=; 20:iNMOs2Ts6OGvbXXLmLLmwn6OtoOKhJsCPM3cvGYywdJxUp/txMyrw2ZkQtha257opmoiajqa8ySanip63Dp2hw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2015 10:12:20.4417 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[206.191.240.52]; Helo=[mail.philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB0896 X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB0863; 2:UcPOYBIug3QajaQ7aVngtWYGmhxG5QJ7tdY/q5l4oRwtey98eQ/32MO7Nvq5lz3M; 3:EYZFJyujgUn1VILkyNDgbhfJOJNAhyeh2hM2YChha0cMThnmKS0Rl6M2B53UdzTGlmNKY0o7jzNAog5kpJkWt9i03dFgwCuwANT1iY6Acr1SJ1QboWPkuQNOzGFJaRJOPaK9Wa2GiqFlo9JDxYA7I4n0WyyR43UBxusp1VvA2M44xANp+yritoNFnwHYr1W2w6KFrKr9Adh25GMgsiCxa4M5wSRVrilkg7xujopAXk+9QTd7U5/hLb2EIKkGz+Y1; 25:rKMyZz61F7EKhZtw/b0pv/kEYJiLq62eePeSzkVMpTJzFBKSzZrlaHLDblAnM01XJrflcqLdynHjv0e2m3xCfRSvSM3H1XFuERDkI16Bny0tC0P+P4cy6UmJqjFkVw31HTLmpM6jRvF/HgLU+axLpnoVtJjThK/CvLqq5tmBztlGgW8BC7u0bagWr0/vkgC6XfvkvlhM+z1E7Vo8H9+U9gpzS46UrUngaxRRlFWNhTCCuXfAWP+wGjad/+mCr5vuoTX12x8/n0T8kjCe2YE77g==; 23:lRLrdCy4MjiAQJLdk/25T4+LhGKxMLc2GWwUq32ype/PdnxwdUOl2heImlPE9vDtm/OMcAk72K6EI0jtlHlsNEcD2Ff84NrgxSVhXEzoQL3N0RdhRtzIpYEpAWuCUvJ9l/tvm3+RyHmOSyy+ktBqhCliSzsajhUcvEP4kfi79jr4oA8F38kPJW6kVck7kyeucpSApIltaV1W5i+sBG0lhseIkOgHtEQNzbenPzQl8+z0O1ukQcpjiv0tiqQ6u8cG X-OriginatorOrg: philips.com Archived-At: Subject: [Ace] FW: New Version Notification for draft-somaraju-ace-multicast-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: Tue, 07 Jul 2015 10:12:41 -0000 RGVhciBhbGwNCg0KV2UgdXBsb2FkZWQgYSBuZXcgZHJhZnQgd2l0aCBkZXRhaWxzIG9uIHRoZSBh dXRob3JpemF0aW9uIGZsb3cgd2l0aGluIGEgcHJvZmVzc2lvbmFsIExpZ2h0aW5nIHN5c3RlbXMg KHdoaWNoIGlzIG9uZSBvZiB0aGUgdXNlIGNhc2VzIGluIHRoZSB1c2UgY2FzZSBkcmFmdCkuDQoN CkNhbiB0aGUgY2hhaXJzIGFsbG9jYXRlIHRpbWUgdG8gZGlzY3VzcyB0aGlzIGF0IHRoZSBQcmFn dWUgbWVldGluZy4NCg0KUmVnYXJkcw0KU2FuZGVlcA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXQ0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDg6MzEgUE0NClRvOiBB YmhpbmF2IFNvbWFyYWp1OyBBYmhpbmF2IFNvbWFyYWp1OyBTYW5kZWVwIFMuIEt1bWFyOyBIYW5u ZXMgVHNjaG9mZW5pZzsgSGFubmVzIFRzY2hvZmVuaWc7IFNhbmRlZXAgUy4gS3VtYXINClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc29tYXJhanUtYWNlLW11bHRp Y2FzdC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc29tYXJhanUtYWNl LW11bHRpY2FzdC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWJo aW5hdiBTb21hcmFqdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 ICAgICAgICAgICBkcmFmdC1zb21hcmFqdS1hY2UtbXVsdGljYXN0DQpSZXZpc2lvbjogICAgICAg MDANClRpdGxlOiAgICAgICAgICBNdWx0aWNhc3QgU2VjdXJpdHkgZm9yIHRoZSBMaWdodGluZyBE b21haW4NCkRvY3VtZW50IGRhdGU6ICAyMDE1LTA3LTA2DQpHcm91cDogICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMjINClVSTDogICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc29tYXJhanUtYWNlLW11bHRp Y2FzdC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zb21hcmFqdS1hY2UtbXVsdGljYXN0Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zb21hcmFqdS1hY2UtbXVsdGljYXN0LTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBMaWdodGluZyBzeXN0ZW1zIGhhdmUgc3RyaWN0IHJlcXVpcmVtZW50 cyBvbiBtZXNzYWdlIGxhdGVuY3kgYW5kDQogICBzeW5jaHJvbml6YXRpb24gKHR5cGljYWxseSBs YXRlbmN5IGxlc3MgdGhhbiAyMDAgbXMgYW5kIGppdHRlciBsZXNzDQogICB0aGFuIDUwIG1zKS4g IFRoZXJlIGFyZSBzZXZlcmFsIGxpZ2h0aW5nIHVzZSBjYXNlcyB0aGF0IHJlcXVpcmUNCiAgIHNl Y3VyaW5nIHN1Y2ggY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGEgKGdyb3VwIG9mKSBzZW5kZXJzIGFu ZCBhIGdyb3VwDQogICBvZiByZWNlaXZlcnMuICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyBpbml0aWFs IGlkZWFzIGZvciBhdXRob3JpemF0aW9uDQogICBhbmQga2V5IG1hbmFnZW1lbnQgcmVxdWlyZWQg Zm9yIHRoZSBzZWN1cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiB3aXRoaW4NCiAgIGEgbGlnaHRpbmcg c3lzdGVtLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRp YWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMg bWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5h bCBtZXNzYWdlLg0K From nobody Wed Jul 8 03:45:19 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 1FFCD1B3439 for ; Wed, 8 Jul 2015 03:45:18 -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 wc2rqP05B_AX for ; Wed, 8 Jul 2015 03:45: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 01CCA1B343D for ; Wed, 8 Jul 2015 03:45:15 -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 t68Aj51I016588; Wed, 8 Jul 2015 12:45:06 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:4c7:f948:fd9a:8102] (unknown [IPv6:2001:638:708:30da:4c7:f948:fd9a:8102]) (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 3mRHMj45Mmz3GJb; Wed, 8 Jul 2015 12:45:05 +0200 (CEST) Message-ID: <559CFF31.4070201@tzi.de> Date: Wed, 08 Jul 2015 12:45:05 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <20150706230021.15054.17580.idtracker@ietfa.amsl.com> In-Reply-To: <20150706230021.15054.17580.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150706230021.15054.17580.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Hannes Tschofenig , Kepeng Li Subject: [Ace] Fwd: New Version Notification for draft-gerdes-ace-dcaf-examples-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: Wed, 08 Jul 2015 10:45:18 -0000 Hi all, we submitted a draft that will list examples for using DCAF with well-known protocols on the less constrained level. We started with an example that illustrates how DCAF can be used with OpenID Connect. Please refer to the PDF version [1] for illustrations. We would like to present this draft during the ACE Meeting in Prague. Could the chairs please reserve a slot for us? Thanks, Steffi [1] https://tools.ietf.org/pdf/draft-gerdes-ace-dcaf-examples-00.pdf -------- Forwarded Message -------- Subject: New Version Notification for draft-gerdes-ace-dcaf-examples-00.txt Date: Mon, 06 Jul 2015 16:00:21 -0700 From: internet-drafts@ietf.org To: Dr. Carsten Bormann , Stefanie Gerdes , Olaf Bergmann , Stefanie Gerdes , Olaf Bergmann , Carsten Bormann A new version of I-D, draft-gerdes-ace-dcaf-examples-00.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-gerdes-ace-dcaf-examples Revision: 00 Title: Examples for Using DCAF with less constrained devices Document date: 2015-07-06 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-gerdes-ace-dcaf-examples-00.txt Status: https://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-examples/ Htmlized: https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00 Abstract: Constrained nodes are devices which are limited in terms of processing power, memory, non-volatile storage and transmission capacity. Due to these constraints, commonly used security protocols are not easily applicable. Nevertheless, an authentication and authorization solution is needed to ensure the security of these devices. The Delegated CoAP Authorization Framework (DCAF) specifies how resource-constrained nodes can delegate defined authentication- and authorization-related tasks to less-constrained devices called Authorization Managers, thus limiting the hardware requirements of the security solution for the constrained devices. To realize the vision of "one Internet for all", constrained devices need to securely establish trust relationships with less constrained devices. This document lists examples for using DCAF with less constrained devices. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 9 00:02: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 2E4451AC3E2 for ; Thu, 9 Jul 2015 00:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9ijyMuFA8iJN for ; Thu, 9 Jul 2015 00:02:08 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C8A1AC3E1 for ; Thu, 9 Jul 2015 00:02:08 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud6.xs4all.net with ESMTP id q7251q00X4d84Ai01725kV; Thu, 09 Jul 2015 09:02:05 +0200 Received: from [2001:983:a264:1:89da:b3b9:129f:fe68] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 09 Jul 2015 09:02:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Jul 2015 09:02:05 +0200 From: peter van der Stok To: "Kumar, Sandeep" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20150706183041.15459.73558.idtracker@ietfa.amsl.com> Message-ID: <55b5744f556c20e03e2d9c128ba07e91@xs4all.nl> X-Sender: stokcons@xs4all.nl (E9qGvbJtnkOGA+uSRhYCvT0vNtZ1trIX) User-Agent: XS4ALL Webmail Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] FW: New Version Notification for draft-somaraju-ace-multicast-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org 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 Jul 2015 07:02:11 -0000 Hi Authors, I am pleased to see that solutions to provide multicast security are being pursued in this draft. Let me encourage you to continue work on multicast security. Below are some high-level remarks to improve the readability and purpose of the document (at least to me) - Can the draft make more clear how it contributes to the meeting of the 200 ms deadline. (point 3 of the introduction) - There is a large section on access levels, but the concept is very little used in the text. - It is only in section 4 that I see the concrete contributions of this draft: Key Distribution center, and Authorization server (are these indeed the topics of this draft?) - The example section 6 provides a lot of information on the LWM2M model, which I find distracting from the actual subject. Hope this helps. Peter Kumar, Sandeep schreef op 2015-07-07 12:12: > Dear all > > We uploaded a new draft with details on the authorization flow within > a professional Lighting systems (which is one of the use cases in the > use case draft). > > Can the chairs allocate time to discuss this at the Prague meeting. > > Regards > Sandeep > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 06, 2015 8:31 PM > To: Abhinav Somaraju; Abhinav Somaraju; Sandeep S. Kumar; Hannes > Tschofenig; Hannes Tschofenig; Sandeep S. Kumar > Subject: New Version Notification for > draft-somaraju-ace-multicast-00.txt > > > A new version of I-D, draft-somaraju-ace-multicast-00.txt > has been successfully submitted by Abhinav Somaraju and posted to the > IETF repository. > > Name: draft-somaraju-ace-multicast > Revision: 00 > Title: Multicast Security for the Lighting Domain > Document date: 2015-07-06 > Group: Individual Submission > Pages: 22 > URL: > https://www.ietf.org/internet-drafts/draft-somaraju-ace-multicast-00.txt > Status: > https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/ > Htmlized: > https://tools.ietf.org/html/draft-somaraju-ace-multicast-00 > > > Abstract: > Lighting systems have strict requirements on message latency and > synchronization (typically latency less than 200 ms and jitter less > than 50 ms). There are several lighting use cases that require > securing such communication between a (group of) senders and a group > of receivers. This draft describes initial ideas for authorization > and key management required for the secure group communication > within > a lighting system. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jul 9 00:42:46 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 BDA981AC44D for ; Thu, 9 Jul 2015 00:42:44 -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 izjg5f0thTny for ; Thu, 9 Jul 2015 00:42:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 433781AC44E for ; Thu, 9 Jul 2015 00:42:42 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.246]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lfppu-1Yfgay3rb8-00pJRo; Thu, 09 Jul 2015 09:42:39 +0200 Message-ID: <559E25DB.2060709@gmx.net> Date: Thu, 09 Jul 2015 09:42:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: consultancy@vanderstok.org, "Kumar, Sandeep" References: <20150706183041.15459.73558.idtracker@ietfa.amsl.com> <55b5744f556c20e03e2d9c128ba07e91@xs4all.nl> In-Reply-To: <55b5744f556c20e03e2d9c128ba07e91@xs4all.nl> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ombO05lMv5bT5PSr4APPTH9cMTFLv6jd5" X-Provags-ID: V03:K0:vdHm/+HsrjqWeUhmZA9m66NMHHN4lqg02Nk2oX3tB+uTQqzDEf1 34tq7ScQhes8nOuS/tw+u+o7HQoXtQ06ByU2lwHWI8QjHLsWEkWgfPofw1s/q4Wj5WyE/Ds LZhP/hEj7OZA7yD6JJOE/3iXpBONRRTTok5wsfcMHTr1DMa2d0WCanB52/uSAOqJNGUH7MC QpHwf5BZjdwpDUKUWgGng== X-UI-Out-Filterresults: notjunk:1;V01:K0:soOyDRfQKZc=:BvPjcKw9Bq/io40ABabUFk 3kVSizqUqTUUNNQKc4ZS+/HEpgfpqMolz3XLt34wWjZoCxfEndjL1IqK+31uoxbek7rGxNxk/ BrDrkZN8xwbp4lVTyEpju34ANXgIpfmVfMEThRTzBjYmJwUoJiAZ/3ThNXo+BGD4bLV3WtNAi 9n4WQqrOQgzJ2qKWJ97pwS/w9rL+eZ3iqKbL5Ze4uoWS8runXx/jx5gqquMG8FHhdeKAmW/Xe NNJArMWJg4WtgcjWL3lYg5RWoSJ9tMYQ1ehoOEQ5jf0/ELEyVUlqle1Yim9Cv/UGeviDmgbZm kHcUDVc3bDT7rHADpCbDyDaB/wEPw3okwRka+8uTvzIKQb9hX/c2y+Tn6AqYqRnH4Im3k3n7D eUsmmk2m29Oe00tehJfXvn4Hr169P7DnG79eWwYWUy1kihu5CBGbSbSgPMap7rI1/sPx5TBv9 LEtH41oFqYvUgORe1JWnBwqujOg7vGnq7cNWTC2P7d8EFPVp9CVTYyBrCq7K1aqME7v4xXg37 fwVnMlFRqBlhatlx8doabSzHLw8jPivOrAHC7maJ0KYgxOAvElyuM+7AoKf2WplZgGU+UBTJ0 RGgGL+N/oKpq/0V64CBm3LDg4qgom/rqFPiesrY7NgiPYzUnb3BhsNG/0q9BWs9HIupaqBkGD DcfHou3zMg/Xo5LQPO2Dl6bwTwJu9OlxZU4FFfXqsdEOnuA== Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] FW: New Version Notification for draft-somaraju-ace-multicast-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: Thu, 09 Jul 2015 07:42:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ombO05lMv5bT5PSr4APPTH9cMTFLv6jd5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter, thanks for your quick review. On 07/09/2015 09:02 AM, peter van der Stok wrote: > Hi Authors, >=20 > I am pleased to see that solutions to provide multicast security are > being pursued in this draft. > Let me encourage you to continue work on multicast security. >=20 >=20 > Below are some high-level remarks to improve the readability and purpos= e > of the document (at least to me) >=20 > - Can the draft make more clear how it contributes to the meeting of th= e > 200 ms deadline. (point 3 of the introduction) The requirement for the low latency motivates the use of multicast rather than using unicast to individually control luminaries. > - There is a large section on access levels, but the concept is very > little used in the text. We tried to move the authorization related aspects into one section. =46rom a protocol point of view the impact is (by design) minimal and onl= y impacts the content of the access tokens. > - It is only in section 4 that I see the concrete contributions of this= > draft: Key Distribution center, and Authorization server (are these > indeed the topics of this draft?) Section 4 provides the architecture and in Section 5 we offer additional detail the access token, which is core to the entire concept. The proposed architecture separates the key distribution part from the authorization part into two logical entities. We believe that this separation makes sense since the authorization server may not be present all the time, particularly not in small enterprise environments. > - The example section 6 provides a lot of information on the LWM2M > model, which I find distracting from the actual subject. In Section 6 we tried to provide an example exchange. We re-use the information model of IPSO for the examples, which happens to re-use the URI encoding of OMA LWM2M. We thought it would make sense to reference some existing work rather than inventing a new information and data model. Ciao Hannes >=20 > Hope this helps. >=20 > Peter >=20 > Kumar, Sandeep schreef op 2015-07-07 12:12: >> Dear all >> >> We uploaded a new draft with details on the authorization flow within >> a professional Lighting systems (which is one of the use cases in the >> use case draft). >> >> Can the chairs allocate time to discuss this at the Prague meeting. >> >> Regards >> Sandeep >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, July 06, 2015 8:31 PM >> To: Abhinav Somaraju; Abhinav Somaraju; Sandeep S. Kumar; Hannes >> Tschofenig; Hannes Tschofenig; Sandeep S. Kumar >> Subject: New Version Notification for draft-somaraju-ace-multicast-00.= txt >> >> >> A new version of I-D, draft-somaraju-ace-multicast-00.txt >> has been successfully submitted by Abhinav Somaraju and posted to the >> IETF repository. >> >> Name: draft-somaraju-ace-multicast >> Revision: 00 >> Title: Multicast Security for the Lighting Domain >> Document date: 2015-07-06 >> Group: Individual Submission >> Pages: 22 >> URL: >> https://www.ietf.org/internet-drafts/draft-somaraju-ace-multicast-00.t= xt >> Status: =20 >> https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/ >> Htmlized: =20 >> https://tools.ietf.org/html/draft-somaraju-ace-multicast-00 >> >> >> Abstract: >> Lighting systems have strict requirements on message latency and >> synchronization (typically latency less than 200 ms and jitter less= >> than 50 ms). There are several lighting use cases that require >> securing such communication between a (group of) senders and a grou= p >> of receivers. This draft describes initial ideas for authorization= >> and key management required for the secure group communication with= in >> a lighting system. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely= >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. >> _______________________________________________ >> 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 --ombO05lMv5bT5PSr4APPTH9cMTFLv6jd5 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 iQEcBAEBCgAGBQJVniXbAAoJEGhJURNOOiAtLhQH/3G+W9cgnsw36MtO4mjS/jZa /PT4QWySbz7wpNf/2LdIEVRCKom21YO86wZidGClivg8W2fCVN244rXqk/cw0K7x O39V0Veki1ldQfLwxEf/ob+t1PVBkcTuH1WLe2JCSFC7psB5uB9Tjw9oif7mgjyV O09cOPa6Mk7jfNwgkRZpbcwmJ0EWIp9vNc/vEgkxeEFwwooVl2e4QnsdWCqxKaA5 9yRGf0JauKXEdmKQtUbes3bAJCy8Z17MTaqXXZg+cf0/bBskMTM46NGJFqxBwdhO gnq18Buv5X11F4e5nGBHopAslqFGpNlKIeCLQrPSk0E83iHK4Vgx0y0n6liC7lI= =ta4S -----END PGP SIGNATURE----- --ombO05lMv5bT5PSr4APPTH9cMTFLv6jd5-- From nobody Thu Jul 9 09:10:05 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 341E21A0021 for ; Thu, 9 Jul 2015 09:10:04 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KTKFdf_9rgdS for ; Thu, 9 Jul 2015 09:10:02 -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 D09AC1B2A54 for ; Thu, 9 Jul 2015 09:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1436458200; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=072+dmzQCtLJqEwo6Tz5qphApm4wPmOvivfLCUet8nI=; b=ozsMHeNCfoBJxf+20yghTCeAXG0EGZRq+basT9iLwbq4YiTxD19S5w1rg9yeHCaiQlm74dsCG5F1uJqVFT23JT8a/D1rgNYl6jvs1xVH2r7vYIDSf4YvFDoyylt3Tk2PYKvCELhEs5soZuEtaaOUgTELm/rbdDBBRPDYBRLteV8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03286; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.39.206(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2015 00:09:58 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 10 Jul 2015 00:09:56 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: ACE agenda for Prague Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3519331799_2860098" Archived-At: Subject: [Ace] ACE agenda for Prague X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 16:10:04 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3519331799_2860098 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hello all, Please find the initial agenda: https://www.ietf.org/proceedings/93/agenda/agenda-93-ace Thanks for your inputs. Kind Regards Kepeng & Hannes ---------------------------------------------------------------------------- ----------------------- ACE WG Meeting IETF 93 - Prague Wednesday 22 July 2015, 9:00 - 11:30 CDT Chairs: Kepeng Li, Hannes Tschofenig * Agenda Bashing (Chairs, 5 min) * Use Cases (Ludwig Seitz, 10 min) - http://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ * Public Safety Use Case (Akbar Rahman, 10 min) - http://datatracker.ietf.org/doc/draft-rahman-ace-public-safety-use-case/ * Actors (Stefanie Gerdes, 10 min) - http://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ * Authorization for Constrained RESTful Environments (Ludwig Seitz, 20 mins) - https://datatracker.ietf.org/doc/draft-seitz-ace-core-authz/ * DCAF Examples (Stefanie Gerdes, 20 min) - http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/ - http://www.ietf.org/id/draft-gerdes-ace-dcaf-examples-00.txt * Multicast Security (Sandeep S. Kumar, 20 min) - https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/ * OAuth and UMA (Hannes Tschofenig, 20 min) - https://www.ietf.org/id/draft-maler-ace-oauth-uma-00.txt * Simplified Key Exchange (Thomas Hardjono, 20 min) - https://www.ietf.org/id/draft-hardjono-ace-fluffy-01.txt * Privacy-Enhanced Tokens (Jorge Cuellar, 10 min) - https://www.ietf.org/id/draft-cuellar-ace-pat-priv-enhanced-authz-tokens-00. txt * Wrap-up (Chairs, 5 min) --B_3519331799_2860098 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hello all,

<= div>Please find the initial agenda:

Thanks for your inputs.
=

Kind Regards
Kepeng & Hannes
----------------------------------------------------------------= -----------------------------------
ACE WG Meeting
= IETF 93 - Prague
Wednesday 22 July 2015, 9:00 - 11:30 CDT
Chairs: Kepeng Li, Hannes Tschofenig

* Agenda Bas= hing (Chairs, 5 min)

* Use Cases (Ludwig Seitz, 10 = min)
- http://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

* Public Safety Use Case (Akbar Rahman, 10 min)
=
- http://datatracker.ietf.org/doc/draft-rahman-ace-public-safety-use-ca= se/

* Actors (Stefanie Gerdes, 10 min)
- = http://datatracker.ietf.org/doc/draft-gerdes-ace-actors/

* Authorization for Constrained RESTful Environments (Ludwig Seitz, 20= mins)
- https://datatracker.ietf.org/doc/draft-seitz-ace-core-aut= hz/

* DCAF Examples (Stefanie Gerdes, 20 min)
=
- http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/
- http://www.ietf.org/id/draft-gerdes-ace-dcaf-examples-00.txt

* Multicast Security (Sandeep S. Kumar, 20 min)
= - https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/
<= br>
* OAuth and UMA (Hannes Tschofenig, 20 min)
- https:= //www.ietf.org/id/draft-maler-ace-oauth-uma-00.txt

= * Simplified Key Exchange (Thomas Hardjono, 20 min)
- https://www.= ietf.org/id/draft-hardjono-ace-fluffy-01.txt

* Priv= acy-Enhanced Tokens (Jorge Cuellar, 10 min)
- https://www.ietf.org= /id/draft-cuellar-ace-pat-priv-enhanced-authz-tokens-00.txt

* Wrap-up (Chairs, 5 min)
--B_3519331799_2860098-- From nobody Thu Jul 9 09:10: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 60D511B2A54 for ; Thu, 9 Jul 2015 09:10:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tJQeM_8QubAv for ; Thu, 9 Jul 2015 09:10:48 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB221A0127 for ; Thu, 9 Jul 2015 09:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1436458246; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=nmUe5PLZbhTRYhKnLXWt6mql5rV4pEpMydiXyjYZFfU=; b=DNjqSYR7izKYoaTNvCauwokn1EDh59hIMoJAGGW8JO/A7OhT3qqurPeD49MRES1IMungEZlwV1HGvmarXRvhF3FGueL6GZgHTWhUoNlJL2jb/9WSJFClwgsEwYavqGTauQz3+1bOxJ+eX/P5prOVs0uTzQbGjhtFkxFbNZuEXqc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03291; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.39.206(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2015 00:10:35 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 10 Jul 2015 00:10:31 +0800 From: "Kepeng Li" To: Ludwig Seitz , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Fwd: New Version Notification for draft-selander-ace-object-security-02.txt References: <20150629135808.16942.95770.idtracker@ietfa.amsl.com> <5591742B.8070105@sics.se> In-Reply-To: <5591742B.8070105@sics.se> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-selander-ace-object-security-02.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: Thu, 09 Jul 2015 16:10:49 -0000 Hi Ludwig, > This might be relevant for CoRE as well. We are therefore unsure where to present this at IETF 93. What do the chairs think? It is already on the COSE agenda, and hopefully will be on the CoRE agenda. We don=A1=AFt see too much changes on the ACE part. Given that we have a quite full agenda in ACE, so we don=A1=AFt include it on the ACE agenda. Kind Regards Kepeng =D4=DA 30/6/15 12:36 am=A3=AC "Ludwig Seitz" =D0=B4=C8=EB: >We have uploaded an update of our object security draft, taking into >consideration the developments around COSE and including considerations >on Blockwise Transfer (as requested at IETF 92). > >This might be relevant for CoRE as well. We are therefore unsure where >to present this at IETF 93. What do the chairs think? > >Regards, > >Ludwig > >-------- Forwarded Message -------- >Subject: New Version Notification for >draft-selander-ace-object-security-02.txt >Date: Mon, 29 Jun 2015 06:58:08 -0700 >From: internet-drafts@ietf.org >To: John Mattsson , Francesca Palombini >, John Mattsson >, Ludwig Seitz , Goran >Selander , Goeran Selander >, Francesca Palombini >, Ludwig Seitz > > >A new version of I-D, draft-selander-ace-object-security-02.txt >has been successfully submitted by Francesca Palombini and posted to the >IETF repository. > >Name: draft-selander-ace-object-security >Revision: 02 >Title: June 29, 2015 >Document date: 2015-06-29 >Group: Individual Submission >Pages: 43 >URL:=20 >https://www.ietf.org/internet-drafts/draft-selander-ace-object-security-02 >.txt >Status:=20 >https://datatracker.ietf.org/doc/draft-selander-ace-object-security/ >Htmlized:=20 >https://tools.ietf.org/html/draft-selander-ace-object-security-02 >Diff:=20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-selander-ace-object-security-02 > >Abstract: > This memo presents OSCOAP, a scheme for protection of request and > response messages of the Constrained Application Protocol (CoAP), > using data object security. > >=20 > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jul 9 09:12:57 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 A2E621B2ABF for ; Thu, 9 Jul 2015 09:12:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 J7VWhySYNcO0 for ; Thu, 9 Jul 2015 09:12:55 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id 18D1D1B2A54 for ; Thu, 9 Jul 2015 09:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1436458373; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=4NZ28icMj9Pv4d2aT5wAlb0A18L5nvloGsC/SAKJSKo=; b=dTNBLJjEtvTbXE2N/eTDlSM9KrS2EGEDWYmueYpdet0WZdYC6MSyRTLG7jZ8DYPdngciqgYoF1xXlXM0K8uwDX8lKx8poR2Cu/oTK07mbDfn5n/XMLho28TbWK6+BYZYFQONuwBdWFrO8hAw35XVZD74XPDKeMnso9lLElahdRs= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03286; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.39.206(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2015 00:12:45 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 10 Jul 2015 00:12:38 +0800 From: "Kepeng Li" To: Ludwig Seitz , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Fwd: New Version Notification for draft-seitz-ace-core-authz-00.txt References: <20150629162754.30862.72458.idtracker@ietfa.amsl.com> <55917372.2010001@sics.se> In-Reply-To: <55917372.2010001@sics.se> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-seitz-ace-core-authz-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: Thu, 09 Jul 2015 16:12:56 -0000 > We would like a slot to present this draft in Prague at the ACE session. It is on the agenda now. Thanks, Kind Regards Kepeng =D4=DA 30/6/15 12:33 am=A3=AC "Ludwig Seitz" =D0=B4=C8=EB: >We have submitted a new draft describing an authorization scheme for >CoRE using RESTful authorization resources. > >@Chairs: We would like a slot to present this draft in Prague at the ACE >session. > >Regards, > >Ludwig > >-------- Forwarded Message -------- >Subject: New Version Notification for draft-seitz-ace-core-authz-00.txt >Date: Mon, 29 Jun 2015 09:27:54 -0700 >From: internet-drafts@ietf.org >To: Goeran Selander , Ludwig Seitz >, Goran Selander , Ludwig >Seitz , malisa.vucinic@st.com , >Malisa Vucinic > > >A new version of I-D, draft-seitz-ace-core-authz-00.txt >has been successfully submitted by Ludwig Seitz and posted to the >IETF repository. > >Name: draft-seitz-ace-core-authz >Revision: 00 >Title: Authorization for Constrained RESTful Environments >Document date: 2015-06-29 >Group: Individual Submission >Pages: 28 >URL:=20 >https://www.ietf.org/internet-drafts/draft-seitz-ace-core-authz-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-seitz-ace-core-authz/ >Htmlized: https://tools.ietf.org/html/draft-seitz-ace-core-authz-00 > > >Abstract: > This memo defines a framework for authorization in constrained-node > networks, i.e. networks where some devices have severe constraints on > memory, processing, power and communication bandwidth. The main goal > is to offload constrained devices by providing them access control > support from trusted parties that are less constrained. The approach > is based on RESTful requests to dedicated access management > resources, supporting different authorization schemes and > communication security paradigms. > >=20 > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jul 9 09:15: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 023D61B2A54 for ; Thu, 9 Jul 2015 09:15:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bOuszj_WDqMW for ; Thu, 9 Jul 2015 09:15:01 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8081A004A for ; Thu, 9 Jul 2015 09:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1436458499; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=QiA3O5IczgVMkVtMIoRu1Mn/4VhfRYsdEcwkgB+ysc8=; b=fPs3EvQTVCaoKORGNnYPL7r6dTwPZCU/BLYgmT9AIm5hRez0ON+U8VwvJNj9qTaSFYIvx7eIZvwCgh+hTy1Uum/0b4HbwICTlBGAlmMc07huUo0SO7RZArG6ndZNbsMxBNXQDiR7wWS7hFdzPv7r3DHb93uZIaPxJt8fMPkIFdg= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03309; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; Received: from 10.22.39.206(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2015 00:14:56 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 10 Jul 2015 00:14:50 +0800 From: "Kepeng Li" To: Stefanie Gerdes , "Ace@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-gerdes-ace-dcaf-examples-00.txt References: <20150706230021.15054.17580.idtracker@ietfa.amsl.com> <559CFF31.4070201@tzi.de> In-Reply-To: <559CFF31.4070201@tzi.de> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: Hannes Tschofenig Subject: Re: [Ace] New Version Notification for draft-gerdes-ace-dcaf-examples-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: Thu, 09 Jul 2015 16:15:03 -0000 Hi Steffi, > We would like to present this draft during the ACE Meeting in Prague. > Could the chairs please reserve a slot for us? It is on the agenda now. Please send us your slides. Thanks, Kind Regards Kepeng =D4=DA 8/7/15 6:45 pm=A3=AC "Stefanie Gerdes" =D0=B4=C8=EB: >Hi all, > >we submitted a draft that will list examples for using DCAF with >well-known protocols on the less constrained level. We started with an >example that illustrates how DCAF can be used with OpenID Connect. > >Please refer to the PDF version [1] for illustrations. > >We would like to present this draft during the ACE Meeting in Prague. >Could the chairs please reserve a slot for us? > >Thanks, >Steffi > >[1] https://tools.ietf.org/pdf/draft-gerdes-ace-dcaf-examples-00.pdf > > >-------- Forwarded Message -------- >Subject: New Version Notification for >draft-gerdes-ace-dcaf-examples-00.txt >Date: Mon, 06 Jul 2015 16:00:21 -0700 >From: internet-drafts@ietf.org >To: Dr. Carsten Bormann , Stefanie Gerdes >, Olaf Bergmann , Stefanie Gerdes >, Olaf Bergmann , Carsten Bormann > > > >A new version of I-D, draft-gerdes-ace-dcaf-examples-00.txt >has been successfully submitted by Stefanie Gerdes and posted to the >IETF repository. > >Name: draft-gerdes-ace-dcaf-examples >Revision: 00 >Title: Examples for Using DCAF with less constrained devices >Document date: 2015-07-06 >Group: Individual Submission >Pages: 5 >URL: >https://www.ietf.org/internet-drafts/draft-gerdes-ace-dcaf-examples-00.txt >Status: >https://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-examples/ >Htmlized: >https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00 > > >Abstract: > Constrained nodes are devices which are limited in terms of > processing power, memory, non-volatile storage and transmission > capacity. Due to these constraints, commonly used security protocols > are not easily applicable. Nevertheless, an authentication and > authorization solution is needed to ensure the security of these > devices. > > The Delegated CoAP Authorization Framework (DCAF) specifies how > resource-constrained nodes can delegate defined authentication- and > authorization-related tasks to less-constrained devices called > Authorization Managers, thus limiting the hardware requirements of > the security solution for the constrained devices. > > To realize the vision of "one Internet for all", constrained devices > need to securely establish trust relationships with less constrained > devices. This document lists examples for using DCAF with less > constrained devices. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > From nobody Thu Jul 9 09:16: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 0FAE71B2A63 for ; Thu, 9 Jul 2015 09:16:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ihhtqCD9BbPq for ; Thu, 9 Jul 2015 09:16:33 -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 3DD111B2A54 for ; Thu, 9 Jul 2015 09:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1436458592; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=mKFMhmQxjyf/VRGlf8mTR2xDDMPoFaJdCuw124jdZPw=; b=HxJ3od7egHo+VPDjupb8L2d7UEtVfsUdDI4glUZGrPBNcGM1cWAwk+q4Jlo0/+elV+RIJCH1Ji6C7YhT6INWpKQnkN1CW7R9s+6k3n73f4fpjc70IEc2l+sgzmnSJj8y28ALbVg9A3JJBNcY3+9OjhO3xeIvgUw3ta4IonXKzzo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R481e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03303; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.39.206(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2015 00:16:31 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 10 Jul 2015 00:16:26 +0800 From: "Kepeng Li" To: "Kumar, Sandeep" , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] FW: New Version Notification for draft-somaraju-ace-multicast-00.txt Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] FW: New Version Notification for draft-somaraju-ace-multicast-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: Thu, 09 Jul 2015 16:16:35 -0000 Hi Sandeep, > Can the chairs allocate time to discuss this at the Prague meeting. It is on the agenda now. Please send us your slides. Thanks, Kind Regards Kepeng =D4=DA 7/7/15 6:12 pm=A3=AC "Kumar, Sandeep" =D0=B4=C8=EB: >Dear all > >We uploaded a new draft with details on the authorization flow within a >professional Lighting systems (which is one of the use cases in the use >case draft). > >Can the chairs allocate time to discuss this at the Prague meeting. > >Regards >Sandeep > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, July 06, 2015 8:31 PM >To: Abhinav Somaraju; Abhinav Somaraju; Sandeep S. Kumar; Hannes >Tschofenig; Hannes Tschofenig; Sandeep S. Kumar >Subject: New Version Notification for draft-somaraju-ace-multicast-00.txt > > >A new version of I-D, draft-somaraju-ace-multicast-00.txt >has been successfully submitted by Abhinav Somaraju and posted to the >IETF repository. > >Name: draft-somaraju-ace-multicast >Revision: 00 >Title: Multicast Security for the Lighting Domain >Document date: 2015-07-06 >Group: Individual Submission >Pages: 22 >URL: =20 >https://www.ietf.org/internet-drafts/draft-somaraju-ace-multicast-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/ >Htmlized: =20 >https://tools.ietf.org/html/draft-somaraju-ace-multicast-00 > > >Abstract: > Lighting systems have strict requirements on message latency and > synchronization (typically latency less than 200 ms and jitter less > than 50 ms). There are several lighting use cases that require > securing such communication between a (group of) senders and a group > of receivers. This draft describes initial ideas for authorization > and key management required for the secure group communication within > a lighting system. > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > > >________________________________ >The information contained in this message may be confidential and legally >protected under applicable law. The message is intended solely for the >addressee(s). If you are not the intended recipient, you are hereby >notified that any use, forwarding, dissemination, or reproduction of this >message is strictly prohibited and may be unlawful. If you are not the >intended recipient, please contact the sender by return e-mail and >destroy all copies of the original message. >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Tue Jul 14 07:35:35 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 3DF931ACE17 for ; Tue, 14 Jul 2015 07:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 VpzjXHKyV1nV for ; Tue, 14 Jul 2015 07:35:32 -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 7CA121ACE12 for ; Tue, 14 Jul 2015 07:35:18 -0700 (PDT) Received: from [192.168.131.131] ([195.149.223.246]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LaXIV-1YYYXL3DN1-00mMgA for ; Tue, 14 Jul 2015 16:35:16 +0200 Message-ID: <55A51E24.8090200@gmx.net> Date: Tue, 14 Jul 2015 16:35:16 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UIKGTDwWawglav6eu7JPGlsn44D8jhOGT" X-Provags-ID: V03:K0:sUFv4cgLN0V06FfgOT2SRBl8H9vCxqJ+s1+gUWn1DfSKg9tFi2s k2rLN7kSw85YIyn1hZxiwERSdv3E+boRHuMl2sT+tm8VNxiLHbJMU3mHXakF/HEdkw19f46 tKQTNcEA5yqRKcQZITsvL5pdpmSU0M44Oe7aOdGtX2gEEf/35CB1wJJMYKFzXefH+VzrE3f kNDMPW+GArOHtuX8ydcQw== X-UI-Out-Filterresults: notjunk:1;V01:K0:o6WO7/9JUUM=:us6Jx46zIJgqGbH+TVsz2d cduiGqGJSOZRIR1qcIxtTobDKb2hX26D04D5yf9Ex3HTc794xWq5QaAcEJydhvrtLVehaZ2SS gLkVBoqtKmuqFTU9x8RWQssUi5RTo1cL4j7HR30TtwimQkop0Af0KKhUmjRBj40wxUMWx7WX7 sc+v7NdpjAdvhoK0oqzSrA72Z6fxTr8wC1U9BdVDl8QR2cDES7NpNENZcsFu8ymg+C3sX1C2/ qgw1u6p49YziWwW+8MYNmAoFJRHdycO7zzuF3pB/fgu6lfIk1Ku5zkGIEgFnpPLZTZfnX6Olh Eci1g5ExHjRXhDQg6shsuhP+cu5pnnjcG92uFCTWBdxyQIO9SbCT20XfTGqMRvzVfMpHq+5d7 oahmcdb6zywSPb9wezWFUrQu4VrdbGSzTq6qGwNvqw6jlHIP+iVWu+/I3z+oHNUZzaGpgErW0 GmULh7u17ygGaumSujlkM5+3ABY0r01gYjd3X4gDD+HFi8Zdm1ixywz36tnHK1yu9bO3komE7 KS2jIA5CHPw/zaA62ifBHfHEilwwes5TxW3Q7vU9utbe79XtEa6NFU13eihoHe32zGff1QqyV gIo5svOcro5A8Q5ZheJ80ZNuQoY6WvXQZtcxNXu7I4cPwIm2AJ3bpeXOnAioqaqSITNMlLUPy XaBjZdE8MAbZdlDCuZs99kKLS79uN3Gq7nyeoaTXJ+Xuzcg== Archived-At: Subject: [Ace] Working Group Status and IETF#93 Preparation X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 14:35:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UIKGTDwWawglav6eu7JPGlsn44D8jhOGT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I just had a chat with Kathleen and I wanted to remind you again about the upcoming meeting, the preparation you are expected to do, and what we try to accomplish. * What are the documents you should be familiar going into the meeting? We have posted an agenda and in that agenda are various links to documents that will get discussed: http://www.ietf.org/mail-archive/web/ace/current/msg01196.html The use case document is currently our only chartered item and needs to be finished. Some of you have already earlier promised to review it. Here is my reminder about the pending reviews: http://www.ietf.org/mail-archive/web/ace/current/msg01185.html Despite the huge interest to have the use case document as a chartered item in this group there have been surprisingly few reviewers in the end. Since we ultimately agreed to work on it, we have to finish it as well. For this meeting we also have a use case contribution on the agenda that talks about public safety. Take a look at it and let us know whether you believe it should be incorporated into the use case document. Here is the link: - http://datatracker.ietf.org/doc/draft-rahman-ace-public-safety-use-case/ At the virtual interim meeting (end of May) we also talked about the actors document (see ). We got very little feedback on that document. We cannot add this document to the milestone list with such a low interest, as Kathleen already expressed during the virtual interim meeting. It is not enough if just the authors like it. Hence, I strongly encourage everyone else in the group to look at it. Finally, we have a couple of solution proposals. Take a brief look at them to see what you like and what you dislike. * What are we trying to accomplish? - We get enough reviews for the use case document so that we can call it done. - Enough reviews & feedback is provided for the actors document so that we can decide whether it is worthwhile to change the charter and add it to the milestone list. If there is no enough input or the feedback is negative then we just move on to the solutions. - Folks read the solution drafts and give us a preference regarding the direction we should be heading. To be honest with you, Kathleen is a bit disappointed about the lack of progress with our work (particularly with the use case document). She considers shutting down the working group if the situation does not improve. Ciao Hannes --UIKGTDwWawglav6eu7JPGlsn44D8jhOGT 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 iQEcBAEBCgAGBQJVpR4lAAoJEGhJURNOOiAtaJYH/0fJLMGtike/fFDsNISSetJx IAoszGXYh9JSkubFUijRZa3LTn6+FAAcLzDQplKG3Pf0/qz6EmhaEzwwJLHJla+e pkPTwzBi4cpTqK0cpQbI441D3Wf8iDHPmEmyW+67KN3GrtqYoalMBScrnEkS97ic flTw+9bXpkTCkTUFI53/HQEpcvB3AxyQ6r6Qy57a2Bon882D7ixFe2RygHLZxXrx zplY7FXvtrS21m1rSOEZbcpYq9v0pZ2/8LAbTNfukW3u5h/gUtw+mkHUzjrxvAU1 GVKKjcUI8F6PGelICwRO2Nnfa/z5v1gdk3GfY+ae5s6g45AFE0/qYPFoaDbXaIQ= =VNKT -----END PGP SIGNATURE----- --UIKGTDwWawglav6eu7JPGlsn44D8jhOGT-- From nobody Wed Jul 15 12:41:33 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 37A411A1B66 for ; Wed, 15 Jul 2015 12:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.907 X-Spam-Level: * X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_50=0.8, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001] 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 YRB_wMl66toQ for ; Wed, 15 Jul 2015 12:41:31 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218B21A1B62 for ; Wed, 15 Jul 2015 12:41:31 -0700 (PDT) Received: from hebrews (unknown [104.129.194.128]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 228FE38F16; Wed, 15 Jul 2015 12:41:29 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 15 Jul 2015 15:41:48 -0400 Message-ID: <002301d0bf36$4af258c0$e0d70a40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdC+91XH7MGTHwusRIGlMUqft0ezFQ== Content-Language: en-us Archived-At: Cc: ace@ietf.org Subject: [Ace] draft-ietf-ace-usecases X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2015 19:41:32 -0000 Section 2.1 -Is it important that vendors have "real-time" information on the state of the container or is it sufficient to have post-mortem dumps? Also is it the vendor or the transporter that needs to have some of this information - since the transporter has a better chance to detect and fix a problem in transit that the vendor. Section 2.1.1 - para #2 - May need a requirement to revoke authorization on a sensor which is out of step with other sensors. I.e. a single sensor which is reading hot when all of the others have a good temperature. Section 2.1.1 - para ? - You need to talk about the possibility that a relay station in the neighborhood of the bananas may need to be present. And that relay station may be provided by the transport company (and change over time as the transport company changes) rather than the vendor. Section 2.1.2 - There is a discussion going on in the COSE group about Integrity and if it is possible to have it in the absence of origin of data information. I.e. can an anonymous note be integrity protected. If you are requiring more than just integrity in U1.2 - then you need to make that statement. Section 2.2 - Do you want to add a case of a child and notification to Alice and Bob when the child arrives home at the end of the school day? Section 2.2 - Do you want to add a case where an external tech comes in to perform maintenance on one or more sections of the house and needs access both to the logs and potentially to change behaviors of subsystems? (i.e. change how the furnace operates after an upgrade). Section 2.3 - s/located physically on the user/located physically on, or in, the user./ Section 2.3.1 s/and his position/and his location/ Otherwise I think this is vertical or prone. Section 2.5 - You need to address the privacy issues implicit in this situation. From nobody Thu Jul 16 11:02:40 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 0938C1B2AFF for ; Thu, 16 Jul 2015 11:02:39 -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, 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 jee0E1sNVTZa for ; Thu, 16 Jul 2015 11:02:37 -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 76EBC1B2AD8 for ; Thu, 16 Jul 2015 11:02:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 24A43E1C4; Thu, 16 Jul 2015 14:19:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B48C763AEC; Thu, 16 Jul 2015 14:02:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9BC2063AD9; Thu, 16 Jul 2015 14:02:36 -0400 (EDT) From: Michael Richardson To: "Jim Schaad" In-Reply-To: <002301d0bf36$4af258c0$e0d70a40$@augustcellars.com> References: <002301d0bf36$4af258c0$e0d70a40$@augustcellars.com> 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: draft-ietf-ace-usecases@tools.ietf.org, ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-usecases X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2015 18:02:39 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > Section 2.1 -Is it important that vendors have "real-time" information on > the state of the container or is it sufficient to have post-mortem dumps? > Also is it the vendor or the transporter that needs to have some of this > information - since the transporter has a better chance to detect and > fix a problem in transit that the vendor. My understanding is that both are relevant. While the container is on a boat, potentially out of range of the vendor, the transporter must get real-time data so that they can fix things. But, in addition, when the container gets to port, the vendor would still like a dump, as they may well take more different action. For instance, perhaps the bananas in that container are still saleable (despite the AC breaking, and the transporter fixing it later that day), but need to be consumed earlier. And then there is the eventual post-mordem: why did the AC fail. > Section 2.2 - Do you want to add a case of a child and notification to > Alice > and Bob when the child arrives home at the end of the school day? [and: what would Alice and Bob name their child? :-) Now I understand why Alice and Bob were so anxious that their (love) notes remain private...] -- 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) iQEVAwUBVafxvICLcPvd0N1lAQJzCQgAgYTSTDDNXlgLFPDL6/tIpRsYI+uPFWBM e8dQZS0zLIX7quoZckwjsNCGU4hG0Cvb988wzUDtnRbDmugS24OmuuuUnZy2sYpm ByN7yHZqI7aHNAgRK7/OXKrJ9GB/eCHxjrr1Ns/shCW8+D1XR/lPq6+GbM4+uu9+ vyCg3a8qxlqrTLZ5k6MPGhEvyJbcUEGJQ7U90Qn/sMD8kv4bS77XOaPI4zCl8AtP T3bLqRscr6NYbZep7ZdfBIAJWuPRF5iAd7kl1fxd7C+lRBdhzWmcxeXY/th8gADt RMDma4Rsnu9C3wUxyu01PX94F29PHaR9SDm9Es2xuhLV2hVN+2pOxw== =bXWi -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 19 04:20: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 BEDFF1ACD01 for ; Sun, 19 Jul 2015 04:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.907 X-Spam-Level: * X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_50=0.8, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001] 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 9sayfyQ4sDPR for ; Sun, 19 Jul 2015 04:20:42 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C151ACCFF for ; Sun, 19 Jul 2015 04:20:42 -0700 (PDT) Received: from hebrews (unknown [130.129.7.152]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 69B5038F11; Sun, 19 Jul 2015 04:20:39 -0700 (PDT) From: "Jim Schaad" To: , Date: Sun, 19 Jul 2015 13:20:58 +0200 Message-ID: <01b001d0c214$fe3bf0e0$fab3d2a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDAdsHOyEiElwvbSheqRuDBgdnZgA== Content-Language: en-us Archived-At: Subject: [Ace] draft-gerdes-ace-actors X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 11:20:43 -0000 I have read through this draft and my first comment is - I don't understand what this draft is trying to accomplish. My confusion begins in the second paragraph of the abstract where it says that it is providing "elements of an architecture / a problem statement". The idea of providing terminology is reasonable - although I generally don't believe that a standalone document is a good place to do so unless you are doing a lot of definitions. And for the most part you just use the same ones as OAuth is using. I can see providing an architecture that is going to be reasonable complete or a problem statement. But doing just elements of those is not useful. How is one to evaluate anything against it if just pieces are given but not anything representing a complete picture. Introduction: * constrained devices are not the only ones for which ACLs are not sufficiently generic. There are lots of places where doing access control is off-loaded from a device to another system. Even with ACLs you need to discuss how authorization would be dealt with. This statement could be much clearer. * If you are going to tell me that there are security tasks that cannot be done, you need to provide a list of what security tasks you care about someplace so I can verify this for myself. Also, for many of these tasks it is necessary to offload even when they can be done by the device. Offloading authorization is not uncommon even for larger devices. * Just saying that limitations are a problem is not generally helpful. It would be better to list some of the reasons for each security task you care about. Since people are going to need to make decisions about what things can and cannot be placed together and having such a list would be helpful in that regard. * Doing forward references to fulfill some of these requests is perfectly reasonable. Terminology: * I am completely lost by the last sentence in this section. It may be signature structure, but it is also an issue with what you are talking about for client-side authorization. * Should "endpoint" be part of the terminology section? Architecture: * I have a problem with bullet #1 - It may be due to working in SACM and depends on how one defines endpoint. However I see no reason that an endpoint cannot host the functionality of AS and CAS as well so this bullet is not complete. * The term "constrained level" pops up out of the middle of nowhere - this really needs to be defined. Perhaps this should be a section title with and introduction before you start. * The introduction of the CSA does not seem logical if it is to help make requests of the RS. This needs more justification. I would have thought it was there to control the C and what it does with things. This seemed to be the Objective type 2 statement from above. If you are making it a support item, then it does not make sense either to call it an access control point or to say it is being controlled by the RqP. It could just as easily be either a neutral party or the AS that is being talked to. Information Flows * I don't understand the reason for complicating the diagram. Having it be the simple version, at least at first presentation of flows, makes it easier to understand. You can talk about the reflection at a later point. * Why do you have information flows as one directional between CAS and C? Missing Architecture issues * Why do you not talk about the presence or absence of AS and CAS nodes at times * Store and forward should be discussed in this document. (i.e. combination of push and pull models) * Better description of type 2 security objects needs to be undertaken - specifically why we would care about them. Security Objectives: * I assume that access is also a security object that is addressed by authorization. * Kill the term non-repudiation - I don't know what this means and there is not a great deal of agreement on its meaning. * You absolutely need some measure of authentication involved. The paragraph 2 needs have a cleaner start that what it does. You really need to talk about authentication, are you authenticating the device or are you authentication any device (or some set of devices) that are owned by somebody. These are different authentication models. **** I am tired and going to stop at this point. Jim From nobody Sun Jul 19 07:54: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 D5C271AD351 for ; Sun, 19 Jul 2015 07:54:00 -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 SXdEpkJduAVS for ; Sun, 19 Jul 2015 07:53:58 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D031AD359 for ; Sun, 19 Jul 2015 07:53:57 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-e3-55abba047032 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.BD.12828.40ABBA55; Sun, 19 Jul 2015 16:53:56 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.149]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Sun, 19 Jul 2015 16:53:55 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-gerdes-ace-actors@tools.ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] draft-gerdes-ace-actors Thread-Index: AdDAdsHOyEiElwvbSheqRuDBgdnZgABu/l4A Date: Sun, 19 Jul 2015 14:53:55 +0000 Message-ID: References: <01b001d0c214$fe3bf0e0$fab3d2a0$@augustcellars.com> In-Reply-To: <01b001d0c214$fe3bf0e0$fab3d2a0$@augustcellars.com> 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.150] Content-Type: text/plain; charset="utf-8" Content-ID: <7A74521C4BC1DA45BD5E47F201BB7E87@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Rpdl1+pQg3sfRSy+f+thtjhychqr xerp39kcmD02zpnO5rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZfRNnsNScMaxYtLuiAbG L/ZdjJwcEgImElvvdjND2GISF+6tZ+ti5OIQEjjKKHH68EdGCGcJo8TEz49YQKrYBFwkHjQ8 YgJJiAjMZZQ43vafFSQhLKAlsWrpVyYQW0RAW+LBurfMELaRxKY1Z8GaWQRUJR4cfMsIYvMK WEjsfH8CrF5IwF5izrOlYHM4BRwkFn28xw5iMwKd9P3UGrAaZgFxiVtP5jNBnCogsWTPeaiz RSVePv4H1isqoCex8noTG0RcSWLF9ktAuziAejUl1u/ShxhjLTFj2jJWCFtRYkr3Q3aIcwQl Ts58wjKBUXwWkm2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjEC I/Dglt+6OxhXv3Y8xCjAwajEw7uAZXWoEGtiWXFl7iFGaQ4WJXHeGZvzQoUE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwSsupSy2+L8Cc/3/5DZXDqv0L60p7TKbxKNpExTGdvuXSaCeqeaqX N2mrwLfVwk3XZ3321tGwcBFctGaaz4O5Ta1NtRFnJhV6pofM2lk23TLDqUvhVNZHmUXX7h44 HRFaGFo7lePMJU790EZjpwYHz8WLN7O8Kvy1LOFHQv6nLYzzjbqtU/4psRRnJBpqMRcVJwIA Codz5qECAAA= Archived-At: Subject: Re: [Ace] draft-gerdes-ace-actors X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 14:54:01 -0000 SmltLCB0aGFua3MgZm9yIHJldmlld2luZywgc29tZSBmaXJzdCBjb21tZW50cyBiZWxvdy4NCg0K T24gMjAxNS0wNy0xOSAxMzoyMCwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29t PiB3cm90ZToNCg0KPkkgaGF2ZSByZWFkIHRocm91Z2ggdGhpcyBkcmFmdCBhbmQgbXkgZmlyc3Qg Y29tbWVudCBpcyAtIEkgZG9uJ3QNCj51bmRlcnN0YW5kDQo+d2hhdCB0aGlzIGRyYWZ0IGlzIHRy eWluZyB0byBhY2NvbXBsaXNoLiAgTXkgY29uZnVzaW9uIGJlZ2lucyBpbiB0aGUNCj5zZWNvbmQN Cj5wYXJhZ3JhcGggb2YgdGhlIGFic3RyYWN0IHdoZXJlIGl0IHNheXMgdGhhdCBpdCBpcyBwcm92 aWRpbmcgImVsZW1lbnRzIG9mDQo+YW4NCj5hcmNoaXRlY3R1cmUgLyBhIHByb2JsZW0gc3RhdGVt ZW50Ii4NCj4NCj5UaGUgaWRlYSBvZiBwcm92aWRpbmcgdGVybWlub2xvZ3kgaXMgcmVhc29uYWJs ZSAtIGFsdGhvdWdoIEkgZ2VuZXJhbGx5DQo+ZG9uJ3QNCj5iZWxpZXZlIHRoYXQgYSBzdGFuZGFs b25lIGRvY3VtZW50IGlzIGEgZ29vZCBwbGFjZSB0byBkbyBzbyB1bmxlc3MgeW91IGFyZQ0KPmRv aW5nIGEgbG90IG9mIGRlZmluaXRpb25zLiAgQW5kIGZvciB0aGUgbW9zdCBwYXJ0IHlvdSBqdXN0 IHVzZSB0aGUgc2FtZQ0KPm9uZXMgYXMgT0F1dGggaXMgdXNpbmcuICAgSSBjYW4gc2VlIHByb3Zp ZGluZyBhbiBhcmNoaXRlY3R1cmUgdGhhdCBpcw0KPmdvaW5nDQo+dG8gYmUgcmVhc29uYWJsZSBj b21wbGV0ZSBvciBhIHByb2JsZW0gc3RhdGVtZW50LiAgQnV0IGRvaW5nIGp1c3QgZWxlbWVudHMN Cj5vZiB0aG9zZSBpcyBub3QgdXNlZnVsLiAgSG93IGlzIG9uZSB0byBldmFsdWF0ZSBhbnl0aGlu ZyBhZ2FpbnN0IGl0IGlmDQo+anVzdA0KPnBpZWNlcyBhcmUgZ2l2ZW4gYnV0IG5vdCBhbnl0aGlu ZyByZXByZXNlbnRpbmcgYSBjb21wbGV0ZSBwaWN0dXJlLg0KDQpBZ3JlZS4gSSB0aGluayB0aGlz IGRyYWZ0IHNob3VsZCBjb250YWluIGJvdGggYXJjaGl0ZWN0dXJlIGFuZCBwcm9ibGVtDQpzdGF0 ZW1lbnQsIHRvIHRoZSBsZXZlbCBvZiBkZXRhaWwgdGhhdCBpdCBiZWNvbWVzIGVhc3kgZm9yIHBl b3BsZSB0bw0KdW5kZXJzdGFuZCB3aGF0IHRoaXMgd29yayBpcyBhYm91dC4NCg0KDQo+DQo+SW50 cm9kdWN0aW9uOg0KPg0KPiogY29uc3RyYWluZWQgZGV2aWNlcyBhcmUgbm90IHRoZSBvbmx5IG9u ZXMgZm9yIHdoaWNoIEFDTHMgYXJlIG5vdA0KPnN1ZmZpY2llbnRseSBnZW5lcmljLiAgVGhlcmUg YXJlIGxvdHMgb2YgcGxhY2VzIHdoZXJlIGRvaW5nIGFjY2VzcyBjb250cm9sDQo+aXMgb2ZmLWxv YWRlZCBmcm9tIGEgZGV2aWNlIHRvIGFub3RoZXIgc3lzdGVtLiAgRXZlbiB3aXRoIEFDTHMgeW91 IG5lZWQgdG8NCj5kaXNjdXNzIGhvdyBhdXRob3JpemF0aW9uIHdvdWxkIGJlIGRlYWx0IHdpdGgu ICAgVGhpcyBzdGF0ZW1lbnQgY291bGQgYmUNCj5tdWNoIGNsZWFyZXIuDQo+DQo+KiAgSWYgeW91 IGFyZSBnb2luZyB0byB0ZWxsIG1lIHRoYXQgdGhlcmUgYXJlIHNlY3VyaXR5IHRhc2tzIHRoYXQg Y2Fubm90DQo+YmUNCj5kb25lLCB5b3UgbmVlZCB0byBwcm92aWRlIGEgbGlzdCBvZiB3aGF0IHNl Y3VyaXR5IHRhc2tzIHlvdSBjYXJlIGFib3V0DQo+c29tZXBsYWNlIHNvIEkgY2FuIHZlcmlmeSB0 aGlzIGZvciBteXNlbGYuICBBbHNvLCBmb3IgbWFueSBvZiB0aGVzZSB0YXNrcw0KPml0DQo+aXMg bmVjZXNzYXJ5IHRvIG9mZmxvYWQgZXZlbiB3aGVuIHRoZXkgY2FuIGJlIGRvbmUgYnkgdGhlIGRl dmljZS4NCj5PZmZsb2FkaW5nIGF1dGhvcml6YXRpb24gaXMgbm90IHVuY29tbW9uIGV2ZW4gZm9y IGxhcmdlciBkZXZpY2VzLg0KPg0KPiogSnVzdCBzYXlpbmcgdGhhdCBsaW1pdGF0aW9ucyBhcmUg YSBwcm9ibGVtIGlzIG5vdCBnZW5lcmFsbHkgaGVscGZ1bC4gIEl0DQo+d291bGQgYmUgYmV0dGVy IHRvIGxpc3Qgc29tZSBvZiB0aGUgcmVhc29ucyBmb3IgZWFjaCBzZWN1cml0eSB0YXNrIHlvdQ0K PmNhcmUNCj5hYm91dC4gIFNpbmNlIHBlb3BsZSBhcmUgZ29pbmcgdG8gbmVlZCB0byBtYWtlIGRl Y2lzaW9ucyBhYm91dCB3aGF0IHRoaW5ncw0KPmNhbiBhbmQgY2Fubm90IGJlIHBsYWNlZCB0b2dl dGhlciBhbmQgaGF2aW5nIHN1Y2ggYSBsaXN0IHdvdWxkIGJlIGhlbHBmdWwNCj5pbg0KPnRoYXQg cmVnYXJkLg0KPg0KPiogRG9pbmcgZm9yd2FyZCByZWZlcmVuY2VzIHRvIGZ1bGZpbGwgc29tZSBv ZiB0aGVzZSByZXF1ZXN0cyBpcyBwZXJmZWN0bHkNCj5yZWFzb25hYmxlLg0KPg0KPlRlcm1pbm9s b2d5Og0KPg0KPiogIEkgYW0gY29tcGxldGVseSBsb3N0IGJ5IHRoZSBsYXN0IHNlbnRlbmNlIGlu IHRoaXMgc2VjdGlvbi4gIEl0IG1heSBiZQ0KPnNpZ25hdHVyZSBzdHJ1Y3R1cmUsIGJ1dCBpdCBp cyBhbHNvIGFuIGlzc3VlIHdpdGggd2hhdCB5b3UgYXJlIHRhbGtpbmcNCj5hYm91dA0KPmZvciBj bGllbnQtc2lkZSBhdXRob3JpemF0aW9uLg0KDQpJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbi4g VGhpcyB3YXMgYSB0b3BpYyBvZiBpbnRlbnNlIGRpc2N1c3Npb25zIGR1cmluZw0KdGhlIHNwcmlu Zy4gVGhlIGN1cnJlbnQgZHJhZnQgaXMgdXNpbmcg4oCcYXV0aG9yaXphdGlvbiIgaW4gYSBuYXR1 cmFsDQpsYW5ndWFnZSBzZW5zZSwgaS5lLiBhbnkgYWN0aW9uIHRoYXQgdGhlIGNsaWVudCBjYW4g YmUgY29uZmlndXJlZCB0byBkbyBieQ0KdGhlIENBUyBpcyBjb25zaWRlcmVkIGF1dGhvcml6YXRp b24uDQoNCj4NCj4qIFNob3VsZCAiZW5kcG9pbnQiIGJlIHBhcnQgb2YgdGhlIHRlcm1pbm9sb2d5 IHNlY3Rpb24/DQoNClRoaXMgaXMgZGVmaW5lZCBpbiBSRkM3MjUyLCBzbyBzaG91bGQgYmUgYWRk ZWQgdG8gdGhlIGxpc3Qgb2YgdGVybXMNCnJlZmVyZW5jZWQgaW4gZnJvbSB0aGF0Lg0KDQo+DQo+ QXJjaGl0ZWN0dXJlOg0KPg0KPiogIEkgaGF2ZSBhIHByb2JsZW0gd2l0aCBidWxsZXQgIzEgLSBJ dCBtYXkgYmUgZHVlIHRvIHdvcmtpbmcgaW4gU0FDTSBhbmQNCj5kZXBlbmRzIG9uIGhvdyBvbmUg ZGVmaW5lcyBlbmRwb2ludC4gIEhvd2V2ZXIgSSBzZWUgbm8gcmVhc29uIHRoYXQgYW4NCj5lbmRw b2ludCBjYW5ub3QgaG9zdCB0aGUgZnVuY3Rpb25hbGl0eSBvZiBBUyBhbmQgQ0FTIGFzIHdlbGwg c28gdGhpcw0KPmJ1bGxldA0KPmlzIG5vdCBjb21wbGV0ZS4NCj4NCj4qICBUaGUgdGVybSAiY29u c3RyYWluZWQgbGV2ZWwiIHBvcHMgdXAgb3V0IG9mIHRoZSBtaWRkbGUgb2Ygbm93aGVyZSAtDQo+ dGhpcw0KPnJlYWxseSBuZWVkcyB0byBiZSBkZWZpbmVkLiAgUGVyaGFwcyB0aGlzIHNob3VsZCBi ZSBhIHNlY3Rpb24gdGl0bGUgd2l0aA0KPmFuZA0KPmludHJvZHVjdGlvbiBiZWZvcmUgeW91IHN0 YXJ0Lg0KPg0KPiogIFRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIENTQSBkb2VzIG5vdCBzZWVtIGxv Z2ljYWwgaWYgaXQgaXMgdG8gaGVscCBtYWtlDQo+cmVxdWVzdHMgb2YgdGhlIFJTLiAgVGhpcyBu ZWVkcyBtb3JlIGp1c3RpZmljYXRpb24uICBJIHdvdWxkIGhhdmUgdGhvdWdodA0KPml0DQo+d2Fz IHRoZXJlIHRvIGNvbnRyb2wgdGhlIEMgYW5kIHdoYXQgaXQgZG9lcyB3aXRoIHRoaW5ncy4gICBU aGlzIHNlZW1lZCB0bw0KPmJlDQo+dGhlIE9iamVjdGl2ZSB0eXBlIDIgc3RhdGVtZW50IGZyb20g YWJvdmUuICAgSWYgeW91IGFyZSBtYWtpbmcgaXQgYQ0KPnN1cHBvcnQNCj5pdGVtLCB0aGVuIGl0 IGRvZXMgbm90IG1ha2Ugc2Vuc2UgZWl0aGVyIHRvIGNhbGwgaXQgYW4gYWNjZXNzIGNvbnRyb2wN Cj5wb2ludA0KPm9yIHRvIHNheSBpdCBpcyBiZWluZyBjb250cm9sbGVkIGJ5IHRoZSBScVAuICBJ dCBjb3VsZCBqdXN0IGFzIGVhc2lseSBiZQ0KPmVpdGhlciBhIG5ldXRyYWwgcGFydHkgb3IgdGhl IEFTIHRoYXQgaXMgYmVpbmcgdGFsa2VkIHRvLg0KPg0KPkluZm9ybWF0aW9uIEZsb3dzDQo+DQo+ KiAgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSByZWFzb24gZm9yIGNvbXBsaWNhdGluZyB0aGUgZGlh Z3JhbS4gICBIYXZpbmcgaXQNCj5iZSB0aGUgc2ltcGxlIHZlcnNpb24sIGF0IGxlYXN0IGF0IGZp cnN0IHByZXNlbnRhdGlvbiBvZiBmbG93cywgbWFrZXMgaXQNCj5lYXNpZXIgdG8gdW5kZXJzdGFu ZC4gIFlvdSBjYW4gdGFsayBhYm91dCB0aGUgcmVmbGVjdGlvbiBhdCBhIGxhdGVyIHBvaW50Lg0K DQpUaGUgcHVycG9zZSBvZiB0aGlzIHBpY3R1cmUgd2FzIHRvIGVtcGhhc2l6ZSB0aGF0IHRoZSBl bmRwb2ludHMgY2FuIGluDQpnZW5lcmFsIGhvc3QgYm90aCBjbGllbnQgYW5kIHNlcnZlciBmdW5j dGlvbmFsaXR5LCBidXQgdGhpcyBpcyBhbHJlYWR5DQpleHBsYWluZWQgaW4gdGV4dCBzbyBJIGFn cmVlIGl0IGNhbiBiZSBvbWl0dGVkLg0KDQoNCj4NCj4qICBXaHkgZG8geW91IGhhdmUgaW5mb3Jt YXRpb24gZmxvd3MgYXMgb25lIGRpcmVjdGlvbmFsIGJldHdlZW4gQ0FTIGFuZCBDPw0KDQoNClRo ZSBtYWluIGluZm9ybWF0aW9uIGZsb3csIGp1c3QgYXMgaW4gdGhlIGNhc2Ugb2YgQVMgYW5kIFJT LCBpcyBmcm9tIHRoZQ0KbGVzcy1jb25zdHJhaW5lZCBkZXZpY2UgdG8gdGhlIGNvbnN0cmFpbmVk IGRldmljZS4gQnV0IHlvdSBhcmUgcmlnaHQgdGhhdA0KaW4gYm90aCBjYXNlcyB0aGVyZSBtYXkg YmUgaW5mb3JtYXRpb24gZmxvd3MgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLg0KRS5nLiBUaGUg UlMgbWF5IHJlcXVlc3QgdGhlIEFTIGZvciBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGdpdmVu IGENCnNwZWNpZmljIHJlcXVlc3QgZnJvbSBhIGNsaWVudC4NCg0KDQo+DQo+TWlzc2luZyBBcmNo aXRlY3R1cmUgaXNzdWVzDQo+DQo+KiBXaHkgZG8geW91IG5vdCB0YWxrIGFib3V0IHRoZSBwcmVz ZW5jZSBvciBhYnNlbmNlIG9mIEFTIGFuZCBDQVMgbm9kZXMgYXQNCj5UaW1lcw0KPg0KPiogU3Rv cmUgYW5kIGZvcndhcmQgc2hvdWxkIGJlIGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50LiAoaS5l Lg0KPmNvbWJpbmF0aW9uDQo+b2YgcHVzaCBhbmQgcHVsbCBtb2RlbHMpDQoNCkRpZmZlcmVudCBh dXRob3JpemF0aW9uIHNjaGVtZXMgYXJlIGRpc2N1c3NlZCBpbg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1jb3JlLWF1dGh6DQpBcmUgdGhlcmUgYW55IHNjaGVt ZXMgeW91IG1pc3MgdGhlcmU/DQoNCj4NCj4qICBCZXR0ZXIgZGVzY3JpcHRpb24gb2YgdHlwZSAy IHNlY3VyaXR5IG9iamVjdHMgbmVlZHMgdG8gYmUgdW5kZXJ0YWtlbiAtDQo+c3BlY2lmaWNhbGx5 IHdoeSB3ZSB3b3VsZCBjYXJlIGFib3V0IHRoZW0uDQo+DQo+U2VjdXJpdHkgT2JqZWN0aXZlczoN Cj4NCj4qICBJIGFzc3VtZSB0aGF0IGFjY2VzcyBpcyBhbHNvIGEgc2VjdXJpdHkgb2JqZWN0IHRo YXQgaXMgYWRkcmVzc2VkIGJ5DQo+YXV0aG9yaXphdGlvbi4NCj4NCj4qICBLaWxsIHRoZSB0ZXJt IG5vbi1yZXB1ZGlhdGlvbiAtIEkgZG9uJ3Qga25vdyB3aGF0IHRoaXMgbWVhbnMgYW5kIHRoZXJl DQo+aXMNCj5ub3QgYSBncmVhdCBkZWFsIG9mIGFncmVlbWVudCBvbiBpdHMgbWVhbmluZy4NCj4N Cj4gKiBZb3UgYWJzb2x1dGVseSBuZWVkIHNvbWUgbWVhc3VyZSBvZiBhdXRoZW50aWNhdGlvbiBp bnZvbHZlZC4gIFRoZQ0KPnBhcmFncmFwaCAyIG5lZWRzIGhhdmUgYSBjbGVhbmVyIHN0YXJ0IHRo YXQgd2hhdCBpdCBkb2VzLiAgWW91IHJlYWxseSBuZWVkDQo+dG8gdGFsayBhYm91dCBhdXRoZW50 aWNhdGlvbiwgYXJlIHlvdSBhdXRoZW50aWNhdGluZyB0aGUgZGV2aWNlIG9yIGFyZSB5b3UNCj5h dXRoZW50aWNhdGlvbiBhbnkgZGV2aWNlIChvciBzb21lIHNldCBvZiBkZXZpY2VzKSB0aGF0IGFy ZSBvd25lZCBieQ0KPnNvbWVib2R5LiAgVGhlc2UgYXJlIGRpZmZlcmVudCBhdXRoZW50aWNhdGlv biBtb2RlbHMuDQoNCkRvZXMgc2VjdGlvbiA3LjIgYWRkcmVzcyB5b3VyIHF1ZXN0aW9ucz8NCg0K Pg0KPioqKioNCj4NCj5JIGFtIHRpcmVkIGFuZCBnb2luZyB0byBzdG9wIGF0IHRoaXMgcG9pbnQu DQo+DQo+SmltDQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5BY2UgbWFpbGluZyBsaXN0DQo+QWNlQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Sun Jul 19 12:44:20 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 E1C411ACEA8; Sun, 19 Jul 2015 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IogDlmgUu_no; Sun, 19 Jul 2015 06:04:40 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C070F1ACEA1; Sun, 19 Jul 2015 06:04:39 -0700 (PDT) X-AuditID: 12074424-f79b46d000001e7f-96-55aba0662cba Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.42.07807.660ABA55; Sun, 19 Jul 2015 09:04:38 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t6JD4blF009992; Sun, 19 Jul 2015 09:04:37 -0400 Received: from dhcp-89fd.meeting.ietf.org (dhcp-89fd.meeting.ietf.org [31.133.137.253]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6JD4XIK028521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Jul 2015 09:04:35 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_83501533-7AD1-4E76-833B-1CE975B61D89" Date: Sun, 19 Jul 2015 15:04:33 +0200 References: <9850F0C0-1BCB-4F22-A925-73A7A6A2B5BF@mit.edu> To: dtls-iot@ietf.org, core@ietf.org, ace@ietf.org, t2trg@irtf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hRV1k1bsDrUoPugkMX3bz3MFvverme2 WNy+i9Xi/YMeFgcWjyVLfjJ5TN54mC2AKYrLJiU1J7MstUjfLoErY9rPe0wF7/Qqppw2bGDc odHFyMkhIWAi8eL5V2YIW0ziwr31bF2MXBxCAouZJNr/LGGBcDYySsybsIgVwrnCJPH4fC8r SAubgKrE9DUtTCA2s0CCxKdXt9lBbGEBHYmn7++A1bAA1aw7/4UFxBYSsJLY8f0GWL2IgJPE pbvPwGp4geIbFreyQNh6Ej3nvjBCnCQrsfVNK9MERr5ZSFbMQlIGEdeWWLbwNTOErSmxv3s5 C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6+VmluilppRuYgQFNbuLyg7G 5kNKhxgFOBiVeHgnfFsVKsSaWFZcmXuIUZKDSUmU94rz6lAhvqT8lMqMxOKM+KLSnNTiQ4wS HMxKIryBgUA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJ3sD5QI2C RanpqRVpmTklCGkmDk6Q4TxAw9eB1PAWFyTmFmemQ+RPMSpKifP2giQEQBIZpXlwvbCk84pR HOgVYV4JkCoeYMKC634FNJgJaHDn6hUgg0sSEVJSDYwdhqnt3x5NnpNwZl2W+qbFOrvfPbrT 9suD3TbIY79dgtnnQ2tSAkXf9k+NL3gXffpIbYkF7+TSHRf4HLhr1sunpd06dPZy5Out+od8 NET+eu7giNq3U+STRMXd5RJmcmtKOq93X1JfJ9LNMtP+s41uULaiSKqhzj+pcMODX1SFQt4+ 62IsXqLEUpyRaKjFXFScCABEFZWpFQMAAA== Archived-At: X-Mailman-Approved-At: Sun, 19 Jul 2015 12:44:18 -0700 Subject: [Ace] Fwd: [Cose] IETF93 Meeting Reminder X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 13:04:42 -0000 --Apple-Mail=_83501533-7AD1-4E76-833B-1CE975B61D89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Crossposting for anyone interested in attending the COSE WG tomorrow = morning. tl;dr version: we=E2=80=99re likely starting before 10:00am so = show up early. =E2=80=94 Justin > Begin forwarded message: >=20 > From: Justin Richer > Subject: [Cose] IETF93 Meeting Reminder > Date: July 19, 2015 at 2:20:21 PM GMT+2 > To: >=20 > Hi everyone, and to those currently in Prague, V=C3=ADtejte v =C4=8Cesk=C3= =A9 republice! >=20 > As a reminder, we=E2=80=99re meeting tomorrow, Monday morning during = the first session in the Berlin/Brussels room. We=E2=80=99re sharing the = room with IPSECME, who are going to start off at 9am. We=E2=80=99ll be = picking up as soon as they wrap. Ostensibly this gives us a starting = time of 10am, but we don=E2=80=99t anticipate that the IPSECME meeting = is going to take the full hour.=20 >=20 > The upshot of this is that we will more than likely be starting the = COSE meeting at some point before 10am in order to give us the most = time. As such, we=E2=80=99re asking that everyone be there early. I=E2=80=99= m going to be there right around 9am, and I would recommend that COSE = folks come no later than 9:30, if not earlier. Basically, as soon as the = previous WG is done and we=E2=80=99ve had a few minutes to transition = things over, we=E2=80=99re going to get started, whether or not you=E2=80=99= re there. :) >=20 > See you all bright and early tomorrow, > =E2=80=94 Justin > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_83501533-7AD1-4E76-833B-1CE975B61D89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Crossposting for anyone interested in attending the COSE WG = tomorrow morning. tl;dr version: we=E2=80=99re likely starting before = 10:00am so show up early.

 =E2=80=94 Justin

Begin = forwarded message:

From: = Justin Richer <jricher@mit.edu>
Subject: = [Cose] IETF93 = Meeting Reminder
Date: July 19, 2015 at 2:20:21 PM GMT+2
To: = <cose@ietf.org>

Hi everyone, and = to those currently in Prague, V=C3=ADtejte v =C4=8Cesk=C3=A9 = republice!

As a reminder, we=E2=80=99re = meeting tomorrow, Monday morning during the first session in the = Berlin/Brussels room. We=E2=80=99re sharing the room with IPSECME, who = are going to start off at 9am. We=E2=80=99ll be picking up as soon as = they wrap. Ostensibly this gives us a starting time of 10am, but we = don=E2=80=99t anticipate that the IPSECME meeting is going to take the = full hour.

The upshot of this is that we = will more than likely be starting the COSE meeting at some point before = 10am in order to give us the most time. As such, we=E2=80=99re asking = that everyone be there early. I=E2=80=99m going to be there right around = 9am, and I would recommend that COSE folks come no later than 9:30, if = not earlier. Basically, as soon as the previous WG is done and we=E2=80=99= ve had a few minutes to transition things over, we=E2=80=99re going to = get started, whether or not you=E2=80=99re there. :)

See you all bright and early tomorrow,
=E2=80=94= Justin
_______________________________________________
Cose mailing list
Cose@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_83501533-7AD1-4E76-833B-1CE975B61D89-- From nobody Sun Jul 19 13:39:16 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 DD1C91B2C03 for ; Sun, 19 Jul 2015 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MSGID_FROM_MTA_HEADER=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 CPelZWlc2Odn for ; Sun, 19 Jul 2015 13:39:11 -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 225CD1B2C0B for ; Sun, 19 Jul 2015 13:39:08 -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 t6JKd23i029430; Sun, 19 Jul 2015 22:39:02 +0200 (CEST) Message-Id: <201507192039.t6JKd23i029430@mailhost.informatik.uni-bremen.de> Received: from [192.168.11.105] (mucha.avetravel.cz [77.240.96.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mZJ1x4pmczD3FT; Sun, 19 Jul 2015 22:39:01 +0200 (CEST) Date: Sun, 19 Jul 2015 22:38:58 +0200 From: Stefanie Gerdes To: Jim Schaad MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: draft-gerdes-ace-actors@tools.ietf.org, ace@ietf.org Subject: Re: [Ace] draft-gerdes-ace-actors X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 20:39:14 -0000 SGkgSmltLAoKSSB0aGluayB0aGF0IHRoZSAtMDMgdmVyc2lvbiBbMV0gb2YgdGhlIGRyYWZ0IGFk ZHJlc3NlZCBhIGxvdCBvZiB0aGUgaXNzdWVzIHlvdSBhcmUgbWVudGlvbmluZy4gSXQgaGFkIGEg Y2xlYXIgZm9jdXMsIGxpc3RlZCB0aGUgdGFza3MgYW5kIGV4cGxhaW5lZCB0aGUgbmVlZCBmb3Ig dGhlIGRpZmZlcmVudCBhY3RvcnMuCgpCZXN0IHJlZ2FyZHMsClN0ZWZmaQoKWzFdIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvcGRmL2RyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLTAzLnBkZgoKQW0gMTku MDcuMjAxNSAxMzoyMCBzY2hyaWViIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+ Ogo+Cj4gSSBoYXZlIHJlYWQgdGhyb3VnaCB0aGlzIGRyYWZ0IGFuZCBteSBmaXJzdCBjb21tZW50 IGlzIC0gSSBkb24ndCB1bmRlcnN0YW5kIAo+IHdoYXQgdGhpcyBkcmFmdCBpcyB0cnlpbmcgdG8g YWNjb21wbGlzaC7CoCBNeSBjb25mdXNpb24gYmVnaW5zIGluIHRoZSBzZWNvbmQgCj4gcGFyYWdy YXBoIG9mIHRoZSBhYnN0cmFjdCB3aGVyZSBpdCBzYXlzIHRoYXQgaXQgaXMgcHJvdmlkaW5nICJl bGVtZW50cyBvZiBhbiAKPiBhcmNoaXRlY3R1cmUgLyBhIHByb2JsZW0gc3RhdGVtZW50Ii7CoCAK Pgo+IFRoZSBpZGVhIG9mIHByb3ZpZGluZyB0ZXJtaW5vbG9neSBpcyByZWFzb25hYmxlIC0gYWx0 aG91Z2ggSSBnZW5lcmFsbHkgZG9uJ3QgCj4gYmVsaWV2ZSB0aGF0IGEgc3RhbmRhbG9uZSBkb2N1 bWVudCBpcyBhIGdvb2QgcGxhY2UgdG8gZG8gc28gdW5sZXNzIHlvdSBhcmUgCj4gZG9pbmcgYSBs b3Qgb2YgZGVmaW5pdGlvbnMuwqAgQW5kIGZvciB0aGUgbW9zdCBwYXJ0IHlvdSBqdXN0IHVzZSB0 aGUgc2FtZSAKPiBvbmVzIGFzIE9BdXRoIGlzIHVzaW5nLsKgwqAgSSBjYW4gc2VlIHByb3ZpZGlu ZyBhbiBhcmNoaXRlY3R1cmUgdGhhdCBpcyBnb2luZyAKPiB0byBiZSByZWFzb25hYmxlIGNvbXBs ZXRlIG9yIGEgcHJvYmxlbSBzdGF0ZW1lbnQuwqAgQnV0IGRvaW5nIGp1c3QgZWxlbWVudHMgCj4g b2YgdGhvc2UgaXMgbm90IHVzZWZ1bC7CoCBIb3cgaXMgb25lIHRvIGV2YWx1YXRlIGFueXRoaW5n IGFnYWluc3QgaXQgaWYganVzdCAKPiBwaWVjZXMgYXJlIGdpdmVuIGJ1dCBub3QgYW55dGhpbmcg cmVwcmVzZW50aW5nIGEgY29tcGxldGUgcGljdHVyZS4gCj4KPiBJbnRyb2R1Y3Rpb246IAo+Cj4g KiBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSBub3QgdGhlIG9ubHkgb25lcyBmb3Igd2hpY2ggQUNM cyBhcmUgbm90IAo+IHN1ZmZpY2llbnRseSBnZW5lcmljLsKgIFRoZXJlIGFyZSBsb3RzIG9mIHBs YWNlcyB3aGVyZSBkb2luZyBhY2Nlc3MgY29udHJvbCAKPiBpcyBvZmYtbG9hZGVkIGZyb20gYSBk ZXZpY2UgdG8gYW5vdGhlciBzeXN0ZW0uwqAgRXZlbiB3aXRoIEFDTHMgeW91IG5lZWQgdG8gCj4g ZGlzY3VzcyBob3cgYXV0aG9yaXphdGlvbiB3b3VsZCBiZSBkZWFsdCB3aXRoLsKgwqAgVGhpcyBz dGF0ZW1lbnQgY291bGQgYmUgCj4gbXVjaCBjbGVhcmVyLiAKPgo+ICrCoCBJZiB5b3UgYXJlIGdv aW5nIHRvIHRlbGwgbWUgdGhhdCB0aGVyZSBhcmUgc2VjdXJpdHkgdGFza3MgdGhhdCBjYW5ub3Qg YmUgCj4gZG9uZSwgeW91IG5lZWQgdG8gcHJvdmlkZSBhIGxpc3Qgb2Ygd2hhdCBzZWN1cml0eSB0 YXNrcyB5b3UgY2FyZSBhYm91dCAKPiBzb21lcGxhY2Ugc28gSSBjYW4gdmVyaWZ5IHRoaXMgZm9y IG15c2VsZi7CoCBBbHNvLCBmb3IgbWFueSBvZiB0aGVzZSB0YXNrcyBpdCAKPiBpcyBuZWNlc3Nh cnkgdG8gb2ZmbG9hZCBldmVuIHdoZW4gdGhleSBjYW4gYmUgZG9uZSBieSB0aGUgZGV2aWNlLiAK PiBPZmZsb2FkaW5nIGF1dGhvcml6YXRpb24gaXMgbm90IHVuY29tbW9uIGV2ZW4gZm9yIGxhcmdl ciBkZXZpY2VzLiAKPgo+ICogSnVzdCBzYXlpbmcgdGhhdCBsaW1pdGF0aW9ucyBhcmUgYSBwcm9i bGVtIGlzIG5vdCBnZW5lcmFsbHkgaGVscGZ1bC7CoCBJdCAKPiB3b3VsZCBiZSBiZXR0ZXIgdG8g bGlzdCBzb21lIG9mIHRoZSByZWFzb25zIGZvciBlYWNoIHNlY3VyaXR5IHRhc2sgeW91IGNhcmUg Cj4gYWJvdXQuwqAgU2luY2UgcGVvcGxlIGFyZSBnb2luZyB0byBuZWVkIHRvIG1ha2UgZGVjaXNp b25zIGFib3V0IHdoYXQgdGhpbmdzIAo+IGNhbiBhbmQgY2Fubm90IGJlIHBsYWNlZCB0b2dldGhl ciBhbmQgaGF2aW5nIHN1Y2ggYSBsaXN0IHdvdWxkIGJlIGhlbHBmdWwgaW4gCj4gdGhhdCByZWdh cmQuIAo+Cj4gKiBEb2luZyBmb3J3YXJkIHJlZmVyZW5jZXMgdG8gZnVsZmlsbCBzb21lIG9mIHRo ZXNlIHJlcXVlc3RzIGlzIHBlcmZlY3RseSAKPiByZWFzb25hYmxlLiAKPgo+IFRlcm1pbm9sb2d5 OiAKPgo+ICrCoCBJIGFtIGNvbXBsZXRlbHkgbG9zdCBieSB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0 aGlzIHNlY3Rpb24uwqAgSXQgbWF5IGJlIAo+IHNpZ25hdHVyZSBzdHJ1Y3R1cmUsIGJ1dCBpdCBp cyBhbHNvIGFuIGlzc3VlIHdpdGggd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgCj4gZm9yIGNs aWVudC1zaWRlIGF1dGhvcml6YXRpb24uIAo+Cj4gKiBTaG91bGQgImVuZHBvaW50IiBiZSBwYXJ0 IG9mIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uPyAKPgo+IEFyY2hpdGVjdHVyZTogCj4KPiAqwqAg SSBoYXZlIGEgcHJvYmxlbSB3aXRoIGJ1bGxldCAjMSAtIEl0IG1heSBiZSBkdWUgdG8gd29ya2lu ZyBpbiBTQUNNIGFuZCAKPiBkZXBlbmRzIG9uIGhvdyBvbmUgZGVmaW5lcyBlbmRwb2ludC7CoCBI b3dldmVyIEkgc2VlIG5vIHJlYXNvbiB0aGF0IGFuIAo+IGVuZHBvaW50IGNhbm5vdCBob3N0IHRo ZSBmdW5jdGlvbmFsaXR5IG9mIEFTIGFuZCBDQVMgYXMgd2VsbCBzbyB0aGlzIGJ1bGxldCAKPiBp cyBub3QgY29tcGxldGUuIAo+Cj4gKsKgIFRoZSB0ZXJtICJjb25zdHJhaW5lZCBsZXZlbCIgcG9w cyB1cCBvdXQgb2YgdGhlIG1pZGRsZSBvZiBub3doZXJlIC0gdGhpcyAKPiByZWFsbHkgbmVlZHMg dG8gYmUgZGVmaW5lZC7CoCBQZXJoYXBzIHRoaXMgc2hvdWxkIGJlIGEgc2VjdGlvbiB0aXRsZSB3 aXRoIGFuZCAKPiBpbnRyb2R1Y3Rpb24gYmVmb3JlIHlvdSBzdGFydC4gCj4KPiAqwqAgVGhlIGlu dHJvZHVjdGlvbiBvZiB0aGUgQ1NBIGRvZXMgbm90IHNlZW0gbG9naWNhbCBpZiBpdCBpcyB0byBo ZWxwIG1ha2UgCj4gcmVxdWVzdHMgb2YgdGhlIFJTLsKgIFRoaXMgbmVlZHMgbW9yZSBqdXN0aWZp Y2F0aW9uLsKgIEkgd291bGQgaGF2ZSB0aG91Z2h0IGl0IAo+IHdhcyB0aGVyZSB0byBjb250cm9s IHRoZSBDIGFuZCB3aGF0IGl0IGRvZXMgd2l0aCB0aGluZ3MuwqDCoCBUaGlzIHNlZW1lZCB0byBi ZSAKPiB0aGUgT2JqZWN0aXZlIHR5cGUgMiBzdGF0ZW1lbnQgZnJvbSBhYm92ZS7CoMKgIElmIHlv dSBhcmUgbWFraW5nIGl0IGEgc3VwcG9ydCAKPiBpdGVtLCB0aGVuIGl0IGRvZXMgbm90IG1ha2Ug c2Vuc2UgZWl0aGVyIHRvIGNhbGwgaXQgYW4gYWNjZXNzIGNvbnRyb2zCoCBwb2ludCAKPiBvciB0 byBzYXkgaXQgaXMgYmVpbmcgY29udHJvbGxlZCBieSB0aGUgUnFQLsKgIEl0IGNvdWxkIGp1c3Qg YXMgZWFzaWx5IGJlIAo+IGVpdGhlciBhIG5ldXRyYWwgcGFydHkgb3IgdGhlIEFTIHRoYXQgaXMg YmVpbmcgdGFsa2VkIHRvLiAKPgo+IEluZm9ybWF0aW9uIEZsb3dzIAo+Cj4gKsKgIEkgZG9uJ3Qg dW5kZXJzdGFuZCB0aGUgcmVhc29uIGZvciBjb21wbGljYXRpbmcgdGhlIGRpYWdyYW0uwqDCoCBI YXZpbmcgaXQgCj4gYmUgdGhlIHNpbXBsZSB2ZXJzaW9uLCBhdCBsZWFzdCBhdCBmaXJzdCBwcmVz ZW50YXRpb24gb2YgZmxvd3MsIG1ha2VzIGl0IAo+IGVhc2llciB0byB1bmRlcnN0YW5kLsKgIFlv dSBjYW4gdGFsayBhYm91dCB0aGUgcmVmbGVjdGlvbiBhdCBhIGxhdGVyIHBvaW50LiAKPgo+ICrC oCBXaHkgZG8geW91IGhhdmUgaW5mb3JtYXRpb24gZmxvd3MgYXMgb25lIGRpcmVjdGlvbmFsIGJl dHdlZW4gQ0FTIGFuZCBDPyAKPgo+IE1pc3NpbmcgQXJjaGl0ZWN0dXJlIGlzc3VlcyAKPgo+ICog V2h5IGRvIHlvdSBub3QgdGFsayBhYm91dCB0aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiBBUyBh bmQgQ0FTIG5vZGVzIGF0IAo+IHRpbWVzIAo+Cj4gKiBTdG9yZSBhbmQgZm9yd2FyZCBzaG91bGQg YmUgZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQuIChpLmUuIGNvbWJpbmF0aW9uIAo+IG9mIHB1 c2ggYW5kIHB1bGwgbW9kZWxzKSAKPgo+ICrCoCBCZXR0ZXIgZGVzY3JpcHRpb24gb2YgdHlwZSAy IHNlY3VyaXR5IG9iamVjdHMgbmVlZHMgdG8gYmUgdW5kZXJ0YWtlbiAtIAo+IHNwZWNpZmljYWxs eSB3aHkgd2Ugd291bGQgY2FyZSBhYm91dCB0aGVtLiAKPgo+IFNlY3VyaXR5IE9iamVjdGl2ZXM6 IAo+Cj4gKsKgIEkgYXNzdW1lIHRoYXQgYWNjZXNzIGlzIGFsc28gYSBzZWN1cml0eSBvYmplY3Qg dGhhdCBpcyBhZGRyZXNzZWQgYnkgCj4gYXV0aG9yaXphdGlvbi4gCj4KPiAqwqAgS2lsbCB0aGUg dGVybSBub24tcmVwdWRpYXRpb24gLSBJIGRvbid0IGtub3cgd2hhdCB0aGlzIG1lYW5zIGFuZCB0 aGVyZSBpcyAKPiBub3QgYSBncmVhdCBkZWFsIG9mIGFncmVlbWVudCBvbiBpdHMgbWVhbmluZy4g Cj4KPiAqIFlvdSBhYnNvbHV0ZWx5IG5lZWQgc29tZSBtZWFzdXJlIG9mIGF1dGhlbnRpY2F0aW9u IGludm9sdmVkLsKgIFRoZSAKPiBwYXJhZ3JhcGggMiBuZWVkcyBoYXZlIGEgY2xlYW5lciBzdGFy dCB0aGF0IHdoYXQgaXQgZG9lcy7CoCBZb3UgcmVhbGx5IG5lZWQgCj4gdG8gdGFsayBhYm91dCBh dXRoZW50aWNhdGlvbiwgYXJlIHlvdSBhdXRoZW50aWNhdGluZyB0aGUgZGV2aWNlIG9yIGFyZSB5 b3UgCj4gYXV0aGVudGljYXRpb24gYW55IGRldmljZSAob3Igc29tZSBzZXQgb2YgZGV2aWNlcykg dGhhdCBhcmUgb3duZWQgYnkgCj4gc29tZWJvZHkuwqAgVGhlc2UgYXJlIGRpZmZlcmVudCBhdXRo ZW50aWNhdGlvbiBtb2RlbHMuIAo+Cj4gKioqKiAKPgo+IEkgYW0gdGlyZWQgYW5kIGdvaW5nIHRv IHN0b3AgYXQgdGhpcyBwb2ludC4gCj4KPiBKaW0gCj4KPgo+Cj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gCj4gQWNlIG1haWxpbmcgbGlzdCAKPiBBY2VA aWV0Zi5vcmcgCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UgCj4K From nobody Tue Jul 21 09:25:48 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 EF7CA1A9062 for ; Tue, 21 Jul 2015 09:25:46 -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 YpRXZqZ5b0QA for ; Tue, 21 Jul 2015 09:25:42 -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 6A7BB1A0110 for ; Tue, 21 Jul 2015 09:25:41 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-5f-55ae728377b6 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.27.29223.3827EA55; Tue, 21 Jul 2015 18:25:39 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.149]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Tue, 21 Jul 2015 18:25:39 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] draft-gerdes-ace-actors Thread-Index: AdDAdsHOyEiElwvbSheqRuDBgdnZgADWx5aA Date: Tue, 21 Jul 2015 16:25:38 +0000 Message-ID: References: <01b001d0c214$fe3bf0e0$fab3d2a0$@augustcellars.com> In-Reply-To: <01b001d0c214$fe3bf0e0$fab3d2a0$@augustcellars.com> 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: text/plain; charset="utf-8" Content-ID: <6710B65BFA168147954627EB34050AC8@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+JvjW5z0bpQg8P3DCy+f+thtjhychqr xerp39kcmD02zpnO5rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZZzZuoq14ENExezjAg2M Z8K6GDk5JARMJO69P8gCYYtJXLi3nq2LkYtDSOAoo8SHzV+gnCWMEj/fNTKCVLEJuEg8aHjE BGKLCLhJnJ28DKybWSBcYsOCp2C2sICWxKqlX6FqtCUerHvLDGEbSaye/okNxGYRUJW48fk9 O4jNK2Ah0bJlFViNkIC9xJxnS1lBbE4BB4lFH++B1TACXff91BomiF3iEreezGeCuFpAYsme 88wQtqjEy8f/wHpFBfQkVl5vYoOIK0msPbwd6DYOoF5NifW79CHGWEv82PaTDcJWlJjS/RDq HEGJkzOfsExglJiFZNsshO5ZSLpnIemehaR7ASPrKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSS TYzAuDy45bfBDsaXzx0PMQpwMCrx8C5YvjZUiDWxrLgy9xCjNAeLkjjvjM15oUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYXT78Cu3/o7GE5YBs91XlP1vKmJhPXxbP3ajd02HuWK2gckzH 0NFMbn56pteSvgIHvulX/kocK2EyPLt9WqXNje7td5/qrm9fwM3vcHVCTevVr5FP+20VVcu1 rs5q9m46FarIrnK555/Zabvjb4VO7jvfE7iiN+iKRdNunZT1lx9e6rqavGa1EktxRqKhFnNR cSIAWBoK8awCAAA= Archived-At: Cc: "draft-gerdes-ace-actors@tools.ietf.org" Subject: Re: [Ace] draft-gerdes-ace-actors X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jul 2015 16:25:47 -0000 SmltLA0KDQpBZ2FpbiwgdGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIHJldmlldyEgU2luY2UgdGhl IGVkaXRvciBvZiB0aGUgZG9jdW1lbnQsDQpDYXJzdGVuLCBoYXMgYmVlbiB2ZXJ5IGJ1c3ksIHRo ZSBvdGhlciBhdXRob3JzIGhhdmUgY29tcGlsZWQgdGhlIGZvbGxvd2luZw0KcmVwbGllcyB0byB5 b3VyIGNvbW1lbnRzLiAoVGhhbmtzIGFsc28gdG8gT2xhZiBmb3IgZ29vZCBpbnB1dC4pDQoNCk9u IDIwMTUtMDctMTkgMTM6MjAsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4g d3JvdGU6DQoNCj5JIGhhdmUgcmVhZCB0aHJvdWdoIHRoaXMgZHJhZnQgYW5kIG15IGZpcnN0IGNv bW1lbnQgaXMgLSBJIGRvbid0DQo+dW5kZXJzdGFuZA0KPndoYXQgdGhpcyBkcmFmdCBpcyB0cnlp bmcgdG8gYWNjb21wbGlzaC4gIE15IGNvbmZ1c2lvbiBiZWdpbnMgaW4gdGhlDQo+c2Vjb25kDQo+ cGFyYWdyYXBoIG9mIHRoZSBhYnN0cmFjdCB3aGVyZSBpdCBzYXlzIHRoYXQgaXQgaXMgcHJvdmlk aW5nICJlbGVtZW50cyBvZg0KPmFuDQo+YXJjaGl0ZWN0dXJlIC8gYSBwcm9ibGVtIHN0YXRlbWVu dCIuDQo+DQo+VGhlIGlkZWEgb2YgcHJvdmlkaW5nIHRlcm1pbm9sb2d5IGlzIHJlYXNvbmFibGUg LSBhbHRob3VnaCBJIGdlbmVyYWxseQ0KPmRvbid0DQo+YmVsaWV2ZSB0aGF0IGEgc3RhbmRhbG9u ZSBkb2N1bWVudCBpcyBhIGdvb2QgcGxhY2UgdG8gZG8gc28gdW5sZXNzIHlvdSBhcmUNCj5kb2lu ZyBhIGxvdCBvZiBkZWZpbml0aW9ucy4gIEFuZCBmb3IgdGhlIG1vc3QgcGFydCB5b3UganVzdCB1 c2UgdGhlIHNhbWUNCj5vbmVzIGFzIE9BdXRoIGlzIHVzaW5nLiAgIEkgY2FuIHNlZSBwcm92aWRp bmcgYW4gYXJjaGl0ZWN0dXJlIHRoYXQgaXMNCj5nb2luZw0KPnRvIGJlIHJlYXNvbmFibGUgY29t cGxldGUgb3IgYSBwcm9ibGVtIHN0YXRlbWVudC4gIEJ1dCBkb2luZyBqdXN0IGVsZW1lbnRzDQo+ b2YgdGhvc2UgaXMgbm90IHVzZWZ1bC4gIEhvdyBpcyBvbmUgdG8gZXZhbHVhdGUgYW55dGhpbmcg YWdhaW5zdCBpdCBpZg0KPmp1c3QNCj5waWVjZXMgYXJlIGdpdmVuIGJ1dCBub3QgYW55dGhpbmcg cmVwcmVzZW50aW5nIGEgY29tcGxldGUgcGljdHVyZS4NCg0KVGhlIGludGVudGlvbiB3YXMgdGhh dCBub3Qgb25seSBzb21lIGVsZW1lbnRzIGJ1dCAiYWxsIHRoZSBlbGVtZW50cyBhbg0KYWN0dWFs IA0KQXJjaGl0ZWN0dXJlIGNhbiBjb21wcmlzZSBvZuKAnS4gV2UgY2hhbmdlIHRoaXMuDQoNCj4N Cj5JbnRyb2R1Y3Rpb246DQo+DQo+KiBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSBub3QgdGhlIG9u bHkgb25lcyBmb3Igd2hpY2ggQUNMcyBhcmUgbm90DQo+c3VmZmljaWVudGx5IGdlbmVyaWMuICBU aGVyZSBhcmUgbG90cyBvZiBwbGFjZXMgd2hlcmUgZG9pbmcgYWNjZXNzIGNvbnRyb2wNCj5pcyBv ZmYtbG9hZGVkIGZyb20gYSBkZXZpY2UgdG8gYW5vdGhlciBzeXN0ZW0uICBFdmVuIHdpdGggQUNM cyB5b3UgbmVlZCB0bw0KPmRpc2N1c3MgaG93IGF1dGhvcml6YXRpb24gd291bGQgYmUgZGVhbHQg d2l0aC4gICBUaGlzIHN0YXRlbWVudCBjb3VsZCBiZQ0KPm11Y2ggY2xlYXJlci4NCg0KQWNjZXNz IGNvbnRyb2wgbGlzdHMgaXMgbWVudGlvbmVkIGluIG1vcmUgdGhhbiBvbmUgcGxhY2UsIGV4YWN0 bHkgd2hpY2gNCnN0YXRlbWVudCBhcmUgeW91IHJlZmVycmluZyB0byAob3IgaXMgaXQgdGhlIHdo b2xlIHBhcmFncmFwaCk/DQoNClRoZSBwb2ludCB3ZSBhcmUgdHJ5aW5nIHRvIG1ha2UgaXMgdGhh dCB0aGUgdXNlIG9mIHN0YXRpYyBhdXRob3Jpc2F0aW9uDQpkb2VzIG5vdCBzdWl0IGFsbCB1c2Ug Y2FzZXMgaW4gcGFydGljdWxhciBkdWUgdG8gdGhlIG5hdHVyZSBvZiBjb25zdHJhaW5lZA0KZGV2 aWNlIGRlcGxveW1lbnRzIHdpdGggYnVpbHQtaW4gZGV2aWNlcywgbG9uZyBkZXBsb3ltZW50IHRp bWVzIGV0Yy4sIGFuZA0KdGhlcmVmb3JlIGVzcGVjaWFsbHkgaW4gdGhpcyBjYXNlIHdlIG5lZWQg dG8gY29uc2lkZXIgZHluYW1pYyB1cGRhdGVzIG9mDQphdXRob3JpemF0aW9uIHBvbGljaWVzLg0K DQoNCg0KPg0KPiogIElmIHlvdSBhcmUgZ29pbmcgdG8gdGVsbCBtZSB0aGF0IHRoZXJlIGFyZSBz ZWN1cml0eSB0YXNrcyB0aGF0IGNhbm5vdA0KPmJlDQo+ZG9uZSwgeW91IG5lZWQgdG8gcHJvdmlk ZSBhIGxpc3Qgb2Ygd2hhdCBzZWN1cml0eSB0YXNrcyB5b3UgY2FyZSBhYm91dA0KPnNvbWVwbGFj ZSBzbyBJIGNhbiB2ZXJpZnkgdGhpcyBmb3IgbXlzZWxmLg0KDQoNClBvaW50IHRha2VuLiBXZSB3 aWxsIGFkZCBzb21lIGV4YW1wbGVzIGFuZCByZWZlcmVuY2UgYW5vdGhlciBkcmFmdCB0aGF0DQp3 aWxsIHNwZWNpZnkgdGFza3MgaW4gZGV0YWlsICh0byBiZSB3cml0dGVuKS4NCg0KDQoNCj5BbHNv LCBmb3IgbWFueSBvZiB0aGVzZSB0YXNrcyBpdA0KPmlzIG5lY2Vzc2FyeSB0byBvZmZsb2FkIGV2 ZW4gd2hlbiB0aGV5IGNhbiBiZSBkb25lIGJ5IHRoZSBkZXZpY2UuDQo+T2ZmbG9hZGluZyBhdXRo b3JpemF0aW9uIGlzIG5vdCB1bmNvbW1vbiBldmVuIGZvciBsYXJnZXIgZGV2aWNlcy4NCg0KVHJ1 ZS4gVGhlcmUgbWF5IHZhcmlvdXMgcmVhc29ucyBmb3Igb2ZmbG9hZGluZy4gV2Ugc2hvdWxkIHJl cGhyYXNlIHRoaXMNCnRleHQgdG8gcmVmbGVjdA0KdGhhdGMuDQoNCg0KDQo+DQo+KiBKdXN0IHNh eWluZyB0aGF0IGxpbWl0YXRpb25zIGFyZSBhIHByb2JsZW0gaXMgbm90IGdlbmVyYWxseSBoZWxw ZnVsLiAgSXQNCj53b3VsZCBiZSBiZXR0ZXIgdG8gbGlzdCBzb21lIG9mIHRoZSByZWFzb25zIGZv ciBlYWNoIHNlY3VyaXR5IHRhc2sgeW91DQo+Y2FyZQ0KPmFib3V0LiAgU2luY2UgcGVvcGxlIGFy ZSBnb2luZyB0byBuZWVkIHRvIG1ha2UgZGVjaXNpb25zIGFib3V0IHdoYXQgdGhpbmdzDQo+Y2Fu IGFuZCBjYW5ub3QgYmUgcGxhY2VkIHRvZ2V0aGVyIGFuZCBoYXZpbmcgc3VjaCBhIGxpc3Qgd291 bGQgYmUgaGVscGZ1bA0KPmluDQo+dGhhdCByZWdhcmQuDQoNCk9LLiBUaGUgdGFzayBkZXNjcmlw dGlvbiBtZW50aW9uZWQgcHJldmlvdXNseSBzaG91bGQgYWRkcmVzcyB0aGlzIGNvbW1lbnQNCnRv by4NCg0KDQoNCj4NCj4qIERvaW5nIGZvcndhcmQgcmVmZXJlbmNlcyB0byBmdWxmaWxsIHNvbWUg b2YgdGhlc2UgcmVxdWVzdHMgaXMgcGVyZmVjdGx5DQo+cmVhc29uYWJsZS4NCg0KT0suDQoNCj4N Cj5UZXJtaW5vbG9neToNCj4NCj4qICBJIGFtIGNvbXBsZXRlbHkgbG9zdCBieSB0aGUgbGFzdCBz ZW50ZW5jZSBpbiB0aGlzIHNlY3Rpb24uICBJdCBtYXkgYmUNCj5zaWduYXR1cmUgc3RydWN0dXJl LCBidXQgaXQgaXMgYWxzbyBhbiBpc3N1ZSB3aXRoIHdoYXQgeW91IGFyZSB0YWxraW5nDQo+YWJv dXQNCj5mb3IgY2xpZW50LXNpZGUgYXV0aG9yaXphdGlvbi4NCg0KT0ssIHdlIHNob3VsZCBjbGFy aWZ5IHRoaXMgcGFyYWdyYXBoLg0KDQoNCg0KPg0KPiogU2hvdWxkICJlbmRwb2ludCIgYmUgcGFy dCBvZiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbj8NCg0KWWVzLiBUaGlzIGlzIGRlZmluZWQgaW4g UkZDNzI1Miwgc28gc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0IG9mIHRlcm1zDQpyZWZlcmVu Y2VkIGluIGZyb20gdGhhdC4NCg0KDQoNCj4NCj5BcmNoaXRlY3R1cmU6DQo+DQo+KiAgSSBoYXZl IGEgcHJvYmxlbSB3aXRoIGJ1bGxldCAjMSAtIEl0IG1heSBiZSBkdWUgdG8gd29ya2luZyBpbiBT QUNNIGFuZA0KPmRlcGVuZHMgb24gaG93IG9uZSBkZWZpbmVzIGVuZHBvaW50LiAgSG93ZXZlciBJ IHNlZSBubyByZWFzb24gdGhhdCBhbg0KPmVuZHBvaW50IGNhbm5vdCBob3N0IHRoZSBmdW5jdGlv bmFsaXR5IG9mIEFTIGFuZCBDQVMgYXMgd2VsbCBzbyB0aGlzDQo+YnVsbGV0DQo+aXMgbm90IGNv bXBsZXRlLg0KDQoNClJpZ2h0LCB3ZSBjaGFuZ2UgdGhhdC4NCg0KCQkJCQkNCk9MRA0KbyAgQW4g ZW5kcG9pbnQgbWF5IGhvc3QgZnVuY3Rpb25hbGl0eSBvZiBDLCBSUyBvciBib3RoIEMgYW5kIFJT Lg0KDQpORVcNCgkNCgkJDQoJCQ0KCQ0KCQ0KCQkNCgkJCQ0KCQkJCQ0KCQkJCQkNCgkJCQkJCSAg IG8gIEFuIGVuZHBvaW50IG1heSBob3N0IGZ1bmN0aW9uYWxpdHkgb2Ygb25lIG9yIG1vcmUgYWN0 b3JzLg0KDQoNCg0KDQo+DQo+KiAgVGhlIHRlcm0gImNvbnN0cmFpbmVkIGxldmVsIiBwb3BzIHVw IG91dCBvZiB0aGUgbWlkZGxlIG9mIG5vd2hlcmUgLQ0KPnRoaXMNCj5yZWFsbHkgbmVlZHMgdG8g YmUgZGVmaW5lZC4gIFBlcmhhcHMgdGhpcyBzaG91bGQgYmUgYSBzZWN0aW9uIHRpdGxlIHdpdGgN Cj5hbmQNCj5pbnRyb2R1Y3Rpb24gYmVmb3JlIHlvdSBzdGFydC4NCg0KR29vZCBjYXRjaC4gV2Ug d2lsbCBtYWtlIGEgZm9yd2FyZCByZWZlcmVuY2Ugd2hlcmUgYm90aCB0aGUgdGVybSBhbmQgaXRz DQpzZWN1cml0eSBvYmplY3RpdmVzIGFyZSBkZXNjcmliZWQuDQoNCj4NCj4qICBUaGUgaW50cm9k dWN0aW9uIG9mIHRoZSBDU0EgZG9lcyBub3Qgc2VlbSBsb2dpY2FsIGlmIGl0IGlzIHRvIGhlbHAg bWFrZQ0KPnJlcXVlc3RzIG9mIHRoZSBSUy4gIFRoaXMgbmVlZHMgbW9yZSBqdXN0aWZpY2F0aW9u LiAgSSB3b3VsZCBoYXZlIHRob3VnaHQNCj5pdA0KPndhcyB0aGVyZSB0byBjb250cm9sIHRoZSBD IGFuZCB3aGF0IGl0IGRvZXMgd2l0aCB0aGluZ3MuICAgVGhpcyBzZWVtZWQgdG8NCj5iZQ0KPnRo ZSBPYmplY3RpdmUgdHlwZSAyIHN0YXRlbWVudCBmcm9tIGFib3ZlLiAgIElmIHlvdSBhcmUgbWFr aW5nIGl0IGENCj5zdXBwb3J0DQo+aXRlbSwgdGhlbiBpdCBkb2VzIG5vdCBtYWtlIHNlbnNlIGVp dGhlciB0byBjYWxsIGl0IGFuIGFjY2VzcyBjb250cm9sDQo+cG9pbnQNCj5vciB0byBzYXkgaXQg aXMgYmVpbmcgY29udHJvbGxlZCBieSB0aGUgUnFQLiAgSXQgY291bGQganVzdCBhcyBlYXNpbHkg YmUNCj5laXRoZXIgYSBuZXV0cmFsIHBhcnR5IG9yIHRoZSBBUyB0aGF0IGlzIGJlaW5nIHRhbGtl ZCB0by4NCg0KDQpUaGUgQ0FTIGhhcyBib3RoIHRoZSBzdXBwb3J0IGFuZCBjb250cm9sIGZ1bmN0 aW9uLiBXZSB3aWxsIGV4cGxhaW4gdGhpcw0KYmV0dGVyLg0KDQoNCg0KDQo+DQo+SW5mb3JtYXRp b24gRmxvd3MNCj4NCj4qICBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHJlYXNvbiBmb3IgY29tcGxp Y2F0aW5nIHRoZSBkaWFncmFtLiAgIEhhdmluZyBpdA0KPmJlIHRoZSBzaW1wbGUgdmVyc2lvbiwg YXQgbGVhc3QgYXQgZmlyc3QgcHJlc2VudGF0aW9uIG9mIGZsb3dzLCBtYWtlcyBpdA0KPmVhc2ll ciB0byB1bmRlcnN0YW5kLiAgWW91IGNhbiB0YWxrIGFib3V0IHRoZSByZWZsZWN0aW9uIGF0IGEg bGF0ZXIgcG9pbnQuDQoNClRoZSBwdXJwb3NlIG9mIHRoaXMgcGljdHVyZSB3YXMgdG8gZW1waGFz aXplIHRoYXQgdGhlIGVuZHBvaW50cyBjYW4gaW4NCmdlbmVyYWwgaG9zdCBib3RoIGNsaWVudCBh bmQgc2VydmVyIGZ1bmN0aW9uYWxpdHksIGJ1dCB0aGlzIGlzIGFscmVhZHkNCmV4cGxhaW5lZCBp biB0ZXh0IHNvIEkgYWdyZWUgaXQgY2FuIGJlIG9taXR0ZWQuIFdlIHdpbGwgcmVtb3ZlIHRoZQ0K cmVmbGVjdGlvbiBmcm9tIHRoZSBmaWd1cmUuDQoNCg0KPg0KPiogIFdoeSBkbyB5b3UgaGF2ZSBp bmZvcm1hdGlvbiBmbG93cyBhcyBvbmUgZGlyZWN0aW9uYWwgYmV0d2VlbiBDQVMgYW5kIEM/DQoN Cg0KVGhlIGZpZ3VyZSBpcyBpbnRlbmRlZCB0byBpbGx1c3RyYXRlLCBvbiBhIGhpZ2ggbGV2ZWws IHRoZSByZWxldmFudA0KaW5mb3JtYXRpb24gZmxvd3Mgd2l0aCBjb25zdHJhaW5lZCBkZXZpY2Vz IGluIHNjb3BlIG9mIEFDRS4gVGhlc2UNCmluZm9ybWF0aW9uIGZsb3dzIGNhbiBiZSByZWFsaXNl ZCB3aXRoIGRpZmZlcmVudCBwcm90b2NvbHMgc28gdGhlIGFjdHVhbA0KbWVzc2FnZSBmbG93IGJl dHdlZW4gdGhlIGFjdG9ycyBtYXkgYmUgZGlmZmVyZW50LCB3ZSBzaG91bGQgZXhwbGFpbiB0aGlz DQpiZXR0ZXIgaW4gdGhlIHRleHQuIEJ1dCBhbHRob3VnaCB0aGVyZSBtYXkgYmUgcmVxdWVzdHMg Z29pbmcgZnJvbSBDIHRvDQpDQVMsIHRoZSBjb250cm9sIGluZm9ybWF0aW9uIGNhcnJpZWQgaW4g dGhlIHJlc3BvbnNlIGluIHRoYXQgY2FzZSBpcyB0aGUNCmluZm9ybWF0aW9uIG9mIGludGVyZXN0 IGhlcmUsIGFuZCB0aGlzIGlzIHRoZSByZWFzb24gZm9yIG9ubHkgc2hvd2luZw0KaW5mb3JtYXRp b24gZmxvdyBpbiBvbmUgZGlyZWN0aW9uLg0KDQoNCihUaGlzIGRpZmZlcnMgZnJvbSBteSBwcmV2 aW91cyBhbnN3ZXIgdG8gdGhlIGRyYWZ0IGFzIGluZGl2aWR1YWwgYXV0aG9yLikNCg0KDQoNCj4N Cj5NaXNzaW5nIEFyY2hpdGVjdHVyZSBpc3N1ZXMNCj4NCj4qIFdoeSBkbyB5b3Ugbm90IHRhbGsg YWJvdXQgdGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgQVMgYW5kIENBUyBub2RlcyBhdA0KPlRp bWVzDQoNCkRvIHlvdSBtZWFuIHRoZSBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5IGFzcGVjdCwg aS5lLiB0aGF0IHRoZSBDQVMgb3IgQVMNCm1heSBub3QgYXZhaWxhYmxlIGZyb20gdGhlIHJlc3Bl Y3RpdmUgY29uc3RyYWluZWQgbm9kZXMgYXQgdGltZXM/DQoNCg0KDQo+DQo+KiBTdG9yZSBhbmQg Zm9yd2FyZCBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQuIChpLmUuDQo+Y29t YmluYXRpb24NCj5vZiBwdXNoIGFuZCBwdWxsIG1vZGVscykNCg0KDQpTdG9yZSBhbmQgZm9yd2Fy ZCBpcyBtZW50aW9uZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0LCBzZWN0aW9uIDIuNS4zLg0KKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS11c2VjYXNlcy0wNCNzZWN0 aW9uLTIuNS4zKQ0KV2hhdCBhc3BlY3Qgb2YgdGhhdCBkbyB5b3UgdGhpbmsgc2hvdWxkIGJlIGRp c2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50Pw0KDQoNCg0KPg0KPiogIEJldHRlciBkZXNjcmlwdGlv biBvZiB0eXBlIDIgc2VjdXJpdHkgb2JqZWN0cyBuZWVkcyB0byBiZSB1bmRlcnRha2VuIC0NCj5z cGVjaWZpY2FsbHkgd2h5IHdlIHdvdWxkIGNhcmUgYWJvdXQgdGhlbS4NCg0KV2Ugd2lsbCBwcm92 aWRlIGFuIGV4YW1wbGUgdG8gaWxsdXN0cmF0ZSB3aHkgdGhpcyBpcyB1c2VmdWwuDQoNCg0KDQo+ DQo+U2VjdXJpdHkgT2JqZWN0aXZlczoNCj4NCj4qICBJIGFzc3VtZSB0aGF0IGFjY2VzcyBpcyBh bHNvIGEgc2VjdXJpdHkgb2JqZWN0IHRoYXQgaXMgYWRkcmVzc2VkIGJ5DQo+YXV0aG9yaXphdGlv bi4NCg0KSXMgdGhpcyBpbiB0aGUgY29udGV4dCBvZiB0aGUgc2VjdXJpdHkgb2JqZWN0aXZlcywg c2VjdGlvbiAyLjE/IEFyZSB5b3UNCnJlZmVycmluZyB0byDigJxhdmFpbGFiaWxpdHnigJ0gaW4g dGhlIHNlbnNlIG9mIGVuc3VyZSB0aGF0IGVudGl0aWVzIHRoYXQgYXJlDQplbnRpdGxlZCB0byBn ZXQgYWNjZXNzIGRvIGdldCBhY2Nlc3M/DQoNCg0KDQo+DQo+KiAgS2lsbCB0aGUgdGVybSBub24t cmVwdWRpYXRpb24gLSBJIGRvbid0IGtub3cgd2hhdCB0aGlzIG1lYW5zIGFuZCB0aGVyZQ0KPmlz DQo+bm90IGEgZ3JlYXQgZGVhbCBvZiBhZ3JlZW1lbnQgb24gaXRzIG1lYW5pbmcuDQoNCk9LLCB3 ZSByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byBub24tcmVwdWRpYXRpb24uIFRoaXMgaXMgbm90IGNl bnRyYWwgaW4gdGhlDQpjdXJyZW50IGRyYWZ0Lg0KDQoNCg0KPg0KPiAqIFlvdSBhYnNvbHV0ZWx5 IG5lZWQgc29tZSBtZWFzdXJlIG9mIGF1dGhlbnRpY2F0aW9uIGludm9sdmVkLiAgVGhlDQo+cGFy YWdyYXBoIDIgbmVlZHMgaGF2ZSBhIGNsZWFuZXIgc3RhcnQgdGhhdCB3aGF0IGl0IGRvZXMuICBZ b3UgcmVhbGx5IG5lZWQNCj50byB0YWxrIGFib3V0IGF1dGhlbnRpY2F0aW9uLCBhcmUgeW91IGF1 dGhlbnRpY2F0aW5nIHRoZSBkZXZpY2Ugb3IgYXJlIHlvdQ0KPmF1dGhlbnRpY2F0aW9uIGFueSBk ZXZpY2UgKG9yIHNvbWUgc2V0IG9mIGRldmljZXMpIHRoYXQgYXJlIG93bmVkIGJ5DQo+c29tZWJv ZHkuICBUaGVzZSBhcmUgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIG1vZGVscy4NCg0KDQpJbiBz ZWN0aW9uIDQgd2UgZWxhYm9yYXRlIG9uIHdoYXQgaXMgYmVpbmcgYXV0aGVudGljYXRlZC4gVGhl IGludGVudGlvbiBpcw0Kbm90IHRvIGRlZmluZSB3aGF0IGlzIGJlaW5nIGF1dGhlbnRpY2F0ZWQg YnV0IGFsbG93IGRpZmZlcmVudA0KYXBwcm9hY2hlcyBmb3IgZGlmZmVyZW50IHVzZSBjYXNlcy4g V2Ugc2hvdWxkIGVpdGhlciBtZW50aW9uIHRoYXQgaGVyZSBvcg0KbWFrZSBhIGZvcndhcmQgcmVm ZXJlbmNlIGZyb20gcGFyYWdyYXBoIDIgaW4gc2VjdGlvbiAzIHRvIHNlY3Rpb24gNC4NCldvdWxk IHRoYXQgYWRkcmVzcyB5b3VyIHF1ZXN0aW9uPw0KDQoNCg0KDQpHw7ZyYW4NCg0K From nobody Wed Jul 22 06:25: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 5653E1B3363 for ; Wed, 22 Jul 2015 06:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6u1VbbJF58l2 for ; Wed, 22 Jul 2015 06:25:39 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA381B3364 for ; Wed, 22 Jul 2015 06:25:16 -0700 (PDT) Received: from hebrews (dhcp-a241.meeting.ietf.org [31.133.162.65]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 742042CA06; Wed, 22 Jul 2015 06:25:15 -0700 (PDT) From: "Jim Schaad" To: "'Michael Richardson'" References: <002301d0bf36$4af258c0$e0d70a40$@augustcellars.com> <16164.1437069756@sandelman.ca> In-Reply-To: <16164.1437069756@sandelman.ca> Date: Wed, 22 Jul 2015 15:25:35 +0200 Message-ID: <004c01d0c481$e5a845a0$b0f8d0e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJupdTtOQBM6kMH/1aENzxleA0T0QGwrVD+nJ4yWrA= Content-Language: en-us Archived-At: Cc: draft-ietf-ace-usecases@tools.ietf.org, ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-usecases X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jul 2015 13:25:40 -0000 > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of > Michael Richardson > Sent: Thursday, July 16, 2015 8:03 PM > To: Jim Schaad > Cc: draft-ietf-ace-usecases@tools.ietf.org; ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-usecases > > > Jim Schaad wrote: > > Section 2.1 -Is it important that vendors have "real-time" information > on > > the state of the container or is it sufficient to have post-mortem > dumps? > > Also is it the vendor or the transporter that needs to have some of this > > information - since the transporter has a better chance to detect and > > fix a problem in transit that the vendor. > > My understanding is that both are relevant. > > While the container is on a boat, potentially out of range of the vendor, the > transporter must get real-time data so that they can fix things. > > But, in addition, when the container gets to port, the vendor would still like > a dump, as they may well take more different action. For instance, perhaps > the bananas in that container are still saleable (despite the AC breaking, and > the transporter fixing it later that day), but need to be consumed earlier. > > And then there is the eventual post-mordem: why did the AC fail. > > > Section 2.2 - Do you want to add a case of a child and notification to > > Alice > > and Bob when the child arrives home at the end of the school day? > > [and: what would Alice and Bob name their child? :-) Now I understand why > Alice and Bob were so anxious that their (love) notes remain private...] > Given that the child is probably a teenager by now, its name is Mallory. Don't know the sex. Jim > > -- > Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting =- > > From nobody Wed Jul 22 09:58: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 2F8751A8BC5 for ; Wed, 22 Jul 2015 09:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.38 X-Spam-Level: * X-Spam-Status: No, score=1.38 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] 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 9d1P5LZpZrJ6 for ; Wed, 22 Jul 2015 09:58:33 -0700 (PDT) Received: from smtpdb11.aruba.it (smtpdb11.aruba.it [62.149.158.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9891A9029 for ; Wed, 22 Jul 2015 09:58:30 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd04.ad.aruba.it with bizsmtp id vUy11q00A2NEPrz01Uy27t; Wed, 22 Jul 2015 18:58:02 +0200 Date: Wed, 22 Jul 2015 18:58:03 +0200 (CEST) From: Meetecho Team To: ace@ietf.org Message-ID: <164854226.15.1437584283063.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14_2024320121.1437584283061" Archived-At: Subject: [Ace] Meetecho recordings of ACE WG session X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:58:35 -0000 ------=_Part_14_2024320121.1437584283061 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the ACE WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#ACE In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_14_2024320121.1437584283061-- From nobody Thu Jul 23 11:09: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 635951B2B10 for ; Thu, 23 Jul 2015 11:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 SUsvRJ404IP8 for ; Thu, 23 Jul 2015 11:09:47 -0700 (PDT) Received: from mx08-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43A11B2AD6 for ; Thu, 23 Jul 2015 11:09:03 -0700 (PDT) Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.14.5/8.14.5) with SMTP id t6NI32BF011724; Thu, 23 Jul 2015 20:09:01 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 1vt7qbrh8w-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2015 20:09:01 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C6D1031; Thu, 23 Jul 2015 18:08:59 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas4.st.com [10.75.90.69]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 825ECA4E0; Thu, 23 Jul 2015 18:08:59 +0000 (GMT) Received: from Safex1mail3.st.com ([fe80::e48c:97a7:3b08:899e]) by safex1hubcas4.st.com ([::1]) with mapi; Thu, 23 Jul 2015 20:08:59 +0200 From: Malisa VUCINIC To: "bergmann@tzi.org" Date: Thu, 23 Jul 2015 20:08:57 +0200 Thread-Topic: '2%' use-cases for object security Thread-Index: AdDFb5FerR3UeKSMQKyxzPnkThqIAQ== Message-ID: <903544800BDD1447BA9BDF3288CF0A0A0168D4F880@SAFEX1MAIL3.st.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_903544800BDD1447BA9BDF3288CF0A0A0168D4F880SAFEX1MAIL3st_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-23_09:2015-07-22,2015-07-23,1970-01-01 signatures=0 Archived-At: Cc: "ace@ietf.org" Subject: [Ace] '2%' use-cases for object security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 18:09:50 -0000 --_000_903544800BDD1447BA9BDF3288CF0A0A0168D4F880SAFEX1MAIL3st_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello Olaf, Just wanted to follow up on the discussion we had during the WG meeting yes= terday. Arguing that a solution purely based on DTLS is an approach for 'future' bo= thers me very much. If that were the case, we wouldn't be having nightmares= in deploying CDNs, making people share the same private key on multiple ma= chines, or create fake certificates to get (D)TLS 'working' in scenarios th= at span from point-to-point request-response. To get back to the constrained world, I believe you concur with the fact th= at most of the existing WSN deployments either have a gateway with applicat= ion level processing or gateway running a CoAP proxy. It seems this is goin= g to stay there for a while. Other people may have input here as well. You = seemed to be implying that we should not care about that too much? The '2 %' use-cases you indicated for object security may be comprised of: - IoT devices talking to the Cloud, where from secured readings may be forw= arded and decrypted/verified end-to-end; - any sort of group communication; - CDNs with secured IoT data; - payments using NFC or similar technology involving intermittent connectiv= ity; - pub/sub brokers and communication over a proxy. Unfortunately, I don't have data to support your claim that some of these e= xamples really do correspond to the 2%. If you do, it would be great if you= could share. Regards, Mali=B9a --_000_903544800BDD1447BA9BDF3288CF0A0A0168D4F880SAFEX1MAIL3st_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello Olaf,

 

Just wanted to follow up on the discussion we had during the WG meeting ye= sterday.

<= o:p> 

Argui= ng that a solution purely based on DTLS is an approach for ‘future= 217; bothers me very much. If that were the case, we wouldn’t be havi= ng nightmares in deploying CDNs, making people share the same private key o= n multiple machines, or create fake certificates to get (D)TLS ‘worki= ng' in scenarios that span from point-to-point request-response.=

 

To get back to the constr= ained world, I believe you concur with the fact that most of the existing W= SN deployments either have a gateway with application level processing or g= ateway running a CoAP proxy. It seems this is going to stay there for a whi= le. Other people may have input here as well. You seemed to be implying tha= t we should not care about that too much?

 

The ‘2 %' use-cases you indicated for obje= ct security may be comprised of:

- IoT devices talking to the Cloud, where from secure= d readings may be forwarded and decrypted/verified end-to-end; <= /span>

- any sort of group co= mmunication;

- CDNs with secured IoT data;

- payments using NFC or similar technology involving= intermittent connectivity;

- pub/sub brokers and communication over a proxy.

 

Unfortunately, I don= 217;t have data to support your claim that some of these examples really do= correspond to the 2%. If you do, it would be great if you could share.

 

Regards,

Mali=B9a<= /span>

 

= --_000_903544800BDD1447BA9BDF3288CF0A0A0168D4F880SAFEX1MAIL3st_-- From nobody Thu Jul 23 16:58: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 6232E1ACE87 for ; Thu, 23 Jul 2015 16:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MSGID_FROM_MTA_HEADER=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 0qrPZXAMTIS8 for ; Thu, 23 Jul 2015 16:58:05 -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 B35841ACE05 for ; Thu, 23 Jul 2015 16:58: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t6NNw2Hj016532; Fri, 24 Jul 2015 01:58:02 +0200 (CEST) Message-Id: <201507232358.t6NNw2Hj016532@mailhost.informatik.uni-bremen.de> Received: from [192.168.11.105] (mucha.avetravel.cz [77.240.96.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mcrFj6Y0JzDM6P; Fri, 24 Jul 2015 01:58:01 +0200 (CEST) Date: Fri, 24 Jul 2015 01:57:59 +0200 From: Stefanie Gerdes To: ludwig@sics.se MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: ace@ietf.org Subject: [Ace] Acre X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 23:58:06 -0000 SGkgTHVkd2lnLAoKQXQgdGhlIGVuZCBvZiB0aGUgQUNFIHNlc3Npb24geWVzdGVyZGF5IHlvdSBz YWlkIHRoYXQgb25lIG9mIHRoZSBtb2RlbHMgeW91IGFyZSBkZXNjcmliaW5nIGluIHlvdXIgbmV3 IGF1dGhvcml6YXRpb24gZHJhZnQgaXMgbW9zdGx5IERDQUYgYW5kIG9ubHkgZGlmZmVycyBpbiB2 ZXJ5IHNtYWxsIGRldGFpbHMuIEkgd2FzIHdvbmRlcmluZyB3aHkgeW91IGFyZSBub3QgcG9pbnRp bmcgdGhhdCBvdXQgaW4geW91ciBkcmFmdC4gSSB0aGluayBpdCB3aWxsIGJlIGxlc3MgY29uZnVz aW5nIGZvciBwZW9wbGUuCgpWaWVsZSBHcsO8w59lClN0ZWZmaQ== From nobody Fri Jul 24 00:52: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 12B281B3014 for ; Fri, 24 Jul 2015 00:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FGgHCzd6NHHN for ; Fri, 24 Jul 2015 00:52:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 EC6601B3015 for ; Fri, 24 Jul 2015 00:51:56 -0700 (PDT) Received: from [192.168.10.141] ([62.168.35.68]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MgGDK-1ZXKpT0fuY-00NjX4; Fri, 24 Jul 2015 09:51:54 +0200 Message-ID: <55B1EE96.5090403@gmx.net> Date: Fri, 24 Jul 2015 09:51:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stefanie Gerdes , ludwig@sics.se References: <201507232358.t6NNw2Hj016532@mailhost.informatik.uni-bremen.de> In-Reply-To: <201507232358.t6NNw2Hj016532@mailhost.informatik.uni-bremen.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fMjGoEFSObARLj2J14uhe6d4OwXO9nMw2" X-Provags-ID: V03:K0:Rew4TjVGzjzFFXnwSieSzmp5h3aMY3Cdg/Pu58PORlhp9DYyS5v 4FOgtBcOrKSsvbDG9QoRSsqQwYr52bZo3sOO6VYa+s6XvkbLdUReEiDzhJOFk9cqFr61XNo UuRoccuOYOlSXkO4xaqzgB3iVa3WXLZKzJW0A1xr2r4aQeKb+U/E9ONlC/LhhedIVkIME+H 9uw54QYKIKwYO1GEqaNpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:LCZmQ4WL//Y=:CP71tb1DN+rzCfJbBZ2fA/ PY05psJaOK852U5zHkpVJ82AQsFGZg7L3qBLCtAq39ju2j3kM2lRL8qbzXGkWI0kJnOzU5E7d EYt2HyTYB0wvSC0oE1EoLA4ob6EzLP0FJfYYEhq12PE5Xf9UHxltvQjsCH+PkPMK+20GtBmYW SaFYWD6WNkYIVpQygyAKMipX1q0Ro0Lq95IQtBUzVB8VfJex4RjDZ7hBMyl5K72GfQxPcWyUj IpWGn5A8u8oTRJjeh9DzBQF2KUOiwoK0XwcllKHJxiSILoSYwOrPZPaWH8NMZl+pw4ESYRC+A Suc/nOdUbtMeYWvPFzVpKSg8RRFAl2PS0uoQcaeKgE/pZmlS4rW/3fJhVhWodl9IuPpTNH7Ps Qdv98rMDJ4NdgyUYYpb6Bfm6pzt1uYeGNDbBcFAr4OjbQVtC6gmZhDi9KB4WviRmrXcjMBCO/ pfyA3GgtuGznTP0lBwfv1lHdks5WBCgYYSkJdw0RI1XdwJzcJBIsi3kC8+6J+QE60Muaj9eq7 uPAfXT2CkUxvrSyJ3k7+6KdsdImi2lZFgXm5CUJN66x0eUs8+JmOeywQwkPDP0y56t3G42j0x JAw0tL4lHdOcniV7MI7uS51JTIbhJT0g6C/lpN36p23p1KfCAFCJ/cadeF8Vvl26Fprcg7tDA 6YSY23C7JCloUbxVIXMJZI+zVrvF/2BkgV2yhQzv0uJi9lQ== Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Acre X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 07:52:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fMjGoEFSObARLj2J14uhe6d4OwXO9nMw2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Steffi, On 07/24/2015 01:57 AM, Stefanie Gerdes wrote: > At the end of the ACE session yesterday you said that one of the models= you are describing in your new authorization draft is mostly DCAF and on= ly differs in very small details. I was wondering why you are not pointin= g that out in your draft. I think it will be less confusing for people. I am not sure where you are heading with this question. I fear that others might easily argue why you aren't referencing their spec either. I believe the point raised with several drafts is the following: there are various communication models in use today. - Do we need all of them? - Do we need to select a few of them? - For a given model do we care much about the message names or details in encoding? Ciao Hannes --fMjGoEFSObARLj2J14uhe6d4OwXO9nMw2 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 iQEcBAEBCgAGBQJVse6WAAoJEGhJURNOOiAtYwcH/2Gqu9E5VCQ7HFRk7ZX0QHbl LR7w5OVPjBghNYEg+LOFvP62mBskjqEESNJcDgOOhYfs3+XIyB2orlVBoouKrmee vGOcbAhQlmld/lmRsANnZiBhV2+8Y/zpyyzaoF9y/bSh+P+61wXXIGo1CF9e/wLP 9T/n6G7dLNJZrggoUwjmcAKPrwdaUUX1ykrbvrowm2QnvyiyS1NZZbQjmnumsoNA y7ezQ1fgEO+u3M1K0kmDzeKQ/VHx2K+rvbseKQrb1xFSeDFTdwJIaRnb6qcPZshY Nv6VtOsA4Yf1mNNgma2X0nSm0HPVplvVnqyIx3BiXbDS62UUZnfAgCj+v1lBf9o= =xRyf -----END PGP SIGNATURE----- --fMjGoEFSObARLj2J14uhe6d4OwXO9nMw2-- From nobody Fri Jul 24 01:01: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 F3A5D1B2FA3 for ; Fri, 24 Jul 2015 01:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wEymC47AxfQL for ; Fri, 24 Jul 2015 01:01:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5B1951B301A for ; Fri, 24 Jul 2015 01:00:59 -0700 (PDT) Received: from [192.168.10.141] ([62.168.35.68]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M6zvN-1Yx9bw3hY5-00wiNJ; Fri, 24 Jul 2015 10:00:42 +0200 Message-ID: <55B1F0A6.50704@gmx.net> Date: Fri, 24 Jul 2015 10:00:38 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Malisa VUCINIC , "bergmann@tzi.org" References: <903544800BDD1447BA9BDF3288CF0A0A0168D4F880@SAFEX1MAIL3.st.com> In-Reply-To: <903544800BDD1447BA9BDF3288CF0A0A0168D4F880@SAFEX1MAIL3.st.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i4BujkaPWMBammiPCVofHgMkjA9807VvV" X-Provags-ID: V03:K0:04aQh2oLc7SRSahR6NjN6oaH2e3lCwVWZt42zmFPp0r94a7iwKs sYYbZeL59S/QlM9l3gwmlWba+cYHw6lRHDfV1KsGupcI/iVI1mBRHflHhzpORnxGuN7cSsc VoX+0UESbzxmPGkedqF+0U6RuGgac5zHbfRR6KwKbv06WMwJOBwP6o97NAGigGEfCccVk6+ CqLR9Dla/CCFVoyYAnd9g== X-UI-Out-Filterresults: notjunk:1;V01:K0:MwKFSQ81a/M=:367kjb9Q2IeJ9N8+uXTq2c g1fp8clecwzCqflWl/gwxiqeKjS9idU5FIG8rXPireiI7hVo4ebsR7OazZzBA+3Atj6h07evR Ua2q0tmj4sGXg6k4KRQ/X7c8RzU2hhD3dfORfV3zirmmkXgM1GjF2/uid25uYNKDkYdDa3eu3 JNQeqVqnGTc838jtd8oB4XR3bMEr8O+cjvv0A7nF9yyY/hWISj6vPMXWzOmSZ0ZBIcZh7wGMn T8xqVF0982/lhWXCrbPE2mI3Z13PaK+/gYTz3bRii+GC10eE/6Je0XszQ6eJrXRVQ4YZ6h9xj Z5a8+IjqUJHGO2J2PGu2fEnZ0JsiELn9RZDiDqxjTDvb2SonAVtj80qYkjnBq0GNvlw1B7H+r H+Fqp8Ildv6RslGTzOpUur5avZWtWzXQxE1G/5ia3oxfniiWdwLl/bt1vOAa1k+DX8vmK1GJI QNZI02nhgM9ohWPL+aYGnkrT8EOLHcCx3uWgRYm0rn4Cp56nYWxoGn/asKBqv3KHlkNB+Ef/m WPCodhjW0mV27BVGHys9/QIky3wbTSIX5Ux/nSr6eQLxZDZaDMOMgAP/taK3m3OfdHmVMQTA/ 6cKHRMjDw6Cui7t2bYSq5pV3IwxzyJAfuM6cwqdesLBDyI0nGoZj+mQl53+BSnP0hJrCif+xD J9907sEXBDDkTgHBE0WScUli1Vzojaqp3naqKzoxrLb6W3g== Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] '2%' use-cases for object security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 08:01:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i4BujkaPWMBammiPCVofHgMkjA9807VvV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Malisa, I believe the underlying issue raised here is the following: Every solution makes assumptions about what use case they care about most. This can, for example, be seen from the focus on symmetric key cryptography and a Kerberos-alike communication pattern in some solutions while there are somewhat different approaches presented in other documents. It appears that there is not a single solution that covers all the use case and this raises challenges. Of course, the authors of every solution think that their work covers the relevant use cases. The use case discussion should have informed our solution work to a certain extend but maybe it didn't quite do as much as we had hoped. I was wondering whether you could take a brief look at the use cases to see whether your scenarios are covered there and, if others in the group agree, then we will have to take those into account. In the physical access control use case Erik presented, which happens to use Bluetooth Smart, we also don't see how DTLS makes sense between the client (smart phone) and the resource server (door lock). Ciao Hannes On 07/23/2015 08:08 PM, Malisa VUCINIC wrote: > Hello Olaf, >=20 > =20 >=20 > Just wanted to follow up on the discussion we had during the WG meeting= > yesterday. >=20 > =20 >=20 > Arguing that a solution purely based on DTLS is an approach for =91futu= re=92 > bothers me very much. If that were the case, we wouldn=92t be having > nightmares in deploying CDNs, making people share the same private key > on multiple machines, or create fake certificates to get (D)TLS > =91working' in scenarios that span from point-to-point request-response= =2E >=20 > =20 >=20 > To get back to the constrained world, I believe you concur with the fac= t > that most of the existing WSN deployments either have a gateway with > application level processing or gateway running a CoAP proxy. It seems > this is going to stay there for a while. Other people may have input > here as well. You seemed to be implying that we should not care about > that too much? >=20 > =20 >=20 > The =912 %' use-cases you indicated for object security may be comprise= d of: >=20 > - IoT devices talking to the Cloud, where from secured readings may be > forwarded and decrypted/verified end-to-end; >=20 > - any sort of group communication; >=20 > - CDNs with secured IoT data; >=20 > - payments using NFC or similar technology involving intermittent > connectivity; >=20 > - pub/sub brokers and communication over a proxy. >=20 > =20 >=20 > Unfortunately, I don=92t have data to support your claim that some of > these examples really do correspond to the 2%. If you do, it would be > great if you could share. >=20 > =20 >=20 > Regards, >=20 > Mali=9Aa >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --i4BujkaPWMBammiPCVofHgMkjA9807VvV 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 iQEcBAEBCgAGBQJVsfCmAAoJEGhJURNOOiAtNGMIAJtRFzamDWY8LYnG8DMfq+VQ Ug+l1Do+BN/hrMO5LKlENCkCSajvQsb/DEGYVhPTO8cmMpLAFnVGGg5Syc7I+Nwb YFtuOy0Euz6+5TkkC3/M667aieYohhZmoUa/ecvNSsujfYLRCQM28k+ZAb2xg6Vl sY0Jov2yPjcl6T+I9lEB80GLjWgg5NzgMxCaFJuucjLdSFMBfDlO1IzCLgkrFkvU w1aFo6nFCkgZL9w2Fl2HiQEIQhCmwTHlGupl/6gNTwu5FhBPitvSoqPlMoKGvIzi nFJdax9dvw53IZgc+VaH6w5U2oqBtz6aw9VhgysmLhIIlTKNpDhbGG9OYSdQhg8= =T9ik -----END PGP SIGNATURE----- --i4BujkaPWMBammiPCVofHgMkjA9807VvV-- From nobody Fri Jul 24 01:08: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 005E21B3027 for ; Fri, 24 Jul 2015 01:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 53rdZsYG27y2 for ; Fri, 24 Jul 2015 01:08:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D36911A1AA8 for ; Fri, 24 Jul 2015 01:08:51 -0700 (PDT) Received: from [192.168.10.141] ([62.168.35.68]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Md31i-1Zacsl0jdS-00IAKv; Fri, 24 Jul 2015 10:08:41 +0200 Message-ID: <55B1F287.3070404@gmx.net> Date: Fri, 24 Jul 2015 10:08:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Malisa VUCINIC , "bergmann@tzi.org" References: <903544800BDD1447BA9BDF3288CF0A0A0168D4F880@SAFEX1MAIL3.st.com> In-Reply-To: <903544800BDD1447BA9BDF3288CF0A0A0168D4F880@SAFEX1MAIL3.st.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="trahVx7erjvSKHmLg69enb25bVrXBkpP8" X-Provags-ID: V03:K0:reiWOJTo2jq6xc4RMdPW8+BWpMDqtPCHMeRypg4raZ/QfffezoB UUhPh3Bj9V8BFKCWPpkxk+SimNQq1++UyQpYbU9Gsn01CHKUJAgHiVODhFdXFF+vaJL5OEX wLB+30vQnLcTbVrpp/Z9KG3Q0qhR/vOE/j1I0uwPsIdHrnKtUAri1ND0912yAhiiVHUcXRH 1LlLe+BQRdVnLPwotVzcg== X-UI-Out-Filterresults: notjunk:1;V01:K0:+WHDmQCPFkA=:iGvQEAb1wFeoKseUiVW1rq Jw52pNZObMqc3m5VNJw1J60YH6u87zJd1tSJTNcIUh5oq5rU5hU31qwKTD5sqq7MYYhCeFhQc 3UUMaAOqqbn4vOuxMZQS8pSe9Fcj1zx1To483fchYJpAtCZm+CqnS2G+LUnLqGoIXJPG9St/F p2QyPdyYp4g7mzA9RyMoNoUo0N/M/51uprtPqGYp2ZL+3nLs0CByps8ypd0W1Y4jyvGVG1c69 5ZB6LPTxCcqh1rQBSTK0yzh0A3MMwxU6v/SjclgiTr6ZyFGFCE7JufUJdqFXWGmiYFhpStJ3I f1RqVGmKY9g05g1p2gudrKmu9XVQVyqXA47AU1oc60q9yfj+D0+Oa48r8bNvxmm3wUlAwloaU shMNyEe9njKi3FyWRMUwpgo0Wle/5tGYId4U1miokGcVdxu3xNCBaO6zICBq3OT69oEYhT1pg MdJACR+fXEh/F/Eiehh3xFJO8EUC3faR8aDSkqCoK7qb/d7QcNsUqgsz1M96KTY9YF286u9Ve ljLY4lJpw5GWVZ4BEFePIXx949Y8NXrs3bmcumj0TQm1tlR++lPSh+t8SykkODXkoTu86sQQl ACNZe4uB6/paub1Rf74rORqfVnodJzooamkFZwiEkKJOvt3fLdW8Ow+UuSh0QyyZwzmm/F1QF TgfXbmZo9zbWmOQgd/uM7fSyiWaW3gGwzHkmNke93eczuIw== Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] '2%' use-cases for object security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 08:08:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --trahVx7erjvSKHmLg69enb25bVrXBkpP8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Malisa, Olaf, despite my earlier response I encourage Olaf to explain what he meant during the presentation! Ciao Hannes On 07/23/2015 08:08 PM, Malisa VUCINIC wrote: > Hello Olaf, >=20 > =20 >=20 > Just wanted to follow up on the discussion we had during the WG meeting= > yesterday. >=20 > =20 >=20 > Arguing that a solution purely based on DTLS is an approach for =91futu= re=92 > bothers me very much. If that were the case, we wouldn=92t be having > nightmares in deploying CDNs, making people share the same private key > on multiple machines, or create fake certificates to get (D)TLS > =91working' in scenarios that span from point-to-point request-response= =2E >=20 > =20 >=20 > To get back to the constrained world, I believe you concur with the fac= t > that most of the existing WSN deployments either have a gateway with > application level processing or gateway running a CoAP proxy. It seems > this is going to stay there for a while. Other people may have input > here as well. You seemed to be implying that we should not care about > that too much? >=20 > =20 >=20 > The =912 %' use-cases you indicated for object security may be comprise= d of: >=20 > - IoT devices talking to the Cloud, where from secured readings may be > forwarded and decrypted/verified end-to-end; >=20 > - any sort of group communication; >=20 > - CDNs with secured IoT data; >=20 > - payments using NFC or similar technology involving intermittent > connectivity; >=20 > - pub/sub brokers and communication over a proxy. >=20 > =20 >=20 > Unfortunately, I don=92t have data to support your claim that some of > these examples really do correspond to the 2%. If you do, it would be > great if you could share. >=20 > =20 >=20 > Regards, >=20 > Mali=9Aa >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --trahVx7erjvSKHmLg69enb25bVrXBkpP8 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 iQEcBAEBCgAGBQJVsfKHAAoJEGhJURNOOiAtOAQIAJ6zPuhSBx42obDRLHABQSw2 TKsZLM5381XlkItybcoyb4l+Yrz3cCRr07S5j3vARmldThIA7apl/le5CTZGLtgP ouYvBlS4SaSUG/xY4XCoCuiqkxIe59ZrIsDjapCe3Rj+Hn9zVw8nfyktt5yDU5if EC84wdUzXP0KyPq0eS4qn7nS4nLThQgFgmRPSKyXlUtoZjKHkiupKiZoD2JnvDfV CpheNy/n66pn6C2rSfVw6n3Bcke2HEY0jim+w/i+N4Ps5tbSoh3gqGldXDAdILNq 59moScW0eqV8xm9S3qe6Wt1h/XLItnQHrRyL0t3QyymP7DTpOsEb6Q4hamYZq5s= =DQ+f -----END PGP SIGNATURE----- --trahVx7erjvSKHmLg69enb25bVrXBkpP8-- From nobody Fri Jul 24 01:20: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 7C95F1B3032 for ; Fri, 24 Jul 2015 01:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MSGID_FROM_MTA_HEADER=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 KxAhPBgVqA1s for ; Fri, 24 Jul 2015 01:20:24 -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 E49561A21A4 for ; Fri, 24 Jul 2015 01:20:23 -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 t6O8KK38012700; Fri, 24 Jul 2015 10:20:20 +0200 (CEST) Message-Id: <201507240820.t6O8KK38012700@mailhost.informatik.uni-bremen.de> Received: from [192.168.11.105] (mucha.avetravel.cz [77.240.96.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3md3PH683czDMQ9; Fri, 24 Jul 2015 10:20:19 +0200 (CEST) Date: Fri, 24 Jul 2015 10:20:18 +0200 From: Stefanie Gerdes To: Hannes Tschofenig MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: ludwig@sics.se, ace@ietf.org Subject: Re: [Ace] Acre X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 08:20:25 -0000 SGkgSGFubmVzLAoKTHVkd2lnJ3MgYXV0aG9yaXphdGlvbiBkcmFmdCBoYXMgdGhlIERDQUYgZHJh ZnQgaW4gdGhlIGFja25vd2xlZGdlbWVudHMgYXMgb25lIG9mIHRoZSBpbnNwaXJhdGlvbnMgZm9y IHRoZSBkcmFmdC4gSSB0aGluayBpdCB3b3VsZCBoZWxwIHRvIHN0YXRlIG1vcmUgY2xlYXJseSwg d2hpY2ggcGFydHMgYXJlIERDQUYgaWYgdGhlcmUgYXJlIHNvIGxhcmdlIHNpbWlsYXJpdGllcy4g SSBkb24ndCB0aGluayB3ZSBzaG91bGQgZW5kIHVwIGhhdmluZyB0d28gZGVzY3JpcHRpb25zIHRo YXQgYXJlIG9ubHkgc2xpZ2h0bHkgZGlmZmVyZW50LgoKVGhhbmtzLApTdGVmZmkKCkFtIDI0LjA3 LjIwMTUgMDk6NTEgc2NocmllYiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldD46Cj4KPiBIaSBTdGVmZmksIAo+Cj4KPiBPbiAwNy8yNC8yMDE1IDAxOjU3IEFNLCBT dGVmYW5pZSBHZXJkZXMgd3JvdGU6IAo+ID4gQXQgdGhlIGVuZCBvZiB0aGUgQUNFIHNlc3Npb24g eWVzdGVyZGF5IHlvdSBzYWlkIHRoYXQgb25lIG9mIHRoZSBtb2RlbHMgeW91IGFyZSBkZXNjcmli aW5nIGluIHlvdXIgbmV3IGF1dGhvcml6YXRpb24gZHJhZnQgaXMgbW9zdGx5IERDQUYgYW5kIG9u bHkgZGlmZmVycyBpbiB2ZXJ5IHNtYWxsIGRldGFpbHMuIEkgd2FzIHdvbmRlcmluZyB3aHkgeW91 IGFyZSBub3QgcG9pbnRpbmcgdGhhdCBvdXQgaW4geW91ciBkcmFmdC4gSSB0aGluayBpdCB3aWxs IGJlIGxlc3MgY29uZnVzaW5nIGZvciBwZW9wbGUuIAo+Cj4gSSBhbSBub3Qgc3VyZSB3aGVyZSB5 b3UgYXJlIGhlYWRpbmcgd2l0aCB0aGlzIHF1ZXN0aW9uLiBJIGZlYXIgdGhhdCAKPiBvdGhlcnMg bWlnaHQgZWFzaWx5IGFyZ3VlIHdoeSB5b3UgYXJlbid0IHJlZmVyZW5jaW5nIHRoZWlyIHNwZWMg ZWl0aGVyLiAKPgo+IEkgYmVsaWV2ZSB0aGUgcG9pbnQgcmFpc2VkIHdpdGggc2V2ZXJhbCBkcmFm dHMgaXMgdGhlIGZvbGxvd2luZzogdGhlcmUgCj4gYXJlIHZhcmlvdXMgY29tbXVuaWNhdGlvbiBt b2RlbHMgaW4gdXNlIHRvZGF5LiAKPgo+IC0gRG8gd2UgbmVlZCBhbGwgb2YgdGhlbT8gCj4KPiAt IERvIHdlIG5lZWQgdG8gc2VsZWN0IGEgZmV3IG9mIHRoZW0/IAo+Cj4gLSBGb3IgYSBnaXZlbiBt b2RlbCBkbyB3ZSBjYXJlIG11Y2ggYWJvdXQgdGhlIG1lc3NhZ2UgbmFtZXMgb3IgZGV0YWlscyAK PiBpbiBlbmNvZGluZz8gCj4KPgo+IENpYW8gCj4gSGFubmVzIAo+Cj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gCj4gQWNlIG1haWxpbmcgbGlzdCAKPiBB Y2VAaWV0Zi5vcmcgCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2Ug Cg== From nobody Fri Jul 24 01:46:20 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 4F2641A1A27 for ; Fri, 24 Jul 2015 01:46:18 -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 4HwXntTMwY2R for ; Fri, 24 Jul 2015 01:46:17 -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 9082B1A019B for ; Fri, 24 Jul 2015 01:46:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-fe-55b1fb56c27e Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0F.E3.25217.65BF1B55; Fri, 24 Jul 2015 10:46:14 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.149]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Fri, 24 Jul 2015 10:46:14 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Stefanie Gerdes , "ludwig@sics.se" Thread-Topic: [Ace] Acre Thread-Index: AQHQxaNtkG3ccvjJPEmD4oxSdbPr3p3qHmQAgAAwtwA= Date: Fri, 24 Jul 2015 08:46:13 +0000 Message-ID: References: <201507232358.t6NNw2Hj016532@mailhost.informatik.uni-bremen.de> <55B1EE96.5090403@gmx.net> In-Reply-To: <55B1EE96.5090403@gmx.net> 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.154] Content-Type: text/plain; charset="utf-8" Content-ID: <0E3AC4F87F0C194CB4E9A90427376DD5@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM+JvjW7Y742hBtNOWFp8/9bDbLHx4l1G i6U777FavGq9w+zA4rF40342jyVLfjJ59B77zeax7e1X5gCWKC6blNSczLLUIn27BK6MTz+n sRVMEqzYu3AmWwPjDYEuRk4OCQETidV//rNB2GISF+6tB7K5OIQEjjJKXHpwhgkkISSwhFHi 2rZEEJtNwEXiQcMjsLiIQLnEg9l7WEFsZgFFiXVz+sDiwgLiEnc27maBqJGQuHL4DCuEbSXx 8sd/sDiLgKrEyaufgJZxcPAKWEjM/OYEsSpDYlvLdrB7OAXUJW4svw02khHotu+n1jBBrBKX uPVkPhPEzQISS/acZ4awRSVePv4HtkpUQE9i5fUmqL+UJBbd/swEsopZQFNi/S59iDHWEtO7 JjHDXD+l+yE7iM0rIChxcuYTlgmMErOQbJuF0D0LSfcsJN2zkHQvYGRdxShanFpcnJtuZKSX WpSZXFycn6eXl1qyiREYqQe3/LbawXjwueMhRgEORiUeXoU5G0OFWBPLiitzDzFKc7AoifPO 2JwXKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxtejtfuW5YQ/SMi4+jwt7eczi+7uX0kmR 1tmTvrmz3Trw7ZH2kkuORT5N1ySP9/1833em2Pze/fpPB82lr8+bNuuFP7dvhKzAc3OdDGWJ WRZP+Kbf2M16ajl37KuVdfIpp6fXTpnU5LbmSqho5sEPpsyMLaEOrDtnMzFcUzr+VtXizX4v /+sMSizFGYmGWsxFxYkA8IezmbUCAAA= Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Acre X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 08:46:18 -0000 SGkgSGFubmVzLA0KDQpPbiAyMDE1LTA3LTI0IDA5OjUxLCAiSGFubmVzIFRzY2hvZmVuaWciIDxo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCg0KPkhpIFN0ZWZmaSwNCj4NCj4NCj5P biAwNy8yNC8yMDE1IDAxOjU3IEFNLCBTdGVmYW5pZSBHZXJkZXMgd3JvdGU6DQo+PiBBdCB0aGUg ZW5kIG9mIHRoZSBBQ0Ugc2Vzc2lvbiB5ZXN0ZXJkYXkgeW91IHNhaWQgdGhhdCBvbmUgb2YgdGhl IG1vZGVscw0KPj55b3UgYXJlIGRlc2NyaWJpbmcgaW4geW91ciBuZXcgYXV0aG9yaXphdGlvbiBk cmFmdCBpcyBtb3N0bHkgRENBRiBhbmQNCj4+b25seSBkaWZmZXJzIGluIHZlcnkgc21hbGwgZGV0 YWlscy4gSSB3YXMgd29uZGVyaW5nIHdoeSB5b3UgYXJlIG5vdA0KPj5wb2ludGluZyB0aGF0IG91 dCBpbiB5b3VyIGRyYWZ0LiBJIHRoaW5rIGl0IHdpbGwgYmUgbGVzcyBjb25mdXNpbmcgZm9yDQo+ PnBlb3BsZS4NCj4NCj5JIGFtIG5vdCBzdXJlIHdoZXJlIHlvdSBhcmUgaGVhZGluZyB3aXRoIHRo aXMgcXVlc3Rpb24uIEkgZmVhciB0aGF0DQo+b3RoZXJzIG1pZ2h0IGVhc2lseSBhcmd1ZSB3aHkg eW91IGFyZW4ndCByZWZlcmVuY2luZyB0aGVpciBzcGVjIGVpdGhlci4NCj4NCj5JIGJlbGlldmUg dGhlIHBvaW50IHJhaXNlZCB3aXRoIHNldmVyYWwgZHJhZnRzIGlzIHRoZSBmb2xsb3dpbmc6IHRo ZXJlDQo+YXJlIHZhcmlvdXMgY29tbXVuaWNhdGlvbiBtb2RlbHMgaW4gdXNlIHRvZGF5Lg0KPg0K Pi0gRG8gd2UgbmVlZCBhbGwgb2YgdGhlbT8NCj4NCj4tIERvIHdlIG5lZWQgdG8gc2VsZWN0IGEg ZmV3IG9mIHRoZW0/DQoNClRoaXMgaXMgZXhhY3RseSB3aGF0IE1pY2hhZWwgYW5kIEkgcHJvcG9z ZWQgdGhhdCB3ZSBzaG91bGQgYXNrIHRoZSBXRw0KZHVyaW5nIHRoZSBtZWV0aW5nLiBVbmZvcnR1 bmF0ZWx5IHRoYXQgcXVlc3Rpb24gd2FzIGRlZmVycmVkIGFuZCB3ZSByYW4NCm91dCBvZiB0aW1l LiBGb3IgUHVzaCBhbmQgQ2xpZW50LVB1bGwvcHVibGlzaC1zdWJzY3JpYmUgdGhlcmUgaXMgYSBj bGVhcg0KaW50ZXJlc3QgZnJvbSB0aGUgY29tbXVuaXR5LiBIb3cgYWJvdXQgdGhlIFB1bGwgbW9k ZWw/IFdlIGluY2x1ZGVkIHRoaXMNCmNvbnNpZGVyaW5nIHVzZSBjYXNlcyB3aXRoIGludGVybWl0 dGVudCBJbnRlcm5ldCBjb25uZWN0aXZpdHkgb2YgdGhlDQpjbGllbnQsIGJ1dCBob3cgY29tbW9u IGlzIHRoYXQ/DQoNCkFyZSB0aGVyZSB5ZXQgb3RoZXIgY29tbXVuaWNhdGlvbiBtb2RlbHMgbmVl ZGVkIHRvIGFkZHJlc3MgdGhlIHVzZSBjYXNlcz8NCg0KTm90ZTogQUNSRSBzaG93cyBob3cgdG8g YnVpbGQgZGlmZmVyZW50IG1vZGVscyBvbiBjb21tb24gUkVTVGZ1bA0KY29tcG9uZW50cywgc28g c3VwcG9ydGluZyBtdWx0aXBsZSBtb2RlbHMgZG9lcyBub3QgbmVjZXNzYXJpbHkgaGF2ZSBhDQpt YWpvciBpbXBhY3QgaW5jcmVhc2Ugb24gY29tcGxleGl0eS4NCg0KUmVnYXJkcw0KR8O2cmFuDQoN Cg0KPg0KPi0gRm9yIGEgZ2l2ZW4gbW9kZWwgZG8gd2UgY2FyZSBtdWNoIGFib3V0IHRoZSBtZXNz YWdlIG5hbWVzIG9yIGRldGFpbHMNCj5pbiBlbmNvZGluZz8NCj4NCj5DaWFvDQo+SGFubmVzDQo+ DQoNCg== From nobody Fri Jul 24 01: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 0ABF31A1B2E for ; Fri, 24 Jul 2015 01:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gUXF0XBA_THO for ; Fri, 24 Jul 2015 01:53:23 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 DE1241A1B19 for ; Fri, 24 Jul 2015 01:53:22 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so18293737wib.1 for ; Fri, 24 Jul 2015 01:53:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=vekfRoJIzy0z9ucMtRlBvGUN8TpkA/RMVfx2nKgWPmQ=; b=R88obvWuZxyFdhxzja3xl2QaNLD4peOVED16SuGwqJFOxP7y+Z8Tuhg+HU+hSe5Fgz XyAgVFZqsIbDHQtJ8r66G3b0txGlH9tjoXHfZ/JT7tCiRcFYe4RHxOGuOcG5xOPyxTRc GHErhMU3hszhERnsx7WJE8cohBRkcPijrPHsgDGm6jXgjFsFuYQizngCJvDM6KoaDBvO cOPuv330/XglLp3QkqlJEfCfYWjlDATJ8z2iINFvT23tMzBlefwtTTjwGGDC9eKC4Sqm RUCOnuv+Yecx2PeQ3oQ62GUNpOugOeOS8eY/9nZlkv3iOmSLsR9Yio4pv+679A07Lc5q Ez3A== X-Gm-Message-State: ALoCoQm+MhuhcGF0yw8DZccKNaaIcIx7gXTCotvIVKgVZqyVug0dKkm4bkBWq8Yv29z+z+sbErPu X-Received: by 10.180.88.196 with SMTP id bi4mr5319474wib.70.1437728001696; Fri, 24 Jul 2015 01:53:21 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:a59f:8581:b7af:63aa? ([2001:67c:370:136:a59f:8581:b7af:63aa]) by smtp.gmail.com with ESMTPSA id h9sm11519748wjx.20.2015.07.24.01.53.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 01:53:20 -0700 (PDT) Message-ID: <55B1FCF3.6030008@sics.se> Date: Fri, 24 Jul 2015 10:53:07 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Stefanie Gerdes , Hannes Tschofenig References: <201507240820.t6O8KK38012700@mailhost.informatik.uni-bremen.de> In-Reply-To: <201507240820.t6O8KK38012700@mailhost.informatik.uni-bremen.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040402090208000603020106" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Acre X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 08:53:25 -0000 This is a cryptographically signed message in MIME format. --------------ms040402090208000603020106 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-07-24 10:20, Stefanie Gerdes wrote: > Hi Hannes, > > Ludwig's authorization draft has the DCAF draft in the acknowledgements= as one of the inspirations for the draft. I think it would help to state= more clearly, which parts are DCAF if there are so large similarities. I= don't think we should end up having two descriptions that are only sligh= tly different. > > Thanks, > Steffi > I think listing the differences is going to be less confusing. So here is my take: DCAF proposes to use the Push model, ACRE argues that there are=20 (significant) use cases that require or are more optimally served by=20 other models (Pull, Client-Pull). As far as the Push model is concerned, DCAF and ACRE are rather similar=20 with the following differences: 1. DCAF proposes to use DTLS exclusively. ACRE argues that it is useful=20 to allow either object security or DTLS for communication security. Note that for the Push model both require object security for the tokens = anyway, so we are not saving any code size either way. 2. DCAF uses psk-identity to transfer the token, which we think is a=20 cludge, especially since there is a standardized authorization data type = for (D)TLS supplemental data (RFC 4680). ACRE proposes to treat the=20 tokens as RESTful resources and allow clients to POST tokens to the=20 resource server. Optionally ACRE suggests the use of TLS supplemental=20 data to transfer tokens. 3. As a consequence of 2, in DCAF you have to perform a DTLS session=20 renegotiation to update a token. In ACRE you just update the RESTful=20 resource. 4. DCAF leverages the client authentication of DTLS to bind the token to = the session. When using object security in ACRE this needs to be done by = signing the client request with a key associated to the token. 5. In ACRE the RS needs to locate the corresponding token for an=20 incoming request. Given that it is easy to find out which token applies=20 to which resources and this information is static, this should not be=20 very complicated. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms040402090208000603020106 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 KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA3MjQwODUzMDdaMCMGCSqGSIb3DQEJBDEW BBRMjWVBaWQrZsUhKtTbgj/FMp0BFzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEATofW6Cp8bule8mLZUDIYNUCCglio4i3VK8mxFEHei44w5a4oL7mI7BGn9Iu3kud1Abhw LvMPVFMmbqyKk+1O1xYA88wNGxPBzsjlwOIEtGwkKgYIA8i3GH/813S5xS751g2X0+y6duwy 91+jf1cDrmnt++5LUSA/uTt8yqYA5ivjQHFauYsQGNjfvcVgL392hy3cghe2K35uZ+qOwqVT lmznCtX74GQWT564DH8kl9EWuoT0WLlW7V26IoCGnZe0URWHEDOqYF1bUkP7kmqiE4RdTmyk X6IfhMTTTD1aUtDdqv8EK2LvDsjc0s9U2gUngZ5dVjD/yTUG5IfN5m7lQAAAAAAAAA== --------------ms040402090208000603020106-- From nobody Fri Jul 24 02:33:46 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 AE1611A8972 for ; Fri, 24 Jul 2015 02:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 prCOpvljoahu for ; Fri, 24 Jul 2015 02:33:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 C22071A8892 for ; Fri, 24 Jul 2015 02:33:35 -0700 (PDT) Received: from [192.168.10.141] ([62.168.35.68]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MJngW-1ZJfHl304a-0017q9; Fri, 24 Jul 2015 11:33:33 +0200 Message-ID: <55B2066B.5010607@gmx.net> Date: Fri, 24 Jul 2015 11:33:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Ludwig Seitz , Stefanie Gerdes References: <201507240820.t6O8KK38012700@mailhost.informatik.uni-bremen.de> <55B1FCF3.6030008@sics.se> In-Reply-To: <55B1FCF3.6030008@sics.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5I1OqFdTgi9aShfRtEhgrp7cBIIgt7NtI" X-Provags-ID: V03:K0:T4I2nTec5ctlLQcUkAxrbYFr9EROMqqkPebET5xwwvzqPq4KdW4 4U3oKcxODKHJ+cX8C5DOdPiyBFHpkBDUoxaxnnO5oLqO1QGcOznd9b7bjcXnFVfXGG9jF14 iQB4ZEYDtXn4h0Ws4+9J68yGd7wm6ls4Cd0a/UhLuSciF45lzOa8NJ8faGBlL48XwujgXQv VshIXk/7/x90OaVCQsWjg== X-UI-Out-Filterresults: notjunk:1;V01:K0:T67LInnAgtE=:59KAocrIplOjWfo6SuqRBM 3WDNoBUzv5JknLlcrHbwiJOBEkpaHMZBfvwCRXcsYopdCCch2uZyn0I3x6W9VD1PNf36ms+cB OEZL7wvB30wzmNwElSg4mEEq3kKeaLcNjQ96iwAk5mdjwCCe9mt5ld1r49F9uVGGSSROdc+AF lu0qHZ/F+1QLuCgyXiG25b06edJBjS7LzVxdqK8YH+r/BtIg1tqPWc5SNpCBaAirnWd3ytpKU WVhnxrnAL8mAhDsaeoQX9/aZLrtpmHh3Fwd72FHJnLmuoCAOFKGC/PngXQWYN5K8+pDbLzGis wEVRz6mCnh4xKIKqwODFW5LFm1wYXI4kNwxFYLgZXBAXxmMP08ryeZPvhfD+4eDGc/21KqIsU WqvhyYg7Ea9jZfe1OFdnPuV55HPAucYRoXLtoNe+gZeIhSjH8e9HgRYBcluVQfbPC5C4c7IDY wWfQwON/Sw5s7r4vhqBZJ21b1w53ykokAipzsr8/fk/ZybF+mF1rjJOofRkZ+tm4moZj5/iCZ O92O3FCq8Pszo0Kb53sUnG4jzYeMxwPUSQry2cMGeEO1gG+YLNmPIwgNrQQKnB6kaBCQFt6Z6 PH9HH4QSM50sDjYvc6VnV+4kkN4SSuzNktACWQDtb69BpCbmo8VspVef6+x9xFIfNAJFVHSZ+ Bb+uSXXwBjlA1zAqBR05qKheXUAYH4tiZlTII5FkI5+mDDQ== Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Acre X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 09:33:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5I1OqFdTgi9aShfRtEhgrp7cBIIgt7NtI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Just to respond from an OAuth ACE point of view since it also uses a variant of the push model. * It does not rely on DTLS for the communication between the client and the RS but it can use it. For the use of CoAP with bearer tokens (over DTLS) there is this write-up: draft-tschofenig-ace-oauth-bt Since we re-use as much as possible the use of DTLS with a proof-of-possession token would at the moment resort to the token binding work. The proposal also works with the object security model Goeran has been proposing for the case where a PoP token is used and proof of possession happens at the app layer. In some sense you could call also our Bluetooth Smart Door Lock investigations an application layer security solution but it is the application layer within the BLE stack. * There is not only the push model but also the token introspection model, which keeps access tokens small. It does, however, require the RS to be able to reach the AS. * It provides flexibility for the access tokens and the type of proof-of-possession model. It therefore works with symmetric as well asymmetric keys. Unlike any other proposal it is well integrated with user identity management. It is well integrated in all scenarios where you use a smart phone / tablet for use with IoT device. Ciao Hannes On 07/24/2015 10:53 AM, Ludwig Seitz wrote: > On 2015-07-24 10:20, Stefanie Gerdes wrote: >> Hi Hannes, >> >> Ludwig's authorization draft has the DCAF draft in the >> acknowledgements as one of the inspirations for the draft. I think it >> would help to state more clearly, which parts are DCAF if there are so= >> large similarities. I don't think we should end up having two >> descriptions that are only slightly different. >> >> Thanks, >> Steffi >> >=20 > I think listing the differences is going to be less confusing. >=20 > So here is my take: >=20 > DCAF proposes to use the Push model, ACRE argues that there are > (significant) use cases that require or are more optimally served by > other models (Pull, Client-Pull). >=20 > As far as the Push model is concerned, DCAF and ACRE are rather similar= > with the following differences: >=20 > 1. DCAF proposes to use DTLS exclusively. ACRE argues that it is useful= > to allow either object security or DTLS for communication security. >=20 > Note that for the Push model both require object security for the token= s > anyway, so we are not saving any code size either way. >=20 > 2. DCAF uses psk-identity to transfer the token, which we think is a > cludge, especially since there is a standardized authorization data typ= e > for (D)TLS supplemental data (RFC 4680). ACRE proposes to treat the > tokens as RESTful resources and allow clients to POST tokens to the > resource server. Optionally ACRE suggests the use of TLS supplemental > data to transfer tokens. >=20 > 3. As a consequence of 2, in DCAF you have to perform a DTLS session > renegotiation to update a token. In ACRE you just update the RESTful > resource. >=20 > 4. DCAF leverages the client authentication of DTLS to bind the token t= o > the session. When using object security in ACRE this needs to be done b= y > signing the client request with a key associated to the token. >=20 > 5. In ACRE the RS needs to locate the corresponding token for an > incoming request. Given that it is easy to find out which token applies= > to which resources and this information is static, this should not be > very complicated. >=20 >=20 > Regards, >=20 > Ludwig >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --5I1OqFdTgi9aShfRtEhgrp7cBIIgt7NtI 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 iQEcBAEBCgAGBQJVsgZrAAoJEGhJURNOOiAthPoIAKGqTA4LxuSOvu4Moe0s+SXh +Js6DStz4e2M8yXjjYUmM769GqFptNHfizmByMARrWj4/B+uWAHyeXfRyOfftlZG t27QKl6ukjEBaZPTqXJJBS2uYuqV8QIv7Ja0JZD5/QcOKNCzWUNvhZdHZruTITVH 7KNrakJ3G05NPPRflORVeOaBDo0Z2IBryFd4EAHNEGztjOheQPdvonQKbOLvPsiJ o+uQmwdz63hs0zrsXSSthatK2SfQbMAYTFF7tfHf0cTm9jsR6KmK4VCXD0qQmpop 7SmI5ex5TCom0J7FJqSwaiFb9LxYiASTe76x9GFuVRlkGVFieTJVMpSBUOdkqU4= =WGat -----END PGP SIGNATURE----- --5I1OqFdTgi9aShfRtEhgrp7cBIIgt7NtI-- From nobody Fri Jul 24 02:36:37 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 E4A181A005B for ; Fri, 24 Jul 2015 02:36:35 -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 kIcEbeeWdHOQ for ; Fri, 24 Jul 2015 02:36:34 -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 83B511A86F7 for ; Fri, 24 Jul 2015 02:36:34 -0700 (PDT) Received: from [192.168.10.141] ([62.168.35.68]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mb7pT-1ZcAU61qxv-00KiAJ; Fri, 24 Jul 2015 11:36:25 +0200 Message-ID: <55B20717.1080207@gmx.net> Date: Fri, 24 Jul 2015 11:36:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Stefanie Gerdes , "ludwig@sics.se" References: <201507232358.t6NNw2Hj016532@mailhost.informatik.uni-bremen.de> <55B1EE96.5090403@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2iMsbRu1ewhVPxg8w9tRP89NcX7p7VsRW" X-Provags-ID: V03:K0:dZQQ+5ZGa3ZZCFeaPSxBojjlpXG9JcCsY1wUWERd/Et8eakAqS3 F1ziswA6N3fN3Ra7kSUK+j+ymulE+nmCfWtPu0dGFPuz1rXoycs1sLeUfKosNIWX+03226S 0VEANK4sNNbYIRLeAr5YrDEHkCvQR91DW2pQLsQoWMH1hNEWEikYRGyrmPgyVe7KmFkYvuo y/ghbwrYFnvgR+DYRSfLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:CKGM7U2HqjY=:hTfm2N1P65S2vXbEG/lvRC NFRy0ZR4sSVN9EHEbg3K2iK9nMEAe92MdlROvO+teZFeD+x8aWzoFLuy2jDOJm3mewR+LJGWE 0n8R3U7mwMXFhxcx6Ym3QU6yCFWc0ZS6JwrXgB0ewdemDzSiUze2umXsP42TKm+VruGUl68E1 sUfU97rzzaXBKs2DjtV9Cz7IaXT4/qjUwoDuSY56/9uormbiB86lGqKINojTVdNid05dfvYFw 4shGsrMcOcLLqrxod75Fv1hu2Mq3hsonWSFd4ZF6zXrilQEPZX3f0eflfzYDdbAJnOkKArfBv BdN386fmVb4Twv9BYNBQTqfAh2NkNLtBxS9JuebdUaiO9pQuBALa+IeQOEG0CQGDS+vRibuJy +Pihdim92b+5HBywIBEPCJiWElPqV5Yr9KL9AE2oiOtgcmat4qP9+dsJAtqbEd5BjoowQsQtu ADLUw62GghBPrfYDNRySQjHhnUrooz32jRLRrIU/qq3BWxeOKwjWwGL6k1/gUw1nc2ceR2gZE irJmdroSrM74ufiuFCsDtZgYAAKtC4VgvPJC92kCAt298l+F8MlnzmGD5UZ9ihdaXkTeBCHS5 2Vlw2TDJ4oGs/XB71Q4o8iPvxouiG3GCanIwEaZ8zpttTCBVXO01dbX5Pspb6ftApuICpyn70 VHLA9E4Anv45RmXxNY6bTw+z52oIHCpyBoEoMwFQ4BwldWw== Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Acre X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Jul 2015 09:36:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2iMsbRu1ewhVPxg8w9tRP89NcX7p7VsRW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Goeran, I agree with you that thinking about the different communication models is definitely worthwhile to do. In order to come up with a decision it will, however, be needed to consult the use cases again. This is what we had been doing with the physical access control and the multicast use case. As you have noticed, we ran out of time during the working group meeting and this process will take a bit longer since it is necessary to carefully think about the scenarios one cares about and whether those are supported by a given model. Ciao Hannes On 07/24/2015 10:46 AM, G=C3=B6ran Selander wrote: > Hi Hannes, >=20 > On 2015-07-24 09:51, "Hannes Tschofenig" wr= ote: >=20 >> Hi Steffi, >> >> >> On 07/24/2015 01:57 AM, Stefanie Gerdes wrote: >>> At the end of the ACE session yesterday you said that one of the mode= ls >>> you are describing in your new authorization draft is mostly DCAF and= >>> only differs in very small details. I was wondering why you are not >>> pointing that out in your draft. I think it will be less confusing fo= r >>> people. >> >> I am not sure where you are heading with this question. I fear that >> others might easily argue why you aren't referencing their spec either= =2E >> >> I believe the point raised with several drafts is the following: there= >> are various communication models in use today. >> >> - Do we need all of them? >> >> - Do we need to select a few of them? >=20 > This is exactly what Michael and I proposed that we should ask the WG > during the meeting. Unfortunately that question was deferred and we ran= > out of time. For Push and Client-Pull/publish-subscribe there is a clea= r > interest from the community. How about the Pull model? We included this= > considering use cases with intermittent Internet connectivity of the > client, but how common is that? >=20 > Are there yet other communication models needed to address the use case= s? >=20 > Note: ACRE shows how to build different models on common RESTful > components, so supporting multiple models does not necessarily have a > major impact increase on complexity. >=20 > Regards > G=C3=B6ran >=20 >=20 >> >> - For a given model do we care much about the message names or details= >> in encoding? >> >> Ciao >> Hannes >> >=20 --2iMsbRu1ewhVPxg8w9tRP89NcX7p7VsRW 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 iQEcBAEBCgAGBQJVsgcXAAoJEGhJURNOOiAtk0EH/3eln/UTi8EWzBdwxRA1q0yY ZvS/0ehDhuyN+87dSrttX/GORn0dF1ckvUrFacvWo7Xa/omaQB9TWjP4HJaLB3ml 6l93CreQ8IHw7434Mr0Epm865xahvnznltHtxamuiDAleqW0zgBKtpwa8c3Tdlto e+sQJnoziIrviDcJfP+UCQ5pBw+IXMWt79/yHTR/HAGWrZ8kTKsiZlMTyfp/FMrA /Yw5GgTNJv3jVzXaUL6RYr6D1FDYttoXkiD8OaI7cdiIHzNglyWe9r6Eke+0hXfi PxIMNeeZTp/Fphjy7zQ4k39MOV+5hH4Djhhrw4LBRQkMViUKyFr5dBk7MPxL0iU= =BWUx -----END PGP SIGNATURE----- --2iMsbRu1ewhVPxg8w9tRP89NcX7p7VsRW-- From nobody Fri Jul 24 04:18:44 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 2E6881A9244 for ; Fri, 24 Jul 2015 04:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jJiB9-xPDFff for ; Fri, 24 Jul 2015 04:18:41 -0700 (PDT) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7644B1AC3F8 for ; Fri, 24 Jul 2015 04:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1437736682; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=RzI9EbHPtHPnjGpJgFhYaV4moCvebDtRTfOZZB919Uw=; b=g8FAb3sSmY626iRgJBPm49199c4FiUIVzm+86dX77I6UBtDqWTP8EliYKnoa61R6fn9QLbTvJGRWHXgR6yrD+ubuRazOZElaeo2xmxhY8Vb/J8PmhAB3Vl3R+Z6cqxvALLWmRHIU1kDUzyYg1n0PjeZlxfkPCFhQ8lYqOSWtZhc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03304; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.53.47(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Fri, 24 Jul 2015 19:17:56 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 24 Jul 2015 19:17:47 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: Call for adoption for draft-gerdes-ace-actors-05 References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3520588677_2759185" Archived-At: Cc: Hannes Tschofenig Subject: [Ace] Call for adoption for 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: Fri, 24 Jul 2015 11:18:43 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3520588677_2759185 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hello all, This note begins a Call For Adoption for draft-gerdes-ace-actors-05 to be adopted as an ACE working group item, and added in the charter. The call ends on Aug 7, 2015. Keep in mind that adoption of a document does not mean the document as-is is ready for publication. It is merely acceptance of the document as a starting point for what will be the final product of the ACE working group. The working group is free to make changes to the document according to the normal consensus process. There were favorable supports toward adoption of this document at IETF 93 in Prague. We will factor this into the decision at the close of this Call. Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item. Thanks, Kind Regards Kepeng & Hannes --B_3520588677_2759185 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hello all,
Keep in mind that adoption of a document does not mean the document
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product
of the ACE working group. The working group is free to make changes to
the document according to the normal consensus process.

There were favorable supports toward adoption of this document at
IETF 93 in Prague. We will factor this into the decision at the close
of this Call.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

Thanks,

Kind Regards
Kepeng & Hannes
 --B_3520588677_2759185-- From nobody Sat Jul 25 17:35: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 C62C01A907A for ; Sat, 25 Jul 2015 17:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, 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 eEzp1DPumpNG for ; Sat, 25 Jul 2015 17:35:51 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161041A9074 for ; Sat, 25 Jul 2015 17:35:51 -0700 (PDT) Received: from hebrews (75-148-161-129-Houston.hfc.comcastbusiness.net [75.148.161.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 787AF2C9EB; Sat, 25 Jul 2015 17:35:49 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <01b001d0c214$fe3bf0e0$fab3d2a0$@augustcellars.com> In-Reply-To: Date: Sat, 25 Jul 2015 19:36:11 -0500 Message-ID: <000001d0c73b$1348a430$39d9ec90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGuI9cmLkIVnP8ERaGjZ3am41rJkwCBfZBIni2H8xA= Content-Language: en-us Archived-At: Cc: draft-gerdes-ace-actors@tools.ietf.org Subject: Re: [Ace] draft-gerdes-ace-actors X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 26 Jul 2015 00:35:53 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Tuesday, July 21, 2015 6:26 PM > To: Jim Schaad; ace@ietf.org > Cc: draft-gerdes-ace-actors@tools.ietf.org > Subject: Re: [Ace] draft-gerdes-ace-actors >=20 > Jim, >=20 > Again, thanks for your detailed review! Since the editor of the = document, > Carsten, has been very busy, the other authors have compiled the = following > replies to your comments. (Thanks also to Olaf for good input.) >=20 > On 2015-07-19 13:20, "Jim Schaad" wrote: >=20 > >I have read through this draft and my first comment is - I don't > >understand what this draft is trying to accomplish. My confusion > >begins in the second paragraph of the abstract where it says that it = is > >providing "elements of an architecture / a problem statement". > > > >The idea of providing terminology is reasonable - although I = generally > >don't believe that a standalone document is a good place to do so > >unless you are doing a lot of definitions. And for the most part you > >just use the same > >ones as OAuth is using. I can see providing an architecture that is > >going > >to be reasonable complete or a problem statement. But doing just > >elements of those is not useful. How is one to evaluate anything > >against it if just pieces are given but not anything representing a > >complete picture. >=20 > The intention was that not only some elements but "all the elements an = actual > Architecture can comprise of=E2=80=9D. We change this. >=20 > > > >Introduction: > > > >* constrained devices are not the only ones for which ACLs are not > >sufficiently generic. There are lots of places where doing access > >control is off-loaded from a device to another system. Even with = ACLs you > need to > >discuss how authorization would be dealt with. This statement could = be > >much clearer. >=20 > Access control lists is mentioned in more than one place, exactly = which > statement are you referring to (or is it the whole paragraph)? Paragraph #3 is what I am referring to. =20 A better layout for the paragraph is probably to reverse the entire = sense of it. We need authorization - When and how are identities setup. How and why = are identities needed to be check. Some things can be anonymous. =20 We need authorization - what are the requirements - - Both gross preconfigured and fine grained. - Preconfigured ACLS does gross, Shared securities does gross. = Other methods are needed for fine-grain. >=20 > The point we are trying to make is that the use of static = authorisation does not > suit all use cases in particular due to the nature of constrained = device > deployments with built-in devices, long deployment times etc., and = therefore > especially in this case we need to consider dynamic updates of = authorization > policies. >=20 >=20 >=20 > > > >* If you are going to tell me that there are security tasks that > >cannot be done, you need to provide a list of what security tasks you > >care about someplace so I can verify this for myself. >=20 >=20 > Point taken. We will add some examples and reference another draft = that will > specify tasks in detail (to be written). >=20 >=20 >=20 > >Also, for many of these tasks it > >is necessary to offload even when they can be done by the device. > >Offloading authorization is not uncommon even for larger devices. >=20 > True. There may various reasons for offloading. We should rephrase = this text to > reflect thatc. >=20 >=20 >=20 > > > >* Just saying that limitations are a problem is not generally = helpful. > >It would be better to list some of the reasons for each security task > >you care about. Since people are going to need to make decisions = about > >what things can and cannot be placed together and having such a list > >would be helpful in that regard. >=20 > OK. The task description mentioned previously should address this = comment too. >=20 >=20 >=20 > > > >* Doing forward references to fulfill some of these requests is > >perfectly reasonable. >=20 > OK. >=20 > > > >Terminology: > > > >* I am completely lost by the last sentence in this section. It may > >be signature structure, but it is also an issue with what you are > >talking about for client-side authorization. >=20 > OK, we should clarify this paragraph. >=20 >=20 >=20 > > > >* Should "endpoint" be part of the terminology section? >=20 > Yes. This is defined in RFC7252, so should be added to the list of = terms > referenced in from that. >=20 >=20 >=20 > > > >Architecture: > > > >* I have a problem with bullet #1 - It may be due to working in SACM > >and depends on how one defines endpoint. However I see no reason = that > >an endpoint cannot host the functionality of AS and CAS as well so = this > >bullet is not complete. >=20 >=20 > Right, we change that. >=20 >=20 > OLD > o An endpoint may host functionality of C, RS or both C and RS. >=20 > NEW >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > o An endpoint may host > functionality of one or more actors. >=20 >=20 >=20 >=20 > > > >* The term "constrained level" pops up out of the middle of nowhere = - > >this really needs to be defined. Perhaps this should be a section > >title with and introduction before you start. >=20 > Good catch. We will make a forward reference where both the term and = its > security objectives are described. Things looked slightly better for layout in the previous version where = you did different sections (hopefully with some small intro) for each of = the different levels that you have here. >=20 > > > >* The introduction of the CSA does not seem logical if it is to help > >make requests of the RS. This needs more justification. I would = have > >thought it > >was there to control the C and what it does with things. This = seemed to > >be > >the Objective type 2 statement from above. If you are making it a > >support > >item, then it does not make sense either to call it an access control > >point or to say it is being controlled by the RqP. It could just as > >easily be either a neutral party or the AS that is being talked to. >=20 >=20 > The CAS has both the support and control function. We will explain = this better. >=20 >=20 >=20 >=20 > > > >Information Flows > > > >* I don't understand the reason for complicating the diagram. = Having it > >be the simple version, at least at first presentation of flows, makes > >it easier to understand. You can talk about the reflection at a = later point. >=20 > The purpose of this picture was to emphasize that the endpoints can in = general > host both client and server functionality, but this is already = explained in text so I > agree it can be omitted. We will remove the reflection from the = figure. >=20 >=20 > > > >* Why do you have information flows as one directional between CAS = and C? >=20 >=20 > The figure is intended to illustrate, on a high level, the relevant = information > flows with constrained devices in scope of ACE. These information = flows can be > realised with different protocols so the actual message flow between = the actors > may be different, we should explain this better in the text. But = although there > may be requests going from C to CAS, the control information carried = in the > response in that case is the information of interest here, and this is = the reason > for only showing information flow in one direction. Given the number of flows that are discussed in doing things like key = distribution, not representing requests from the client/resource to the = CAS/AS seems to be undesirable. This is emphasized by the fact that = you are frequently talking about off-loading parts of the control = decisions from the constrained layer to the controller layer. This = means that the document is discussing this as an information flow on a = regular basis. >=20 >=20 > (This differs from my previous answer to the draft as individual = author.) >=20 >=20 >=20 > > > >Missing Architecture issues > > > >* Why do you not talk about the presence or absence of AS and CAS = nodes > >at Times >=20 > Do you mean the intermittent connectivity aspect, i.e. that the CAS or = AS may > not available from the respective constrained nodes at times? >=20 Yes >=20 >=20 > > > >* Store and forward should be discussed in this document. (i.e. > >combination > >of push and pull models) >=20 >=20 > Store and forward is mentioned in the use case draft, section 2.5.3. > (https://tools.ietf.org/html/draft-ietf-ace-usecases-04#section-2.5.3) > What aspect of that do you think should be discussed in this document? >=20 This document should be readable in the absence of the use case = document. It may or may not get published. This document should be the = first read document for ACE. If that is the case then this is the type = of thing which needs to be included. >=20 >=20 > > > >* Better description of type 2 security objects needs to be = undertaken > >- specifically why we would care about them. >=20 > We will provide an example to illustrate why this is useful. >=20 >=20 >=20 > > > >Security Objectives: > > > >* I assume that access is also a security object that is addressed = by > >authorization. >=20 > Is this in the context of the security objectives, section 2.1? Are = you referring to > =E2=80=9Cavailability=E2=80=9D in the sense of ensure that entities = that are entitled to get access > do get access? >=20 Yes - should have been security objective in my statement. >=20 >=20 > > > >* Kill the term non-repudiation - I don't know what this means and > >there is not a great deal of agreement on its meaning. >=20 > OK, we remove the reference to non-repudiation. This is not central in = the > current draft. >=20 >=20 >=20 > > > > * You absolutely need some measure of authentication involved. The > >paragraph 2 needs have a cleaner start that what it does. You really > >need to talk about authentication, are you authenticating the device = or > >are you authentication any device (or some set of devices) that are > >owned by somebody. These are different authentication models. >=20 >=20 > In section 4 we elaborate on what is being authenticated. The = intention is not to > define what is being authenticated but allow different approaches for = different > use cases. We should either mention that here or make a forward = reference > from paragraph 2 in section 3 to section 4. > Would that address your question? >=20 >=20 >=20 >=20 > G=C3=B6ran From nobody Tue Jul 28 01:15:54 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 CF9C91A00B5 for ; Tue, 28 Jul 2015 01:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0o1Z92SzAxpD for ; Tue, 28 Jul 2015 01:15:51 -0700 (PDT) Received: from mx08-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3E91A0007 for ; Tue, 28 Jul 2015 01:15:50 -0700 (PDT) Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.14.5/8.14.5) with SMTP id t6S8EgJ3005360; Tue, 28 Jul 2015 10:15:47 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 1vx4xxgcuw-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2015 10:15:47 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A17DE38; Tue, 28 Jul 2015 08:15:45 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas1.st.com [10.75.90.14]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 857302CEF; Tue, 28 Jul 2015 08:15:45 +0000 (GMT) Received: from Safex1mail3.st.com ([fe80::e48c:97a7:3b08:899e]) by SAFEX1HUBCAS1.st.com ([::1]) with mapi; Tue, 28 Jul 2015 10:15:45 +0200 From: Malisa VUCINIC To: Hannes Tschofenig Date: Tue, 28 Jul 2015 10:15:44 +0200 Thread-Topic: [Ace] '2%' use-cases for object security Thread-Index: AdDF5tl1QnlPgj1BTzKtTlXPlclI4ADJkd9Q Message-ID: <903544800BDD1447BA9BDF3288CF0A0A0169F51711@SAFEX1MAIL3.st.com> References: <903544800BDD1447BA9BDF3288CF0A0A0168D4F880@SAFEX1MAIL3.st.com> <55B1F0A6.50704@gmx.net> In-Reply-To: <55B1F0A6.50704@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-28_03:2015-07-28,2015-07-28,1970-01-01 signatures=0 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] '2%' use-cases for object security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jul 2015 08:15:53 -0000 Hi Hannes, The scenarios I mentioned seem to be covered by the Smart Metering use case= (U5.5 and U5.8). The text in U5.8 seems a bit convoluted though so I would= like to clarify if 'multiple nodes' should say 'multiple application layer= hops' or similar, as the term 'node' implies a link layer hop which I don'= t think we care about in this WG. Also, 'messages between endpoints' shoul= d IMO be rephrased to stress the fact that this may include a sensor readin= g.=20 As per the group communication scenario, U4.8 implies the use of a multicas= t protocol which voiced some concerns during the meeting so I suppose it sh= ould be rephrased to account for generic group communication. Also, U4.8 on= ly implies the actuation so it might be useful to precise that we can also = have a single sensor reading accessed by several devices. I would also suggest to extend Section 3.4 in order to stress how important= proxies are in energy-constrained environments. As sensors sleep >99.9% of= the time, we certainly do not want to expose them to every client out ther= e that is interested in accessing a reading. Proxies (or application layer = gateways) are thus a natural candidate to hide the constrained part and pro= vide the client(s) with up-to-date readings. Regards, Mali=B9a -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: vendredi 24 juillet 2015 10:01 To: Malisa VUCINIC; bergmann@tzi.org Cc: ace@ietf.org Subject: Re: [Ace] '2%' use-cases for object security I was wondering whether you could take a brief look at the use cases to see= whether your scenarios are covered there and, if others in the group agree= , then we will have to take those into account. From nobody Tue Jul 28 02:24:57 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 60CEB1A8824 for ; Tue, 28 Jul 2015 02:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I5uolfjf9q1 for ; Tue, 28 Jul 2015 02:24:54 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 93F571A8822 for ; Tue, 28 Jul 2015 02:24:53 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so70527272lbb.1 for ; Tue, 28 Jul 2015 02:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tCWGs796d7Gc2Qy/fhcXDmS7yYaKUmQs5bZdtV+hGOo=; b=O8S9kMdxbdl0Y2u4aAmJIYnTtXmvgqhseTEwg/JrZwE5nQd/Tvxwu3w65QwnfRSyL/ BfLOKM7VbkmBbObIWI0KInt4Wp8stHh+noRFhwrS9pIqeKPVayu3lfzlx83mw5E3A7VA rfH8sDz7Yswc2CmZPag7RPGgTnUNYm7z/Y6a6Ke0aAt7RXcpL5JBTYXO49q7ov6uI4QX pMbT/SwLAiTCFZztQqQMFmiQQgCHQRGvOdB/ddX6SbpWBjfQovLdNmG2x+p9SFR7fTgG ae8QEcXuILo9O8GUtP/XXIefvucidW2SrdPQJx+kvMjl4LeJ4DhvS6qe/vWhxuNGhV9K W2cw== MIME-Version: 1.0 X-Received: by 10.112.63.169 with SMTP id h9mr31786930lbs.104.1438075492100; Tue, 28 Jul 2015 02:24:52 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.31.75 with HTTP; Tue, 28 Jul 2015 02:24:52 -0700 (PDT) In-Reply-To: <903544800BDD1447BA9BDF3288CF0A0A0169F51711@SAFEX1MAIL3.st.com> References: <903544800BDD1447BA9BDF3288CF0A0A0168D4F880@SAFEX1MAIL3.st.com> <55B1F0A6.50704@gmx.net> <903544800BDD1447BA9BDF3288CF0A0A0169F51711@SAFEX1MAIL3.st.com> Date: Tue, 28 Jul 2015 10:24:52 +0100 X-Google-Sender-Auth: o2qwRJ5ag051Jl4cqcu95qF-BfY Message-ID: From: Robert Cragie To: Malisa VUCINIC Content-Type: multipart/alternative; boundary=001a11c3fd12ddf22e051bec0af7 Archived-At: Cc: Hannes Tschofenig , "ace@ietf.org" Subject: Re: [Ace] '2%' use-cases for object security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 09:24:56 -0000 --001a11c3fd12ddf22e051bec0af7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One of the issues as I see it is defining what we mean by "endpoint". The term does have a specific meaning in CoAP but is often used rather abstractly in these sort of conversations. The term "end-to-end" also has similar issues. Intermediaries can be involved at all layers and for different purposes and if the requirement is for encryption and/or integrity protection of data then the whole picture obviously has to be considered, so regarding the comment about "node" vs. "application layer hop", both probably need to be considered. It is likely due to the presence of those multiple intermediaries at multiple layers that protection has to occur "high up" in the layers, using, for example, object security. This occurs in the smart metering use case; consumption data from a gas meter often has to be encrypted and integrity protected at the gas meter (the origin) and decrypted and verified at the supplier's head end (MDM) system (the target). It can take a convoluted path through different protocols and proxies to get from origin to target and if DTLS is used, it is likely to be one part of the overall picture. Regarding the use cases in general - I would really like to see them be just use cases, without any second guessing regarding topologies, protocols etc. For example, and to Mali=C5=A1a's point, U4.8 should not really mentio= n "multicast protocol". Robert On 28 July 2015 at 09:15, Malisa VUCINIC wrote: > Hi Hannes, > > The scenarios I mentioned seem to be covered by the Smart Metering use > case (U5.5 and U5.8). The text in U5.8 seems a bit convoluted though so I > would like to clarify if 'multiple nodes' should say 'multiple applicatio= n > layer hops' or similar, as the term 'node' implies a link layer hop which= I > don't think we care about in this WG. Also, 'messages between endpoints' > should IMO be rephrased to stress the fact that this may include a sensor > reading. > > As per the group communication scenario, U4.8 implies the use of a > multicast protocol which voiced some concerns during the meeting so I > suppose it should be rephrased to account for generic group communication= . > Also, U4.8 only implies the actuation so it might be useful to precise th= at > we can also have a single sensor reading accessed by several devices. > > I would also suggest to extend Section 3.4 in order to stress how > important proxies are in energy-constrained environments. As sensors slee= p > >99.9% of the time, we certainly do not want to expose them to every clie= nt > out there that is interested in accessing a reading. Proxies (or > application layer gateways) are thus a natural candidate to hide the > constrained part and provide the client(s) with up-to-date readings. > > Regards, > Mali=C5=A1a > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: vendredi 24 juillet 2015 10:01 > To: Malisa VUCINIC; bergmann@tzi.org > Cc: ace@ietf.org > Subject: Re: [Ace] '2%' use-cases for object security > > > I was wondering whether you could take a brief look at the use cases to > see whether your scenarios are covered there and, if others in the group > agree, then we will have to take those into account. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a11c3fd12ddf22e051bec0af7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One of the issues as I see it is defining what we mean by = "endpoint". The term does have a specific meaning in CoAP but is = often used rather abstractly in these sort of conversations. The term "= ;end-to-end" also has similar issues. Intermediaries can be involved a= t all layers and for different purposes and if the requirement is for encry= ption and/or integrity protection of data then the whole picture obviously = has to be considered, so regarding the comment about "node" vs. &= quot;application layer hop", both probably need to be considered. It i= s likely due to the presence of those multiple intermediaries at multiple l= ayers that protection has to occur "high up" in the layers, using= , for example, object security. This occurs in the smart metering use case;= consumption data from a gas meter often has to be encrypted and integrity = protected at the gas meter (the origin) and decrypted and verified at the s= upplier's head end (MDM) system (the target). It can take a convoluted = path through different protocols and proxies to get from origin to target a= nd if DTLS is used, it is likely to be one part of the overall picture.
Regarding the use cases in general - I would really like to= see them be just use cases, without any second guessing regarding topologi= es, protocols etc. For example, and to Mali=C5=A1a's point, U4.8 should not really mention &qu= ot;multicast protocol".

Robert

On 28 July 2015 = at 09:15, Malisa VUCINIC <malisa.vucinic@st.com> wrote:<= br>
Hi Hannes,

The scenarios I mentioned seem to be covered by the Smart Metering use case= (U5.5 and U5.8). The text in U5.8 seems a bit convoluted though so I would= like to clarify if 'multiple nodes' should say 'multiple appli= cation layer hops' or similar, as the term 'node' implies a lin= k layer hop which I don't think we care about in this WG.=C2=A0 Also, &= #39;messages between endpoints' should IMO be rephrased to stress the f= act that this may include a sensor reading.

As per the group communication scenario, U4.8 implies the use of a multicas= t protocol which voiced some concerns during the meeting so I suppose it sh= ould be rephrased to account for generic group communication. Also, U4.8 on= ly implies the actuation so it might be useful to precise that we can also = have a single sensor reading accessed by several devices.

I would also suggest to extend Section 3.4 in order to stress how important= proxies are in energy-constrained environments. As sensors sleep >99.9%= of the time, we certainly do not want to expose them to every client out t= here that is interested in accessing a reading. Proxies (or application lay= er gateways) are thus a natural candidate to hide the constrained part and = provide the client(s) with up-to-date readings.

Regards,
Mali=C5=A1a

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: vendredi 24 juillet 2015 10:01
To: Malisa VUCINIC; bergmann@tzi.org
Cc: ace@ietf.org
Subject: Re: [Ace] '2%' use-cases for object security


I was wondering whether you could take a brief look at the use cases to see= whether your scenarios are covered there and, if others in the group agree= , then we will have to take those into account.

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

--001a11c3fd12ddf22e051bec0af7-- From nobody Tue Jul 28 11:06:43 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 DB5961B2CFB for ; Tue, 28 Jul 2015 11:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTuj51IZRE2l for ; Tue, 28 Jul 2015 11:06:40 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCB51B2CF9 for ; Tue, 28 Jul 2015 11:06:40 -0700 (PDT) X-ASG-Debug-ID: 1438106798-06daaa664f44390001-Yzt3Th Received: from NALENITE.InterDigital.com (nalenite.interdigital.com [10.2.64.253]) by smtp-in1.interdigital.com with ESMTP id mCbq2mNtKQBzaDgn (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jul 2015 14:06:38 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0248.002; Tue, 28 Jul 2015 14:06:37 -0400 From: "Rahman, Akbar" To: Hannes Tschofenig , Kepeng Li , "ludwig@sics.se" Thread-Topic: Update to Public Safety Use Case draft X-ASG-Orig-Subj: Update to Public Safety Use Case draft Thread-Index: AdDJWDziZpqLhO2xSw+6JjhmB4tRfA== Date: Tue, 28 Jul 2015 18:06:35 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F2310B67E@NABESITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.153] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nalenite.interdigital.com[10.2.64.253] X-Barracuda-Start-Time: 1438106798 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.21160 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "ace@ietf.org" Subject: [Ace] Update to Public Safety Use Case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jul 2015 18:06:42 -0000 Hi Hannes/Kepeng/Ludwig, I have made an update of the Public Safety Use case draft to capture the ke= y points from the Prague meeting. Namely (from the minutes): -https://www.ietf.org/proceedings/93/minutes/minutes-93-ace -Hannes: please give us feedback about non-repudiation, clarificatio= n on integrity of the data. -We should include this on the UC document: 12 hands Ok, 2 hand no. -Conclusion: We will include it Please look at the diff of the draft and tell me if you agree with the upda= tes (i.e. basically got rid of the offending items as suggested during the = WG discussion as they strayed out of the Authentication/Authorization arena= into Legal or other protocol areas). Htmlized: https://tools.ietf.org/html/draft-rahman-ace-public-safety-= use-case-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-rahman-ace-public= -safety-use-case-01 If so, I guess the next step is for Ludwig to incorporate into the WG Use C= ase draft. If you merge, you can just acknowledge us but do not have to in= clude us as authors in your WG Use Case draft. Please write back! Best Regards, Akbar