From nobody Mon Jan 5 05:33:42 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C8E1A7018 for ; Mon, 5 Jan 2015 05:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_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 au9DHn0JH2O5 for ; Mon, 5 Jan 2015 05:33:38 -0800 (PST) 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 7F0821A87C0 for ; Mon, 5 Jan 2015 05:33:36 -0800 (PST) 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 t05DXW1m014648; Mon, 5 Jan 2015 14:33:32 +0100 (CET) Received: from [IPv6:2001:638:708:30da:c5f1:85da:71f9:d34f] (unknown [IPv6:2001:638:708:30da:c5f1:85da:71f9:d34f]) (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 3kGHq038Y9z7ymX; Mon, 5 Jan 2015 14:33:32 +0100 (CET) Message-ID: <54AA9286.4090209@tzi.de> Date: Mon, 05 Jan 2015 14:32:54 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hannes Tschofenig , "Ace@ietf.org" References: <5482F2A8.2090801@gmx.net> In-Reply-To: <5482F2A8.2090801@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/m_Jh8qCVFUyLDUD7h9JnrSRR_Aw Subject: Re: [Ace] Home Automation Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:33:40 -0000 Hi everyone, I wish you all a happy new year! On 12/06/2014 01:12 PM, Hannes Tschofenig wrote: > I read through the home automation case and I have a few remarks. > > > In Section 2.2.2. "Seamless Authorization" you write: > > " > Jane buys a new light bulb for the corridor and integrates it into > the home network (how she does that is not in scope). George is not > at home, but Jane wants him to be able to control the new device with > his smart phone without the need for additional administration > effort. > " > > Could you be a bit more specific about what is out of scope? I could > imagine that the way how Jane configures access control policies when > she integrates the light bulb into her home is quite similar to the way > how she would do that for George. > > I am also wondering what you mean by "Jane wants him [George] to be able > to control the new device with his smart phone without the need for > additional administration effort.". I am sure it again requires some > configuration. It might not require any effort for George but someone > has to do that since otherwise how should the authorization server know > that it has to grant permissions to George to turn the light on or off. > > In Section 2.2.3. you describe the case for remotely letting in a > visitor. Would it be possible to add a scenario that is less > sophisticated since this scenario requires some form of messaging > infrastructure to exist. > > Here is what I have in mind: > > ----- > > Jane and George have equipped their home with Internet connected door-locks. > > Joe, a friend of George, frequently visits them and they would like to > give them access to their home. Once, when Joe was at their home George > uses his smart phone to create a digital access token. He > transfers that access token to Joe's phone using short range radio > communication technology. The token allows Joe to open the door. > > Jane and George know that they can revoke access at any time and are > also able to modify the permissions with that access token. Joe is also > not able to use the obtained access token to mint new access tokens to > grant his friends to gain access to the house of Jane and George. > > ----- > I don't really understand why we should take the remote access out of this use case. It would be a very severe limitation if authorization policies for the constrained devices cannot be configured remotely. Best regards, Steffi From nobody Mon Jan 5 05:38:26 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B221A6F3B for ; Mon, 5 Jan 2015 05:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yRrw5VsgmqE for ; Mon, 5 Jan 2015 05:38:22 -0800 (PST) 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 11F6D1A1A78 for ; Mon, 5 Jan 2015 05:38:22 -0800 (PST) Received: from [192.168.131.143] ([80.92.122.140]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MeMOx-1YSoJP06cJ-00QA3s; Mon, 05 Jan 2015 14:38:12 +0100 Message-ID: <54AA93C3.9000207@gmx.net> Date: Mon, 05 Jan 2015 14:38:11 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: gerdes@tzi.de, "Ace@ietf.org" References: <5482F2A8.2090801@gmx.net> <54AA9286.4090209@tzi.de> In-Reply-To: <54AA9286.4090209@tzi.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="laWTxnksVEIm2mWu2spGlFVGd0a9hVc98" X-Provags-ID: V03:K0:I/o/jvNp/XX1WIH6OHFdThiicaxPQ5mxaobHrwt4oY/Lm6cd2xp UMrdNQHVTDJgJzDD9fFrBAKjAQbCJsBdiLPUpufIZLc74SoP+taJEbLHlDZ1UcBo0guTPiM VF6t0O+Pl6MkXDZm+yuQUhkkjClq0rytXMrHR6kYeLSyMbd+4ZpWDyv4RCG/uAFPHph4Gj3 d2nPWyRB8VTZZ19UgQxAw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ace/hza_PSqmXtHHVWNs9vFkoEGbwOk Subject: Re: [Ace] Home Automation Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:38:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --laWTxnksVEIm2mWu2spGlFVGd0a9hVc98 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steffi, happy new year to you as well. My text suggestion was for an additional exchange that passes authorization credentials to another person in a f2f fashion. I thought that this could be useful since the remote version requires a lot of other infrastructure to exist and raised the bar for building something interoperable. Ciao Hannes On 01/05/2015 02:32 PM, Stefanie Gerdes wrote: > Hi everyone, >=20 > I wish you all a happy new year! >=20 >=20 > On 12/06/2014 01:12 PM, Hannes Tschofenig wrote: >> I read through the home automation case and I have a few remarks. >> >> >> In Section 2.2.2. "Seamless Authorization" you write: >> >> " >> Jane buys a new light bulb for the corridor and integrates it into= >> the home network (how she does that is not in scope). George is n= ot >> at home, but Jane wants him to be able to control the new device w= ith >> his smart phone without the need for additional administration >> effort. >> " >> >> Could you be a bit more specific about what is out of scope? I could >> imagine that the way how Jane configures access control policies when >> she integrates the light bulb into her home is quite similar to the wa= y >> how she would do that for George. >> >> I am also wondering what you mean by "Jane wants him [George] to be ab= le >> to control the new device with his smart phone without the need for >> additional administration effort.". I am sure it again requires some >> configuration. It might not require any effort for George but someone >> has to do that since otherwise how should the authorization server kno= w >> that it has to grant permissions to George to turn the light on or off= =2E >> >> In Section 2.2.3. you describe the case for remotely letting in a >> visitor. Would it be possible to add a scenario that is less >> sophisticated since this scenario requires some form of messaging >> infrastructure to exist. >=20 >> >> Here is what I have in mind: >> >> ----- >> >> Jane and George have equipped their home with Internet connected >> door-locks. >> >> Joe, a friend of George, frequently visits them and they would like to= >> give them access to their home. Once, when Joe was at their home Georg= e >> uses his smart phone to create a digital access token. He >> transfers that access token to Joe's phone using short range radio >> communication technology. The token allows Joe to open the door. >> >> Jane and George know that they can revoke access at any time and are >> also able to modify the permissions with that access token. Joe is als= o >> not able to use the obtained access token to mint new access tokens to= >> grant his friends to gain access to the house of Jane and George. >> >> ----- >> >=20 > I don't really understand why we should take the remote access out of > this use case. It would be a very severe limitation if authorization > policies for the constrained devices cannot be configured remotely. >=20 >=20 > Best regards, > Steffi >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --laWTxnksVEIm2mWu2spGlFVGd0a9hVc98 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 iQEcBAEBCgAGBQJUqpPDAAoJEGhJURNOOiAtpfIH/2bE+OiTRknKNOkZQooTIo8A nv9wiU/ymTCExTigbv6sgL3sv7r0NF4wHBYOUIYRiC/9INbsGwV24oGMVwGEB5hl ZRf0Da5TwlS6/m/ppDvE0SGxB7p7HbdnovTiBmLgSX8rj9bhPdZYZe2kfWTd+NBa J+GWEQ06JsXA2fFvm8F8fYNDvd7rNUhc7jqKkJiXL3MUDxsROeV6eAKX0FwGGIny ewdw6Quvwff2q17EkEnSWuWzC9jPUZfAjIhI6WJUII3rmEo4LEDykRD6A6zW+s8c o9xjbNjWMPnN7xZJ0qEpsqAuohSmkK9tVREQfEpy+yaVSGwI23JhdAAR/JYbMcw= =vq0g -----END PGP SIGNATURE----- --laWTxnksVEIm2mWu2spGlFVGd0a9hVc98-- From nobody Thu Jan 8 09:21: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 65B4A1A8867 for ; Thu, 8 Jan 2015 09:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 pDBmn_bSA5n3 for ; Thu, 8 Jan 2015 09:21:28 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.52.26]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71F11A882E for ; Thu, 8 Jan 2015 09:21:28 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 7E488BBD8A02D; Thu, 8 Jan 2015 11:21:25 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 507C1BBD89EB9 for ; Thu, 8 Jan 2015 11:21:25 -0600 (CST) Received: from [96.231.226.60] (port=50197 helo=[192.168.1.2]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y9Glw-0006PR-Og for Ace@ietf.org; Thu, 08 Jan 2015 11:21:24 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <5480686E.1080406@gmx.net> Date: Thu, 8 Jan 2015 12:21:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <005C633D-889C-485E-A32D-843642E93CC4@ieca.com> References: <5480686E.1080406@gmx.net> To: "Ace@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.60 X-Exim-ID: 1Y9Glw-0006PR-Og X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.2]) [96.231.226.60]:50197 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [Ace] draft-ietf-ace-usecases-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:21:30 -0000 I reviewed the -00 version of the use cases draft. Overall, I wanted to = say that I wish more drafts were this easy to read. This is probably a = philosophical thing but I=92m really glad you didn=92t use 2119-language = in this draft. This draft captures what I was looking for in a use case = draft so hopefully after addressing some of Hannes=92 points we can just = WGLC the -01 version! What follows are some nits: 0) s.1.1: fix the line break: Client (C): A device which wants to access a resource on the Resource Server. This could also be a constrained device. 1) Is it worth pointing out in s2 that you=92re not trying to enumerate = all use cases? I=92d like to avoid getting this draft done because = folks are afraid their use case is not listed. 2) s2.1.2: U1.1: I like the idea of being more specific because I was = curious if at time t there=92s going to be more than one entity with = authorization or if there will only ever be one entity authorized at a = given time. I think that that=92s implied but I=92m not sure I remember = reading it explicitly. 3) s2.1.2: U1.4&5: WRT Hannes/Michael=92s thoughts on these two: I=92d = keep =91em and just state they=92re out of scope. I think it=92s better = to leave them there than later have somebody ask well what about these = things later. 4) S2.1.2: U1.9: (just an observation nothing needs to be changed) I = think it=92ll be interesting to see how we=92ll deal with this because I = could see authorizations being given for a set amount of time and then = having to deal with the timer running out. =20 5) S2.2.1: I could see replacing "or their smartphones=94 with =93or = with an internet connected device (e.g., smartphones)=94 because I might = actually want to use my laptop, or my car=92s touchscreen. Then again I = guess we don=92t have to list every possible scenario. I=92ll leave it = to you. 6) S2.2.2: r/smart phone/smartphone 7) S2.3.1: fix the line break: including access control. This prevents situation where someone else wearing that device can 8) S2.4: fix the line break: areas of the building. Accordingly, a company must be able to control the light and HVAC 9) s2.7: Probably need an informative link to what the Stuxnet worm was. 10) s3.3: r/internet/Internet 11) s4: line breaks: other parties involved. Suitable measures for protecting and purging the logs must be taken 12) As a security area draft, I=92m really disappointed that Alice, Bob, = Eve, and Mallory somehow got left out ;) spt On Dec 04, 2014, at 08:58, Hannes Tschofenig = wrote: > Hi all, >=20 > we are happy to see the use case document adopted. >=20 > Here is the draft: > http://www.ietf.org/id/draft-ietf-ace-usecases-00.txt >=20 > Please take a look at the document; we would like to advance it. >=20 > Ciao > Hannes & Kepeng >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Sat Jan 10 03:51:47 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0051ACD01 for ; Sat, 10 Jan 2015 03:51:44 -0800 (PST) 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 QAuZXVRhNwFc for ; Sat, 10 Jan 2015 03:51:41 -0800 (PST) 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 5D2BA1ACD00 for ; Sat, 10 Jan 2015 03:51:40 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-db-54b1124a6d44 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 13.FB.04076.A4211B45; Sat, 10 Jan 2015 12:51:38 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.38]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Sat, 10 Jan 2015 12:51:38 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Stefanie Gerdes , Ludwig Seitz Thread-Topic: [Ace] Container Use Case Thread-Index: AQHQD9NllQ+W4xnHo06VfJeSgjYakZyBEb6AgDhmLoA= Date: Sat, 10 Jan 2015 11:51:37 +0000 Message-ID: References: <54807796.7030504@gmx.net> <5481D0B9.6020905@tzi.de> In-Reply-To: <5481D0B9.6020905@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+Jvja6X0MYQg74FFhbfv/UwW2y8eJfR 4lXrHWYHZo8lS34yefQe+83mse3tV+YA5igum5TUnMyy1CJ9uwSujIl/mtgLelQrNt59wNLA OEGui5GDQ0LARKLzhGoXIyeQKSZx4d56ti5GLg4hgSOMEjOPzmOFcBYzSrQ/uMMCUsUm4Cpx 4ME7JhBbRMBJon9WD1icWUBRYvess+wgtrCAqsSdq5OgatQktk3ewQKyTETASqLjngRImAWo 5PLDK2DlvAIWEt0PJzKD2EICDhJNe44ygticQK37O2ezgtiMQMd9P7WGCWKVuMStJ/OZII4W kFiy5zwzhC0q8fLxP7B6UQE9iZXXm9gg4koSK7ZfYoTo1ZO4MXUKG4RtLTHn1Al2CFtbYtnC 18wQ9whKnJz5hGUCo8QsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLSSy3KTC4uzs/T y0st2cQIjMyDW35b7WA8+NzxEKMAB6MSD++GqRtChFgTy4orcw8xSnOwKInz5jkAhQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTAGfyj6v3Xfo/KSwze3Jm/Myk/ZF/+m7xinklxQOM9Ej3cM vW//a12p45poeftnQXth4iX1zlPXvpzc/+z13zu1Okv3f2e0eKPe2DnxzncV25i1zw8vXdq1 edYaRV7lzY9mPG832XW+8oBpUcS/cs3/TKGhHFzP/50X/fOb4YDXhjCLt48+Ch56qsRSnJFo qMVcVJwIAE2GJ2KtAgAA Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Container Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 11:51:44 -0000 Hi Steffi and Ludwig, (Also a question for WG chairs / AD a few paragraphs below) I=B9ve read through the ACE use case draft with fresh eyes and have some comments. Since I know the draft is in transition I will not go into detail in this mail. Could you please let me know if you plan to address the comments below or not in the next version? The main overall comment is that there is a great deal of overlapping material between section 3 of the use case draft and section 4 of draft-seitz-ace-problem-description: [1]=20 http://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section-4 Recall that section 4 of [1] is to a large extent the result of a discussion at the (informal) ACE meeting in Stockholm in June 2014. Obviously we didn't agree on everything at the meeting, as is also indicated in the draft, but some terms and assumptions were agreed and I think it would save us time to re-use some of this either in the use case draft or in a separate [architecture?] draft. WG chairs/AD/anyone: Do you have an opinion about whether (a) there should be a separate [architecture?] draft describing additional terminology and assumptions of the solution space, or (b) if this should be fitted into the security considerations of the use case draft, or (c) each solution proposal should make its own assumptions and terminology? The charter does not include an architecture document which I guess speaks in favor of (b) and (c). Here are the comments: Section 3.1 "Attacks" - The last part of the section describes properties of constrained devices that may need to be considered also for performance reasons, not just attack mitigation. How about renaming the section "Constrained device aspects" or "Constrained devices" or similar? - Section 4.2 of [1] contains a list of partly overlapping features of constrained devices. Does it makes sense to include in the use case draft other features of section 4.2 in [1] which are not currently in? For example that some constrained devices may be unable to manage complex authorization policies or unable to precisely measure time (see also section 5.3 in [1])? Section 3.2 "Configuration of Access Permissions" - Different terms with similar meaning are used in the draft: "access permissions"/"access control policies"/"authorization policies". A single term consistently used would be preferable. As an alternative, [1] uses the term "authorization information". Section 4.4 of [1] proposes a definition and characterization of authorization info. which is more general than just premissions/policies. Does it make sense to use this terminology and/or characterization in the use case draft? - Section 3.2 also overlaps with 4.5 of [1], the latter is considering a more general problem "access to authorization information". (More general since authz. info is more general than access policies and "access" is a priori more general than "configuration"/"provisioning to the device".) Does it make sense to include this more general problem and the properties listed in section 4.5 of [1] in the use case draft? - Section 4.5 of [1] also go into how to secure access to authorization information. Do you think this content also makes sense in the security considerations of the use case draft? Section 4 - Not only authorization of resource access, but also authorization of access to resource information should be considered for privacy reasons (compare section 4.3 of [1].) General=20 - The use case draft contains fragments of an authorization architecture (mainly terminology in section 1.1 such as C, RS, RO). Would it make sense to extend this and include a basic split "authorization decision / authorization enforcement" setup? Section 2 of [1] motivates why this setup is particular relevant for the constrained device setting, and section 4.3 of [1] maps this functionality to the architecture. - [1] also contains assumptions on keys and ciphersuites (section 4.7), constrained network considerations (section 4.9) and legacy considerations (section 4.10). Do you think any of this makes sense in the use case draft? - Sections 2.x.x. entitled "Authorization Problems Summary" I think most of the authorization problems make more sense with "device owner" replaced with "resource owner". Referring to Steffi's mail reply to Hannes (Subject: [ACE] Container Use Case) I think it is confusing to try to address server and client problems with one problem statement about "device owner". I would like to separate those so it is clear to whether the problem relates to server or client. Do you agree? Regards, G=F6ran From nobody Sun Jan 11 03:21:50 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E931A1B7F for ; Sun, 11 Jan 2015 03:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 OnmwTHXed155 for ; Sun, 11 Jan 2015 03:21:44 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7A41A1B7D for ; Sun, 11 Jan 2015 03:21:44 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id l2so14939431wgh.7 for ; Sun, 11 Jan 2015 03:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Bb3+KP3IalBxxtxX5wore2k4lKjNoGF/laaB084BCs=; b=jb/5ZFywEIIfF7w0t8Zzud49lecEzmEAjwOXDifxAEcgZ2sdZLGJC2aYJdHg7YinFc uPmg4GwyTkBPmO3JE9S+swcXoUsrXZXdZXIEF6VuJbj7FeDbMd87B35LATqaAqsc+/as rKAoQ6T9YB2ZRFAg7+eovga6OXZYX9kMMpdU2xMu1NXRrrQUPA3z4Px2d1lfFPxevCwl QyycmoqoikHbk49Z5V2qemZjE2XZOwE6kFkioK61Lv15crJC4YdzUnoLKC633AxLKmJI d0SZxxIGeQYC6yMQ5v+inxkw3vQnTuoyQLheRQ/JHfvn4vjEvzZHl7hHVhYI+sW0oKi1 INBg== MIME-Version: 1.0 X-Received: by 10.180.211.34 with SMTP id mz2mr20805538wic.56.1420975303192; Sun, 11 Jan 2015 03:21:43 -0800 (PST) Received: by 10.194.223.35 with HTTP; Sun, 11 Jan 2015 03:21:43 -0800 (PST) In-Reply-To: <54AA93C3.9000207@gmx.net> References: <5482F2A8.2090801@gmx.net> <54AA9286.4090209@tzi.de> <54AA93C3.9000207@gmx.net> Date: Sun, 11 Jan 2015 16:51:43 +0530 Message-ID: From: sandeep kiran p To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c37e022e781e050c5e987e Archived-At: Cc: gerdes@tzi.de, "Ace@ietf.org" Subject: Re: [Ace] Home Automation Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Jan 2015 11:21:47 -0000 --001a11c37e022e781e050c5e987e Content-Type: text/plain; charset=UTF-8 Hi, Can the following also be considered as a use case? " The owners of the automated home want to be intimated of any violations of the access control policies. Say the automation system detects a person in the house when the owner has locked down everything and is on a vacation. The system should then immediately intimate the owners about the breach. " Thanks Sandeep On Mon, Jan 5, 2015 at 7:08 PM, Hannes Tschofenig wrote: > Hi Steffi, > > happy new year to you as well. > > My text suggestion was for an additional exchange that passes > authorization credentials to another person in a f2f fashion. I thought > that this could be useful since the remote version requires a lot of > other infrastructure to exist and raised the bar for building something > interoperable. > > Ciao > Hannes > > > On 01/05/2015 02:32 PM, Stefanie Gerdes wrote: > > Hi everyone, > > > > I wish you all a happy new year! > > > > > > On 12/06/2014 01:12 PM, Hannes Tschofenig wrote: > >> I read through the home automation case and I have a few remarks. > >> > >> > >> In Section 2.2.2. "Seamless Authorization" you write: > >> > >> " > >> Jane buys a new light bulb for the corridor and integrates it into > >> the home network (how she does that is not in scope). George is not > >> at home, but Jane wants him to be able to control the new device > with > >> his smart phone without the need for additional administration > >> effort. > >> " > >> > >> Could you be a bit more specific about what is out of scope? I could > >> imagine that the way how Jane configures access control policies when > >> she integrates the light bulb into her home is quite similar to the way > >> how she would do that for George. > >> > >> I am also wondering what you mean by "Jane wants him [George] to be able > >> to control the new device with his smart phone without the need for > >> additional administration effort.". I am sure it again requires some > >> configuration. It might not require any effort for George but someone > >> has to do that since otherwise how should the authorization server know > >> that it has to grant permissions to George to turn the light on or off. > >> > >> In Section 2.2.3. you describe the case for remotely letting in a > >> visitor. Would it be possible to add a scenario that is less > >> sophisticated since this scenario requires some form of messaging > >> infrastructure to exist. > > > >> > >> Here is what I have in mind: > >> > >> ----- > >> > >> Jane and George have equipped their home with Internet connected > >> door-locks. > >> > >> Joe, a friend of George, frequently visits them and they would like to > >> give them access to their home. Once, when Joe was at their home George > >> uses his smart phone to create a digital access token. He > >> transfers that access token to Joe's phone using short range radio > >> communication technology. The token allows Joe to open the door. > >> > >> Jane and George know that they can revoke access at any time and are > >> also able to modify the permissions with that access token. Joe is also > >> not able to use the obtained access token to mint new access tokens to > >> grant his friends to gain access to the house of Jane and George. > >> > >> ----- > >> > > > > I don't really understand why we should take the remote access out of > > this use case. It would be a very severe limitation if authorization > > policies for the constrained devices cannot be configured remotely. > > > > > > Best regards, > > Steffi > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a11c37e022e781e050c5e987e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Can the following also be considere= d as a use case?

"
The owners of th= e automated home want to be intimated of any violations of the access contr= ol policies. Say the automation system detects a person in the house when t= he owner has locked down everything and is on a vacation. The system should= then immediately intimate the owners about the breach.
"= ;

Thanks
Sandeep

On Mon, Jan 5, 2015 at 7:08= PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> w= rote:
Hi Steffi,

happy new year to you as well.

My text suggestion was for an additional exchange that passes
authorization credentials to another person in a f2f fashion. I thought
that this could be useful since the remote version requires a lot of
other infrastructure to exist and raised the bar for building something
interoperable.

Ciao
Hannes


On 01/05/2015 02:32 PM, Stefanie Gerdes wrote:
> Hi everyone,
>
> I wish you all a happy new year!
>
>
> On 12/06/2014 01:12 PM, Hannes Tschofenig wrote:
>> I read through the home automation case and I have a few remarks.<= br> >>
>>
>> In Section 2.2.2. "Seamless Authorization" you write: >>
>> "
>>=C2=A0 =C2=A0 =C2=A0Jane buys a new light bulb for the corridor and= integrates it into
>>=C2=A0 =C2=A0 =C2=A0the home network (how she does that is not in s= cope).=C2=A0 George is not
>>=C2=A0 =C2=A0 =C2=A0at home, but Jane wants him to be able to contr= ol the new device with
>>=C2=A0 =C2=A0 =C2=A0his smart phone without the need for additional= administration
>>=C2=A0 =C2=A0 =C2=A0effort.
>> "
>>
>> Could you be a bit more specific about what is out of scope? I cou= ld
>> imagine that the way how Jane configures access control policies w= hen
>> she integrates the light bulb into her home is quite similar to th= e way
>> how she would do that for George.
>>
>> I am also wondering what you mean by "Jane wants him [George]= to be able
>> to control the new device with his smart phone without the need fo= r
>> additional administration effort.". I am sure it again requir= es some
>> configuration. It might not require any effort for George but some= one
>> has to do that since otherwise how should the authorization server= know
>> that it has to grant permissions to George to turn the light on or= off.
>>
>> In Section 2.2.3. you describe the case for remotely letting in a<= br> >> visitor. Would it be possible to add a scenario that is less
>> sophisticated since this scenario requires some form of messaging<= br> >> infrastructure to exist.
>
>>
>> Here is what I have in mind:
>>
>> -----
>>
>> Jane and George have equipped their home with Internet connected >> door-locks.
>>
>> Joe, a friend of George, frequently visits them and they would lik= e to
>> give them access to their home. Once, when Joe was at their home G= eorge
>> uses his smart phone to create a digital access token. He
>> transfers that access token to Joe's phone using short range r= adio
>> communication technology. The token allows Joe to open the door. >>
>> Jane and George know that they can revoke access at any time and a= re
>> also able to modify the permissions with that access token. Joe is= also
>> not able to use the obtained access token to mint new access token= s to
>> grant his friends to gain access to the house of Jane and George.<= br> >>
>> -----
>>
>
> I don't really understand why we should take the remote access out= of
> this use case. It would be a very severe limitation if authorization > policies for the constrained devices cannot be configured remotely. >
>
> Best regards,
> Steffi
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace


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


--001a11c37e022e781e050c5e987e-- From nobody Sun Jan 11 08:16: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 C29D31A7009 for ; Sun, 11 Jan 2015 08:15:59 -0800 (PST) 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 9afEaq98-OAR for ; Sun, 11 Jan 2015 08:15:57 -0800 (PST) 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 2E41F1A7008 for ; Sun, 11 Jan 2015 08:15:57 -0800 (PST) Received: from [172.16.254.109] ([80.92.123.55]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDn8s-1XztAr09TK-00H7UJ for ; Sun, 11 Jan 2015 17:15:55 +0100 Message-ID: <54B2A1BA.600@gmx.net> Date: Sun, 11 Jan 2015 17:15:54 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <54856F84.4040403@gmx.net> In-Reply-To: <54856F84.4040403@gmx.net> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <54856F84.4040403@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="66LlqmIvax3CWDh74h1AbCbVA4Vi3FCoV" X-Provags-ID: V03:K0:vgkztfYxRlm/9vVQRtcO9L64ukP2pB9JEDmnrDzgXjrPlUXPhJm DWPfniSbyiKV5XT1ctrAvmccUk+s5Q0yl+HReUYRliRI3bfm0JCSyjxgByYYEJYKdn3gy2g F9dhSxAvLzBrVIr4JeE4R8bIIpl7EJDlyXUOi2gRHSyYcZ/yy0HGYQx8+jiwlwd8JXw8hsY ysXtGhf9pNiRdsk8d/sHA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Fwd: Webinar on "Kantara User-Managed Access (UMA)" X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Jan 2015 16:16:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --66LlqmIvax3CWDh74h1AbCbVA4Vi3FCoV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Just a short reminder regarding the upcoming talk this week. Ciao Hannes PS: I will try to record it but I cannot promise that it actually works given the problems we had earlier. -------- Forwarded Message -------- Subject: [Ace] Webinar on "Kantara User-Managed Access (UMA)" Date: Mon, 08 Dec 2014 10:29:40 +0100 From: Hannes Tschofenig To: Ace@ietf.org CC: Eve Maler Hi all, earlier this year we organized a couple of webinars to hear about ACE- relevant technologies, including OAuth, Kerberos, and the PKI/certificate model. In a recent chat with Eve Maler, who co-chairs the Kantara User-Managed Access (UMA) working group, she volunteered to explain their ongoing work to us. Eve is employed by Forgerock, a company developing identity management solutions, and has been working in the identity management space for a very long time. UMA is a profile and application of OAuth that defines how resource owners can control resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. Recent investigations have shown promise for applying UMA to Internet of Things authorization use cases. The webinar will take place on January 13th 2015 at 8am PST. We are looking forward to hear from Eve. Ciao Hannes & Kepeng --------- Here is the Webex meeting info. Webex Link: https://ietf.webex.com/ietf/j.php?MTID=3Dmf6d0740b7959df0377a74117c49a0ff= 3 Meeting #: 641 684 081 Meeting password: test Join by phone: +1-877-668-4493 Call-in toll free number (US/Canada) +1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 684 081 (As mentioned during earlier calls, the IETF Webex bridge does not offer other dial-in numbers. If you want to dial-in from remote please use Skype or some other VoIP tool to keep the costs at a reasonable level.) Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=3Dmaca56e1e06cf3b2bc8322bd9a6d5afb= a We are planning to enable recording but we do not promise that it will work since there have been problems with the IETF Webex configuration in the past. --66LlqmIvax3CWDh74h1AbCbVA4Vi3FCoV 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 iQEcBAEBCgAGBQJUsqG6AAoJEGhJURNOOiAtAKsIAJiyfeJn2d1YizL6+96Wp2cx OdIcy+5vXua9uZZUBfO6gdA2S6yDekmhUYcze++OKasYbWSNjS3XuLz3YFua/OcA 65gQq4d77SASZqnoUuyvvSmA8djGC286LcRCHKy53kcQ8LZmYyeKPQArvh1+v8mw WTZzENB+kv9yPPcGX8hPMkvIWj5W+t5n4l7nrnuQ6bXZHjfVYB+LuwfZdxVogQaI 34jQ8OFvkJ4rI+Hq5pi3FCBH8O725rXehTjbD6ce1B6AB/rhQjpHRCOMV5GwyUC/ HK3zCzJ8HvUGAmRtRNca7PlqAEfYlxZTv5zz7JmhE3uzhoLqN0/olSfRrPACZ6A= =xPjZ -----END PGP SIGNATURE----- --66LlqmIvax3CWDh74h1AbCbVA4Vi3FCoV-- From nobody Tue Jan 13 03:37:28 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 B85201A8A9C for ; Tue, 13 Jan 2015 03:37:26 -0800 (PST) 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 8vstJaoboHth for ; Tue, 13 Jan 2015 03:37:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9FE1A8A8F for ; Tue, 13 Jan 2015 03:37:24 -0800 (PST) Received: from [192.168.131.144] ([80.92.123.55]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MgHHO-1YNjTY19Tq-00NgvG for ; Tue, 13 Jan 2015 12:37:22 +0100 Message-ID: <54B50371.7040306@gmx.net> Date: Tue, 13 Jan 2015 12:37:21 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <54B3947B.6090002@gmx.net> In-Reply-To: <54B3947B.6090002@gmx.net> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <54B3947B.6090002@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d79kqff758r4eh7rEdwN7h08uRrWJV2NW" X-Provags-ID: V03:K0:8QhE9aMYH0rDvZKI4w4oW338MbJA1vLpuaEe0x8b8YC/pc2lb+g LSd0DaWt1i665c8PNCTZkIknHaEMflRif91Rnm4d4bA3o/upK8nX/3ud95lvnelDE2HUpyk gyRHR59mDmW8L3Y0+E0810MbnFrOR+KIG2Kck9xIBpZ165uQNVRc+nZcIlHQFdhXBUaZD6B 9cixdp4/ZfAq2AdS+E2mg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Fwd: Re: Container Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 13 Jan 2015 11:37:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d79kqff758r4eh7rEdwN7h08uRrWJV2NW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable actually wanted to send this to the mailing list. -------- Forwarded Message -------- Subject: Re: [Ace] Container Use Case Date: Mon, 12 Jan 2015 10:31:39 +0100 From: Hannes Tschofenig To: G=C3=B6ran Selander , Stefanie Gerdes , Ludwig Seitz CC: Likepeng Hi Goeran, thanks for your detailed review. Let me respond to the following question you raised in your review: On 01/12/2015 08:41 AM, G=C3=B6ran Selander wrote: > Recall that section 4 of [1] is to a large extent the result of a >> discussion at the (informal) ACE meeting in Stockholm in June 2014. >> Obviously we didn't agree on everything at the meeting, as is also >> indicated in the draft, but some terms and assumptions were agreed and= I >> think it would save us time to re-use some of this either in the use c= ase >> draft or in a separate [architecture?] draft. >>=20 >> WG chairs/AD/anyone: Do you have an opinion about whether (a) there sh= ould >> be a separate [architecture?] draft describing additional terminology = and >> assumptions of the solution space, or (b) if this should be fitted int= o >> the security considerations of the use case draft, or (c) each solutio= n >> proposal should make its own assumptions and terminology? The charter= >> does not include an architecture document which I guess speaks in favo= r of >> (b) and (c). Currently, we only have the use case document and the solution document(s) in the charter and nothing else. As mentioned in earlier discussions I think it makes sense to include useful terminology in this document but there will for sure be terminology that is very solution specific and such terminology could best be included in a solution document. For example, I believe the following terms would be very useful to have in the use case document: * Authorization Server * (Constrained) Client * (Constrained) Resource Server * Resource Owner (RO) We could reference other security documents for basic security terms (such as RFC 3552 and/or RFC 4949) regarding authentication, authorization, integrity, confidentiality, non-repudiation, accounting, etc.) There are, however, a few things I am not sure about. When it comes to ownership the story gets a bit complex as the devices is owned and not necessarily a role (such as a client or a server role). Embedded in this ownership concept into the terminology seems to imply a notion about who has access to data on that device. Of course, ownership does not automatically imply access to data. So, it is not clear to me whether focusing on ownership is the right way to cast the story. I am also looking for input from the group whether there is interest to include different forms of authorization servers. The authorization server of the client, and the server, for example. In some cases there is no just one authorization server for a given entity but a chain of servers (particularly in the enterprise world) when you delegate certain rights to other parties. Is this worthwhile to discuss/to include? Sometimes in the identity management space there is also the desire to separate the entity that does the authentication from the entity that does the authorization. Is this useful in our case? When attributes come into the picture then these attributes may not all come from the same entity. The authentication attributes are a simple example, which may come from a separate authentication server. In theory attributes can came from various sources. Regarding the assumptions I think the same approach as with terminology applies. It is reasonable to state assumptions in the use case document (which are today implicit). For example, an assumption covered in the use case document is that there is an authorization server and that devices have credentials pre-provisioned with that authorization server. Ciao Hannes --d79kqff758r4eh7rEdwN7h08uRrWJV2NW 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 iQEcBAEBCgAGBQJUtQNxAAoJEGhJURNOOiAtooQH/iXeQLZ6LWO3w4S6ooHRCdfF MTSGg0a7QxZuVC+PtWih5uDm6fJeSxj/6mff5C/5Y3tJt68dGips8AYBN1EmMxEK BSkFOio0MxxDwr2X2b30JG3KSUkUjYnuqJLKY3g536q9GOPsMMcHtlT8N3pd2Z8G GKmktGNOmPYuDf22SFravA/fdoqt/Jt67d/PCn6cFte1rSuyeh+rfEo49K9kxQPd 47II8Nxthx7Lq8Hv5bkhvvDBwcZcqtG6le8o3lz6jWZAMhV89ldGsaqf88JzpIrQ Ku8JwGBfnYLzPxKgt08TYPJ6Ifl8Di/KxEgRn/ZOViKVh0G156BO1nlBB4W8IIc= =Cw2d -----END PGP SIGNATURE----- --d79kqff758r4eh7rEdwN7h08uRrWJV2NW-- From nobody Tue Jan 13 03:56:21 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 C62A31A8AA8 for ; Tue, 13 Jan 2015 03:56:20 -0800 (PST) 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 Mv7sND7GV4x7 for ; Tue, 13 Jan 2015 03:56:17 -0800 (PST) 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 6B1BA1A1B75 for ; Tue, 13 Jan 2015 03:56:17 -0800 (PST) Received: from [192.168.131.144] ([80.92.123.55]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MYx2x-1YFn9p2U8R-00Vd1u for ; Tue, 13 Jan 2015 12:56:14 +0100 Message-ID: <54B507DE.5030800@gmx.net> Date: Tue, 13 Jan 2015 12:56:14 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: In-Reply-To: OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kAodbxXtuoK4oeR9aqBbLRKNSl0w6rrvO" X-Provags-ID: V03:K0:TLvAXy1ZFJyhNzDm4FwE81NM77XDpIx48gTw/gA21DU40KfU7M7 iMYBYOlseL7eLjinePOTj3bTk+C/98zZJEEtjmpM4tESt/qlqfSyMrMSRkimHjB7ltp79xr n54UNWgk1jMj0aWXe738MhTp2gBRqkfbnSgr7Fxmti28Rs9v4ISKRxRJSnLmvsifDOdY/Xa gSQhJYEOFurlbnkoE+Rsw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Fwd: Re: Container Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 13 Jan 2015 11:56:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kAodbxXtuoK4oeR9aqBbLRKNSl0w6rrvO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI: message from Goeran. -------- Forwarded Message -------- Subject: Re: [Ace] Container Use Case Date: Tue, 13 Jan 2015 09:31:17 +0000 From: G=F6ran Selander To: Hannes Tschofenig , Stefanie Gerdes , Ludwig Seitz , Kumar, Sandeep , Mehdi.Mani@itron.com CC: Likepeng Hi Hannes, Also including the other co-authors (or did you intend to send it on the ACE list?) Some comments inline. On 2015-01-12 10:31, "Hannes Tschofenig" wrot= e: >Hi Goeran, > >thanks for your detailed review. Let me respond to the following >question you raised in your review: > >On 01/12/2015 08:41 AM, G=F6ran Selander wrote: >> Recall that section 4 of [1] is to a large extent the result of a >>> discussion at the (informal) ACE meeting in Stockholm in June 2014. >>> Obviously we didn't agree on everything at the meeting, as is also >>> indicated in the draft, but some terms and assumptions were agreed an= d >>>I >>> think it would save us time to re-use some of this either in the use >>>case >>> draft or in a separate [architecture?] draft. >>>=20 >>> WG chairs/AD/anyone: Do you have an opinion about whether (a) there >>>should >>> be a separate [architecture?] draft describing additional terminology= >>>and >>> assumptions of the solution space, or (b) if this should be fitted in= to >>> the security considerations of the use case draft, or (c) each soluti= on >>> proposal should make its own assumptions and terminology? The charte= r >>> does not include an architecture document which I guess speaks in >>>favor of >>> (b) and (c). > >Currently, we only have the use case document and the solution >document(s) in the charter and nothing else. > >As mentioned in earlier discussions I think it makes sense to include >useful terminology in this document but there will for sure be >terminology that is very solution specific and such terminology could >best be included in a solution document. > >For example, I believe the following terms would be very useful to have >in the use case document: > > * Authorization Server > > * (Constrained) Client > > * (Constrained) Resource Server > > * Resource Owner (RO) This is fine by me, but see below. > >We could reference other security documents for basic security terms >(such as RFC 3552 and/or RFC 4949) regarding authentication, >authorization, integrity, confidentiality, non-repudiation, accounting, >etc.) > >There are, however, a few things I am not sure about. > >When it comes to ownership the story gets a bit complex as the devices >is owned and not necessarily a role (such as a client or a server role).= >Embedded in this ownership concept into the terminology seems to imply a= >notion about who has access to data on that device. Of course, ownership= >does not automatically imply access to data. So, it is not clear to me >whether focusing on ownership is the right way to cast the story. > >I am also looking for input from the group whether there is interest to >include different forms of authorization servers. The authorization >server of the client, and the server, for example. In some cases there >is no just one authorization server for a given entity but a chain of >servers (particularly in the enterprise world) when you delegate certain= >rights to other parties. Is this worthwhile to discuss/to include? We have had this discussion before and there are different models. My proposal was that we maybe could get around re-iterating the previous discussion by looking carefully at the functions, in particular authorization decision and authorization enforcement split. Since authorization is about making decisions we should answer the question wha= t role takes this decision and what role is enforcing the decision. This provides a set of necessary roles which should be termed in the use case document to allow a good discussion of security considerations. As a natural consequence of this the PEP need to access =B3authorization information=B2 from the PDP. And this access needs to be secured. This is= also a necessary part of the architecture, independent of solution, and should IMHO be part of the security considerations of the use case document. draft-seitz-ace-problem-description provides one example of how to term and structure this, but it may be expressed in different ways. > >Sometimes in the identity management space there is also the desire to >separate the entity that does the authentication from the entity that >does the authorization. Is this useful in our case? I think that this is not strictly necessary in our case. In my opinion there are two parts: 1. how the PEP securely access authorization information (as mentioned above) 2. how the authorization information is used by the PEP to secure the resource access The second part also includes the security protocol between client and resource server, which may depend on the authorization information. For example: access to resource X for the holder of key Y means that the PEP must verify that the requesting entity has key Y, or at least protect the= resource such that only can be accessed with possession of key Y. We should also have a high level understanding of what the authorization information contains, i.e. what are the different options: for example authorization decisions or capability lists. But we don=B9t need to speci= fy *how* the authorization information is produced, e.g. how the client was authenticated (even if this may be included in the authorization information). Moreover the authorization decision may not require the identity of the entity: it may be sufficient that the entity has the right key (producing= a correct MAC). In practice different different roles may require different proofs from the requesting client: The PDP may require the client to authenticate, whereas the PEP will settle for key confirmation.= So I don=B9t think we need to include the authentication server as a separate entity, but I do think we should keep integrity protection and encryption of resource access as part of the authorization procedure. > >When attributes come into the picture then these attributes may not all >come from the same entity. The authentication attributes are a simple >example, which may come from a separate authentication server. In theory= >attributes can came from various sources. Yes, but I think we should avoid this complication and stay on the level of =B3authorization information=B2 which in principle may contain authentication attributes, come from different sources etc. but let=B9s n= ot assume that in the first place. > >Regarding the assumptions I think the same approach as with terminology >applies. It is reasonable to state assumptions in the use case document >(which are today implicit). For example, an assumption covered in the >use case document is that there is an authorization server and that >devices have credentials pre-provisioned with that authorization server.= OK by me. We should also be explicit that this could be either symmetric keys or public keys. Regards G=F6ran --kAodbxXtuoK4oeR9aqBbLRKNSl0w6rrvO 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 iQEcBAEBCgAGBQJUtQfeAAoJEGhJURNOOiAta+4H/RbOGlX4yyEOYLUYghUsTXL/ QBchC5oseaQ7RfdnOB05HIv7BujeBRphlXBkMAfwshiLJ/uISTsFDTHRVum3jgIF jn3UIc+4908kIWuBPcupRXSSn5xEky1AU18YeI4S3bEa0AFl9MXvViULcTBCHz9r e4n/8Z+BeAnWG8f+Isf8+0WLW/OQGMHQRiSkU5ixf2zUxiJ54Xq3w51Vm1nkqike XYKteQLF8Sfk+MR0HT5oWwvrZu7CjXYQYAocTcDs/Gcrv+OetRdXGdgE5WeveQCw kg970vJi8KXiclJxqyMf7gokHP8RwUdpwFvbZpUC/MILQmlXiw7SPjOosyQ+Xwo= =s9uw -----END PGP SIGNATURE----- --kAodbxXtuoK4oeR9aqBbLRKNSl0w6rrvO-- From nobody Tue Jan 13 03:56: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 682641A8AAB for ; Tue, 13 Jan 2015 03:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_81=0.6, 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 vrPoW2FAU7Th for ; Tue, 13 Jan 2015 03:56:33 -0800 (PST) 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 395411A1B75 for ; Tue, 13 Jan 2015 03:56:33 -0800 (PST) Received: from [192.168.131.144] ([80.92.123.55]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MS5QA-1YMeuo1tlq-00TB7a; Tue, 13 Jan 2015 12:56:08 +0100 Message-ID: <54B507D7.3000902@gmx.net> Date: Tue, 13 Jan 2015 12:56:07 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?G=F6ran_Selander?= , Stefanie Gerdes , Ludwig Seitz , "Kumar, Sandeep" , "Mehdi.Mani@itron.com" References: <54807796.7030504@gmx.net> <5481D0B9.6020905@tzi.de> <54B3947B.6090002@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xo5U3RV9VlgTsC6df3RdevFtA5aQj07TC" X-Provags-ID: V03:K0:PB2OHfxNUvBB0vhRnGNkAg9nLRJWpYZYkek0KWw1SvlaN8wjCs6 qXCZvtW4VG0Ovb9MCf3xLdvPs0cwhpa09ujxEWYuE3fUVuCBStmUkryBK52AroOv5xcQrlv yli2wdONT17uoxlaitzoJBqHlULokiSMCclA5Q0Wmc8BQDKqetZvH6WeaTpyOr5rSUEHzOP PrNwOFt2BPSeba8phTReA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Likepeng , "Ace@ietf.org" Subject: Re: [Ace] Container Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 13 Jan 2015 11:56:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xo5U3RV9VlgTsC6df3RdevFtA5aQj07TC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Goeran, a quick response. ~snip~ Summary of proposal by Goeran: Look at what role makes authorization decision and what role is enforcing it. >=20 > As a natural consequence of this the PEP need to access =B3authorizatio= n > information=B2 from the PDP. And this access needs to be secured. This = is > also a necessary part of the architecture, independent of solution, and= > should IMHO be part of the security considerations of the use case > document. >=20 > draft-seitz-ace-problem-description provides one example of how to term= > and structure this, but it may be expressed in different ways. I guess you are particularly pointing to Section 3 of https://tools.ietf.org/html/draft-seitz-ace-problem-description-02#sectio= n-3 (which defines the problem description). The content makes sense to me; I only have a minor remark. There are different models for authorization, namely 1) The PEP gets the authorization information from the PDP. Think about an actual policy sent to the PEP in the form of "IF request used key X and resource=3DY THEN accept ELSE deny" statements. 2) The PEP gets only the decision of the authorization request from the PDP. This is a YES and NO decision. 3) Then, there is the approach of entitlements. Here you define an abstract term like 'email' and that has a specific meaning for the RS. For example, it means 'client is requesting to send emails notifications by the RS.' I got the impression that your description focuses on #1. Is that correct= ? (We can actually ask Eve today to talk about this issue since she has a long history with the standardization of access control policies.) >=20 >=20 >> >> Sometimes in the identity management space there is also the desire to= >> separate the entity that does the authentication from the entity that >> does the authorization. Is this useful in our case? >=20 >=20 > I think that this is not strictly necessary in our case. In my opinion > there are two parts: >=20 > 1. how the PEP securely access authorization information (as mentioned > above) > 2. how the authorization information is used by the PEP to secure the > resource access=20 >=20 > The second part also includes the security protocol between client and > resource server, which may depend on the authorization information. For= > example: access to resource X for the holder of key Y means that the PE= P > must verify that the requesting entity has key Y, or at least protect t= he > resource such that only can be accessed with possession of key Y. I was more talking about the authentication of the client (or the user) rather than authentication of the RS. Of course, there is no need to always do authentication and authorization into separate entities. >=20 > We should also have a high level understanding of what the authorizatio= n > information contains, i.e. what are the different options: for example > authorization decisions or capability lists. But we don=B9t need to spe= cify > *how* the authorization information is produced, e.g. how the client wa= s > authenticated (even if this may be included in the authorization > information). This is a good idea. >=20 > Moreover the authorization decision may not require the identity of the= > entity: it may be sufficient that the entity has the right key (produci= ng > a correct MAC). In practice different different roles may require > different proofs from the requesting client: The PDP may require the > client to authenticate, whereas the PEP will settle for key confirmatio= n. I agree. It might purely be trait-based. >=20 > So I don=B9t think we need to include the authentication server as a > separate entity, but I do think we should keep integrity protection and= > encryption of resource access as part of the authorization procedure. It is certainly an architectural decision to think about. In the AAA/EAP case the EAP server is logically separated from the AAA server even though they may often reside in the same box. >=20 >=20 >> >> When attributes come into the picture then these attributes may not al= l >> come from the same entity. The authentication attributes are a simple >> example, which may come from a separate authentication server. In theo= ry >> attributes can came from various sources. >=20 > Yes, but I think we should avoid this complication and stay on the leve= l > of =B3authorization information=B2 which in principle may contain > authentication attributes, come from different sources etc. but let=B9s= not > assume that in the first place. Thanks for the feedback. >=20 >=20 >> >> Regarding the assumptions I think the same approach as with terminolog= y >> applies. It is reasonable to state assumptions in the use case documen= t >> (which are today implicit). For example, an assumption covered in the >> use case document is that there is an authorization server and that >> devices have credentials pre-provisioned with that authorization serve= r. >=20 > OK by me. We should also be explicit that this could be either symmetri= c > keys or public keys. I think we should be explicit about it. I don't think we even made a decision yet about this topic yet but it would be good to get an agreement since it will obviously impact the solution space. Ciao Hannes >=20 > Regards > G=F6ran >=20 --xo5U3RV9VlgTsC6df3RdevFtA5aQj07TC 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 iQEcBAEBCgAGBQJUtQfXAAoJEGhJURNOOiAtU9MIAIR9Cyg/WY7WW3DbYNKEdL7m 8ys+kkTrraPqNXw4K/CBFcz+T664avvDq5AMPTbQ+/1aqE1k5eElWdlQIRJr15MT lwKlLfUjzRjVQgWZJ2+gXJgua8LydwkXYroIb3g2USJ7Tho6sDu3URcZAY/DCBbG w+sEGzF1lS+xc9t+J1f8qos1P5IPAZBPvWsOS6KgauimUHnYWEs2+589BdedewPg VQPexlXZpWlq2WLBbTShidzIrExq0EbeRtqKnxThi1h6cOMNUha+FwiCg+0izAhz 78t4MZqnmqA1Ln3qSxpzWkx1kHogDM8MQQSZY+XpHAi3EbAR873JZMmusjL+bio= =ezLf -----END PGP SIGNATURE----- --xo5U3RV9VlgTsC6df3RdevFtA5aQj07TC-- From nobody Tue Jan 13 05:00:17 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 3B3AB1A8AC6 for ; Tue, 13 Jan 2015 05:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-h86kHsoj81 for ; Tue, 13 Jan 2015 05:00:13 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id C9D001A8AC3 for ; Tue, 13 Jan 2015 05:00:12 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id E6BCFED73 for ; Tue, 13 Jan 2015 14:00:11 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t0DD0BdX012397 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 13 Jan 2015 14:00:11 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 88BE550D for ; Tue, 13 Jan 2015 14:00:11 +0100 (CET) Message-ID: <54B516DA.6050104@sics.se> Date: Tue, 13 Jan 2015 14:00:10 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "ace@ietf.org" References: <20150113125529.11446.69474.idtracker@ietfa.amsl.com> In-Reply-To: <20150113125529.11446.69474.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150113125529.11446.69474.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090009090204010406030402" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NDp0bNL - bdf016ce2d66 - 20150113 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NDp0bNL&m=bdf016ce2d66&t=20150113&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NDp0bNL&m=bdf016ce2d66&t=20150113&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NDp0bNL&m=bdf016ce2d66&t=20150113&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 13:00:16 -0000 This is a cryptographically signed message in MIME format. --------------ms090009090204010406030402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable We have updated the document, trying to address the comments received=20 from Hannes, Sean Turner and Michael Richardson. We will continue updating the document to address new comments (and old=20 one we might have missed), but we felt it was useful to post an update=20 in order to close some of the issues and avoid re-discussing them. /Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-01.txt Date: Tue, 13 Jan 2015 04:55:29 -0800 From: internet-drafts@ietf.org To: Mehdi Mani , Sandeep Kumar=20 , Goeran Selander=20 , Sandeep S. Kumar=20 , Ludwig Seitz , Goran=20 Selander , Stefanie Gerdes=20 , Stefanie Gerdes , Ludwig Seitz=20 , Mehdi Mani A new version of I-D, draft-ietf-ace-usecases-01.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 01 Title: ACE use cases Document date: 2015-01-13 Group: ace Pages: 24 URL:=20 http://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/= Htmlized: http://tools.ietf.org/html/draft-ietf-ace-usecases-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecase= s-01 --------------ms090009090204010406030402 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 KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAxMTMxMzAwMTBaMCMGCSqGSIb3DQEJBDEW BBSOcZfBtKjaobNwtL2RJ1eKqno0TDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAq74sNrrdclFD7ambJYi8mMkbIpJfAWxTmofRXhQ3BMvO9JdevunNWSpklZZWUHLcqJIa z1XZ8dgc2UoKOw/LfF+aHyNHFahqStRxTmbt1LLBLVxXGnQ4oo4yepySCzB907OssiOPxIrc kNgy8Q15LObX6MJf+hBlqlbRHnS3q45f1a4Mdz2et9yB9pT/Zty2S6w3gxKnch/P8t45r7Vv SbfWjQbIYOvX85dd+DayOroMBj2OESf16orxiquFNn6Aqq0EnSM82B7JmQvnWDBhDRWJJTQd rrFJ7r1yrFgE5wRKeSweHp5s+5f+ZNJXPDn/WyXhYmsqnZYiZj60gThqzQAAAAAAAA== --------------ms090009090204010406030402-- From nobody Tue Jan 13 05:14:58 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC40C1A8AC6 for ; Tue, 13 Jan 2015 05:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_81=0.6, 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 95Za0TZR8X6q for ; Tue, 13 Jan 2015 05:14:52 -0800 (PST) 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 E65DA1A8AC4 for ; Tue, 13 Jan 2015 05:14:51 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-fa-54b51a498582 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 17.A5.04231.94A15B45; Tue, 13 Jan 2015 14:14:49 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.38]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 14:14:48 +0100 From: =?windows-1254?Q?G=F6ran_Selander?= To: Hannes Tschofenig Thread-Topic: [Ace] Container Use Case Thread-Index: AQHQD9NllQ+W4xnHo06VfJeSgjYakZyBEb6AgDhmLoCAAs3+AIAAHs2AgAGi3ACAABfWgIAAJsGA Date: Tue, 13 Jan 2015 13:14:48 +0000 Message-ID: References: <54807796.7030504@gmx.net> <5481D0B9.6020905@tzi.de> <54B3947B.6090002@gmx.net> <54B507D7.3000902@gmx.net> In-Reply-To: <54B507D7.3000902@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.146] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM+Jvja6n1NYQg+k3lCy+f+thtth48S6j xdKd91gt9hxuYrZ41XqH2WL5zDiLJYcXMTqweyzetJ/No+XIW1aPJUt+MnnM+X2W1ePAgd1M Hr3HfrN5bHv7lTmAPYrLJiU1J7MstUjfLoEro+FoVEG7ccW10/eZGxiXaXYxcnBICJhI/D9d 18XICWSKSVy4t56ti5GLQ0jgCKPEsyPvWCGcxYwS2388YwOpYhNwl5izdyULiC0iYChxfeZ0 sCJmgSeMEuseXQYrEhZQlbhzdRITRJGaxLbJO6AaoiR2bNnKDmKzANVc+nwXzOYVsJA4+vUb M8S2HiaJs1vfMYIkOAXUJU6c6AezGYHu+35qDdhQZgFxiVtP5jNB3C0gsWTPeWYIW1Ti5eN/ rCC2qICexMrrTWwQcSWJHxsusUD0GkgcOXeTFeR9ZgFriZ2b5SHC2hLLFr5mhrhHUOLkzCcs ExglZiHZNgtJ9yyE7llIumch6V7AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzDOD275 rbuDcfVrx0OMAhyMSjy8Bl1bQoRYE8uKK3MPMUpzsCiJ8+Y5bAgREkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwCgjNGPOk7ybFi4Cl+r3FHz8EfTzltaarUYN2a033Y6/VSs/3L9wtszs6xeK ZktIsvoyfBd4PUlrttAbzsD8CRlJ+6QNHf9cTWJuZO3YPmH9juRL+b7qlxbt+7y26wLflldO Kfe0WXfk8faYBHpOOrRPVPzihNil3Xf+vlz05kbq/5CZk7k1Z51QYinOSDTUYi4qTgQAyk71 A9QCAAA= Archived-At: Cc: "Mehdi.Mani@itron.com" , Likepeng , "Ace@ietf.org" , Stefanie Gerdes , Ludwig Seitz , "Kumar, Sandeep" Subject: Re: [Ace] Container Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 13 Jan 2015 13:14:56 -0000 Hi Hannes Thanks for quick reply and good comments, some answers/comments inline. On 2015-01-13 12:56, "Hannes Tschofenig" wrote: >Hi Goeran, > >a quick response. > > >~snip~ > >Summary of proposal by Goeran: Look at what role makes authorization >decision and what role is enforcing it. > >>=20 >> As a natural consequence of this the PEP need to access =B3authorization >> information=B2 from the PDP. And this access needs to be secured. This i= s >> also a necessary part of the architecture, independent of solution, and >> should IMHO be part of the security considerations of the use case >> document. >>=20 >> draft-seitz-ace-problem-description provides one example of how to term >> and structure this, but it may be expressed in different ways. > >I guess you are particularly pointing to Section 3 of >https://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section >-3 >(which defines the problem description). Yes, but it is more compactly summarized in sections 4.3 - 4.5 https://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section- 4.3 > >The content makes sense to me; I only have a minor remark. >There are different models for authorization, namely > >1) The PEP gets the authorization information from the PDP. Think about >an actual policy sent to the PEP in the form of "IF request used key X >and resource=3DY THEN accept ELSE deny" statements. > >2) The PEP gets only the decision of the authorization request from the >PDP. This is a YES and NO decision. > >3) Then, there is the approach of entitlements. Here you define an >abstract term like 'email' and that has a specific meaning for the RS. >For example, it means 'client is requesting to send emails notifications >by the RS.' > >I got the impression that your description focuses on #1. Is that correct? All these are encompassed in the term =93authorization information=94, so, = no, #2 and #3 are not a priori excluded. In section 4.4 we used the term =93access control policy=94, =93authorization decision=94 and =93client cap= ability=94 which I believe maps to 1, 2 and 3, respectively. > >(We can actually ask Eve today to talk about this issue since she has a >long history with the standardization of access control policies.) > >>=20 >>=20 >>> >>> Sometimes in the identity management space there is also the desire to >>> separate the entity that does the authentication from the entity that >>> does the authorization. Is this useful in our case? >>=20 >>=20 >> I think that this is not strictly necessary in our case. In my opinion >> there are two parts: >>=20 >> 1. how the PEP securely access authorization information (as mentioned >> above) >> 2. how the authorization information is used by the PEP to secure the >> resource access=20 >>=20 >> The second part also includes the security protocol between client and >> resource server, which may depend on the authorization information. For >> example: access to resource X for the holder of key Y means that the PEP >> must verify that the requesting entity has key Y, or at least protect >>the >> resource such that only can be accessed with possession of key Y. > > >I was more talking about the authentication of the client (or the user) >rather than authentication of the RS. Yes, so did I. Maybe I misunderstood or confused the terminology? I=92m mainly thinking of PDP =3D Authorization Server and PEP =3D Resource Server= , but don=92t want to exclude other cases. > >Of course, there is no need to always do authentication and >authorization into separate entities. Agree=20 > >>=20 >> We should also have a high level understanding of what the authorization >> information contains, i.e. what are the different options: for example >> authorization decisions or capability lists. But we don=B9t need to >>specify >> *how* the authorization information is produced, e.g. how the client was >> authenticated (even if this may be included in the authorization >> information). > >This is a good idea. > >>=20 >> Moreover the authorization decision may not require the identity of the >> entity: it may be sufficient that the entity has the right key >>(producing >> a correct MAC). In practice different different roles may require >> different proofs from the requesting client: The PDP may require the >> client to authenticate, whereas the PEP will settle for key >>confirmation. > >I agree. It might purely be trait-based. > > >>=20 >> So I don=B9t think we need to include the authentication server as a >> separate entity, but I do think we should keep integrity protection and >> encryption of resource access as part of the authorization procedure. > >It is certainly an architectural decision to think about. In the AAA/EAP >case the EAP server is logically separated from the AAA server even >though they may often reside in the same box. > >>=20 >>=20 >>> >>> When attributes come into the picture then these attributes may not all >>> come from the same entity. The authentication attributes are a simple >>> example, which may come from a separate authentication server. In >>>theory >>> attributes can came from various sources. >>=20 >> Yes, but I think we should avoid this complication and stay on the level >> of =B3authorization information=B2 which in principle may contain >> authentication attributes, come from different sources etc. but let=B9s >>not >> assume that in the first place. > >Thanks for the feedback. > >>=20 >>=20 >>> >>> Regarding the assumptions I think the same approach as with terminology >>> applies. It is reasonable to state assumptions in the use case document >>> (which are today implicit). For example, an assumption covered in the >>> use case document is that there is an authorization server and that >>> devices have credentials pre-provisioned with that authorization >>>server. >>=20 >> OK by me. We should also be explicit that this could be either symmetric >> keys or public keys. > >I think we should be explicit about it. I don't think we even made a >decision yet about this topic yet but it would be good to get an >agreement since it will obviously impact the solution space. Yes, at least when we dig down into the details. Since we don=92t have an architecture draft, I understand these type of decisions should be recorded in the use case document. Regards, G=F6ran From nobody Tue Jan 13 06:37: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 10B4A1A8AF5 for ; Tue, 13 Jan 2015 06:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd-a9-Tjt5qE for ; Tue, 13 Jan 2015 06:37:42 -0800 (PST) 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 0AEDF1A8AA6 for ; Tue, 13 Jan 2015 06:37:41 -0800 (PST) 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 t0DEbXhp006329; Tue, 13 Jan 2015 15:37:33 +0100 (CET) Received: from [IPv6:2001:638:708:30da:7da3:1876:c92a:ba10] (unknown [IPv6:2001:638:708:30da:7da3:1876:c92a:ba10]) (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 3kMDs86n2xz83jD; Tue, 13 Jan 2015 15:37:32 +0100 (CET) Message-ID: <54B52DAB.5020804@tzi.de> Date: Tue, 13 Jan 2015 15:37:31 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?G=F6ran_Selander?= , Ludwig Seitz References: <54807796.7030504@gmx.net> <5481D0B9.6020905@tzi.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Container Use Case X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 14:37:45 -0000 Hi Göran, On 01/10/2015 12:51 PM, Göran Selander wrote: > Hi Steffi and Ludwig, > > (Also a question for WG chairs / AD a few paragraphs below) > > > > I¹ve read through the ACE use case draft with fresh eyes and have some > comments. Since I know the draft is in transition I will not go into > detail in this mail. Could you please let me know if you plan to address > the comments below or not in the next version? > > The main overall comment is that there is a great deal of overlapping > material between section 3 of the use case draft and section 4 of > draft-seitz-ace-problem-description: > > [1] > http://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section-4 > > Recall that section 4 of [1] is to a large extent the result of a > discussion at the (informal) ACE meeting in Stockholm in June 2014. > Obviously we didn't agree on everything at the meeting, as is also > indicated in the draft, but some terms and assumptions were agreed and I > think it would save us time to re-use some of this either in the use case > draft or in a separate [architecture?] draft. > > WG chairs/AD/anyone: Do you have an opinion about whether (a) there should > be a separate [architecture?] draft describing additional terminology and > assumptions of the solution space, or (b) if this should be fitted into > the security considerations of the use case draft, or (c) each solution > proposal should make its own assumptions and terminology? The charter > does not include an architecture document which I guess speaks in favor of > (b) and (c). There already was some discussion about this during the last ACE session in Honolulu. I really don't like the idea to mix up use cases, architecture and solutions. The terminology in the use cases draft should only contain the terminology actually used in there. Additional terminology will likely be solution specific. Since we don't know yet which solution fits best it will be more useful to leave this discussion for later. We will gain more from the use cases document if we focus on its main purpose: summarizing the main problems in representative use cases. If it is obvious that there are documents missing in the milestones that would be useful for the work in ACE, it might be better to add them instead of trying to press topics into a document where they don't really fit and will blur the focus. > Here are the comments: > > Section 3.1 "Attacks" > - The last part of the section describes properties of constrained devices > that may need to be considered also for performance reasons, not just > attack mitigation. How about renaming the section "Constrained device > aspects" or "Constrained devices" or similar? > > - Section 4.2 of [1] contains a list of partly overlapping features of > constrained devices. Does it makes sense to include in the use case draft > other features of section 4.2 in [1] which are not currently in? For > example that some constrained devices may be unable to manage complex > authorization policies or unable to precisely measure time (see also > section 5.3 in [1])? Kathleen advised us to include attack scenarios into the document (see http://www.ietf.org/mail-archive/web/ace/current/msg00765.html). > Section 3.2 "Configuration of Access Permissions" > - Different terms with similar meaning are used in the draft: "access > permissions"/"access control policies"/"authorization policies". A single > term consistently used would be preferable. As an alternative, [1] uses > the term "authorization information". Section 4.4 of [1] proposes a > definition and characterization of authorization info. which is more > general than just premissions/policies. Does it make sense to use this > terminology and/or characterization in the use case draft? The term policy usually has a different meaning than the term authorization information. In my understanding, the latter refers to a collection of information that is used for authorization and contains e.g. the access permissions. The term "policy" is defined as "A plan or course of action that is stated for a system or organization and is intended to affect and direct the decisions and deeds of that entity's components or members." by RFC4949. A permission is usually one part of an authorization policy. It can e.g. consist of an object and an action that can be performed on that object. Therefore, I don't think we benefit from replacing the terms in the document with "authorization information" as you suggest. > - Section 3.2 also overlaps with 4.5 of [1], the latter is considering a > more general problem "access to authorization information". (More general > since authz. info is more general than access policies and "access" is a > priori more general than "configuration"/"provisioning to the device".) > Does it make sense to include this more general problem and the properties > listed in section 4.5 of [1] in the use case draft? > > - Section 4.5 of [1] also go into how to secure access to authorization > information. Do you think this content also makes sense in the security > considerations of the use case draft? Section 3.2 and 3.3 are derived from the problem descriptions of the use cases. If you miss a specific topic, maybe there is something missing in the use cases? Some of the topics mentioned in section 4.5 discuss solutions, e.g. "Authorization information may a priori be transferred directly between AS and RS, or via C; using Agent, Push or Pull mechanisms". I don't think this belongs into the use cases document. > Section 4 > - Not only authorization of resource access, but also authorization of > access to resource information should be considered for privacy reasons > (compare section 4.3 of [1].) > > > > General > - The use case draft contains fragments of an authorization architecture > (mainly terminology in section 1.1 such as C, RS, RO). Would it make sense > to extend this and include a basic split "authorization decision / > authorization enforcement" setup? Section 2 of [1] motivates why this > setup is particular relevant for the constrained device setting, and > section 4.3 of [1] maps this functionality to the architecture. This again is more about possible solutions and architecture. This is not in scope for the use cases draft. > - [1] also contains assumptions on keys and ciphersuites (section 4.7), > constrained network considerations (section 4.9) and legacy considerations > (section 4.10). Do you think any of this makes sense in the use case draft? > > - Sections 2.x.x. entitled "Authorization Problems Summary" > I think most of the authorization problems make more sense with "device > owner" replaced with "resource owner". Referring to Steffi's mail reply to > Hannes (Subject: [ACE] Container Use Case) I think it is confusing to try > to address server and client problems with one problem statement about > "device owner". I would like to separate those so it is clear to whether > the problem relates to server or client. Do you agree? > We introduced the term "principal" in the new version of the draft to address this problem. Best regards, Steffi From nobody Tue Jan 13 09:39:59 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F521A6FF7 for ; Tue, 13 Jan 2015 09:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3LtNUCPrVix for ; Tue, 13 Jan 2015 09:39:55 -0800 (PST) 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 D05261A8FD7 for ; Tue, 13 Jan 2015 09:39:54 -0800 (PST) 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 t0DHdqZe022719 for ; Tue, 13 Jan 2015 18:39:52 +0100 (CET) Received: from alma.local (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (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 3kMJvW5TH6z846g; Tue, 13 Jan 2015 18:39:51 +0100 (CET) Message-ID: <54B55867.4020907@tzi.org> Date: Tue, 13 Jan 2015 18:39:51 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: ace@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] DCAF implementation size numbers X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 13 Jan 2015 17:39:57 -0000 Thanks to Eve Maler for the interesting Webinar we had today. It is refreshing to see that the separation between requesting party and resource owner comes up in the OAuth environment as well. I'm looking forward to a decaffeinated OAuth -- we should just make sure we bridge the gap and don't fill it in... I promised to provide some DCAF numbers. >From http://dx.doi.org/10.1109/ICNP.2014.104 (slides at http://netsec.cs.uoregon.edu/npsec2014/slides/dcaf_npsec2014.pdf -- see slide 24): > A prototypical implementation for an ARM Cortex M3 (CC2538) shows that > DCAF adds about 440 Bytes of code and 54 Bytes of data plus storage > for the Ticket Face to an existing CoAP server with DTLS support. (No, these are not kilobytes :-) This assumes having a DTLS PSK implementation and the associated crypto (AES encryption, SHA-256) already present. It also assumes a CBOR implementation (which is needed for the actual data anyway). Even though this was measured on a device "that ARM would like to sell you" (was that Justin?), this should work quite well with other devices in the RFC 7228 "Class 1" cluster". Grüße, Carsten From nobody Wed Jan 14 02:20:32 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 948961B2C3A for ; Wed, 14 Jan 2015 02:20:30 -0800 (PST) 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 Swc1ATGDWMWp for ; Wed, 14 Jan 2015 02:20:27 -0800 (PST) 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 2D2621ACE52 for ; Wed, 14 Jan 2015 02:20:27 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-0d-54b642e9e932 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.4B.04484.9E246B45; Wed, 14 Jan 2015 11:20:25 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.38]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 11:20:24 +0100 From: =?windows-1254?Q?G=F6ran_Selander?= To: "gerdes@tzi.de" , Hannes Tschofenig Thread-Topic: Terminology and basic assumptions (Was: Re: [Ace] Container Use Case) Thread-Index: AQHQL+O1yqd4RxE4eEKwFVIWdrGzmQ== Date: Wed, 14 Jan 2015 10:20:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="windows-1254" Content-ID: <829B5100561E9F4882B837BF758F659D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rvel07YQgw3TxS2+f+thtth48S6j xdKd91gdmD0Wb9rP5rFkyU8mj21vvzIHMEdx2aSk5mSWpRbp2yVwZcz/qV7w3bZi6fvIBsb5 Rl2MHBwSAiYSP38FdzFyApliEhfurWcDsYUEjjBKrLuT38XIBWQvZpRYfHIeE0iCTcBdYs7e lSwgtohAiMSzuStZQWxmAUWJ3bPOsoPYwgIBEvcvtTBD1IRKPDrWC2XrSdw5vh9sAYuAqsTv 68/A6nkFLCT2HXrGCGIzAh3x/dQaJoiZ4hK3nsxngjhOQGLJnvPMELaoxMvH/8D2igLNXHm9 iQ0irihxdfpyqF4DiSPnbkLdZi1xeVMDG4StLbFs4WtmiL2CEidnPmGZwCg2C8m6WUjaZyFp n4WkfRaS9gWMrKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAqPs4JbfBjsYXz53PMQowMGo xMO74fbWECHWxLLiytxDjNIcLErivHkOG0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNaZ f7t3OvtI4w+DNHl19S36dxabb1j/dOfiatMrLjJzJt5JMTbOOH658ZbmS+NL/Hucc6/9rTl9 ioPBsG2rkIbY8fWrV9nGdjx41GvfJNs7z1SLR853h8tS00+bGPjzJu5g6a2ctP2c4vsmk5W9 Z+Ic3SNqrgZtuuvezHHn3uWVvKpOzXpHqpVYijMSDbWYi4oTAd+07SOTAgAA Archived-At: Cc: "Ace@ietf.org" Subject: [Ace] Terminology and basic assumptions (Was: Re: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jan 2015 10:20:30 -0000 Hi Steffi, Hannes I note that there is a difference in opinion here whether we should try to introduce the basic terms, concepts and assumptions in the use case draft or not. Pending the resolution of that I wait with responding to this mail and instead provide more specific comments of the new version of the use case draft (next mails). Regards, G=F6ran On 2015-01-13 15:37, "Stefanie Gerdes" wrote: >Hi G=F6ran, > >On 01/10/2015 12:51 PM, G=F6ran Selander wrote: >> Hi Steffi and Ludwig, >> >> (Also a question for WG chairs / AD a few paragraphs below) >> >> >> >> I=B9ve read through the ACE use case draft with fresh eyes and have some >> comments. Since I know the draft is in transition I will not go into >> detail in this mail. Could you please let me know if you plan to address >> the comments below or not in the next version? >> >> The main overall comment is that there is a great deal of overlapping >> material between section 3 of the use case draft and section 4 of >> draft-seitz-ace-problem-description: >> >> [1] >>=20 >>http://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section >>-4 >> >> Recall that section 4 of [1] is to a large extent the result of a >> discussion at the (informal) ACE meeting in Stockholm in June 2014. >> Obviously we didn't agree on everything at the meeting, as is also >> indicated in the draft, but some terms and assumptions were agreed and I >> think it would save us time to re-use some of this either in the use >>case >> draft or in a separate [architecture?] draft. >> >> WG chairs/AD/anyone: Do you have an opinion about whether (a) there >>should >> be a separate [architecture?] draft describing additional terminology >>and >> assumptions of the solution space, or (b) if this should be fitted into >> the security considerations of the use case draft, or (c) each solution >> proposal should make its own assumptions and terminology? The charter >> does not include an architecture document which I guess speaks in favor >>of >> (b) and (c). > >There already was some discussion about this during the last ACE session >in Honolulu. I really don't like the idea to mix up use cases, >architecture and solutions. The terminology in the use cases draft >should only contain the terminology actually used in there. Additional >terminology will likely be solution specific. Since we don't know yet >which solution fits best it will be more useful to leave this discussion >for later. We will gain more from the use cases document if we focus on >its main purpose: summarizing the main problems in representative use >cases. > >If it is obvious that there are documents missing in the milestones that >would be useful for the work in ACE, it might be better to add them >instead of trying to press topics into a document where they don't >really fit and will blur the focus. > >> Here are the comments: >> >> Section 3.1 "Attacks" >> - The last part of the section describes properties of constrained >>devices >> that may need to be considered also for performance reasons, not just >> attack mitigation. How about renaming the section "Constrained device >> aspects" or "Constrained devices" or similar? >> >> - Section 4.2 of [1] contains a list of partly overlapping features of >> constrained devices. Does it makes sense to include in the use case >>draft >> other features of section 4.2 in [1] which are not currently in? For >> example that some constrained devices may be unable to manage complex >> authorization policies or unable to precisely measure time (see also >> section 5.3 in [1])? > >Kathleen advised us to include attack scenarios into the document (see >http://www.ietf.org/mail-archive/web/ace/current/msg00765.html). > >> Section 3.2 "Configuration of Access Permissions" >> - Different terms with similar meaning are used in the draft: "access >> permissions"/"access control policies"/"authorization policies". A >>single >> term consistently used would be preferable. As an alternative, [1] uses >> the term "authorization information". Section 4.4 of [1] proposes a >> definition and characterization of authorization info. which is more >> general than just premissions/policies. Does it make sense to use this >> terminology and/or characterization in the use case draft? > >The term policy usually has a different meaning than the term >authorization information. In my understanding, the latter refers to a >collection of information that is used for authorization and contains >e.g. the access permissions. The term "policy" is defined as "A plan or >course of action that is stated for a system or organization and is >intended to affect and direct the decisions and deeds of that entity's >components or members." by RFC4949. A permission is usually one part of >an authorization policy. It can e.g. consist of an object and an action >that can be performed on that object. > >Therefore, I don't think we benefit from replacing the terms in the >document with "authorization information" as you suggest. > >> - Section 3.2 also overlaps with 4.5 of [1], the latter is considering a >> more general problem "access to authorization information". (More >>general >> since authz. info is more general than access policies and "access" is a >> priori more general than "configuration"/"provisioning to the device".) >> Does it make sense to include this more general problem and the >>properties >> listed in section 4.5 of [1] in the use case draft? >> >> - Section 4.5 of [1] also go into how to secure access to authorization >> information. Do you think this content also makes sense in the security >> considerations of the use case draft? > >Section 3.2 and 3.3 are derived from the problem descriptions of the use >cases. If you miss a specific topic, maybe there is something missing in >the use cases? > >Some of the topics mentioned in section 4.5 discuss solutions, e.g. >"Authorization information may a priori be transferred directly between >AS and RS, or via C; using Agent, Push or Pull mechanisms". I don't >think this belongs into the use cases document. > > >> Section 4 >> - Not only authorization of resource access, but also authorization of >> access to resource information should be considered for privacy reasons >> (compare section 4.3 of [1].) >> >> >> >> General >> - The use case draft contains fragments of an authorization architecture >> (mainly terminology in section 1.1 such as C, RS, RO). Would it make >>sense >> to extend this and include a basic split "authorization decision / >> authorization enforcement" setup? Section 2 of [1] motivates why this >> setup is particular relevant for the constrained device setting, and >> section 4.3 of [1] maps this functionality to the architecture. > >This again is more about possible solutions and architecture. This is >not in scope for the use cases draft. > >> - [1] also contains assumptions on keys and ciphersuites (section 4.7), >> constrained network considerations (section 4.9) and legacy >>considerations >> (section 4.10). Do you think any of this makes sense in the use case >>draft? >> >> - Sections 2.x.x. entitled "Authorization Problems Summary" >> I think most of the authorization problems make more sense with "device >> owner" replaced with "resource owner". Referring to Steffi's mail reply >>to >> Hannes (Subject: [ACE] Container Use Case) I think it is confusing to >>try >> to address server and client problems with one problem statement about >> "device owner". I would like to separate those so it is clear to whether >> the problem relates to server or client. Do you agree? >> > >We introduced the term "principal" in the new version of the draft to >address this problem. > >Best regards, >Steffi From nobody Wed Jan 14 02:25:47 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767241B2C41 for ; Wed, 14 Jan 2015 02:25:45 -0800 (PST) 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 L0esa7xdMNyU for ; Wed, 14 Jan 2015 02:25:43 -0800 (PST) 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 75E601B2C34 for ; Wed, 14 Jan 2015 02:25:42 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-f0-54b644243792 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.E0.04231.42446B45; Wed, 14 Jan 2015 11:25:40 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.38]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 11:25:40 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "gerdes@tzi.de" Thread-Topic: Role terminology in use case draft (Was: [Ace] Container Use Case) Thread-Index: AQHQL+RxnxnwVHnuJU+Yvlqb3+45rg== Date: Wed, 14 Jan 2015 10:25:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6F851F8A4395284C9EC59FC2848126CA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja6Ky7YQg7X/9S2+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJUxffoGxoLJmhWvGmawNzB+U+hi5OCQEDCR mH27pouRE8gUk7hwbz0biC0kcIRRYuX0ui5GLiB7MaPE/lMfwBJsAq4SBx68YwKxRQSUJdr+ fGYEsZkFFCV2zzrLDmILC3hLTN77iw2iJkhi/+xWdghbT2LRz79gNouAqsSx53vBenkFLCQ+ /7sCNpMR6Ijvp9YwQcwUl7j1ZD4TxHECEkv2nGeGsEUlXj7+xwpiiwLNXHm9iQ0irijx8dU+ qHv0JG5MncIGYVtLHFnyAiquLbFs4WtmiL2CEidnPmGZwCg2C8m6WUjaZyFpn4WkfRaS9gWM rKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAqPq4JbfujsYV792PMQowMGoxMO74fbWECHW xLLiytxDjNIcLErivHkOG0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNpfMJvBLZjqXptY 6bZHKGhtKvdrT0eGWULBppVNb9oMKoWv+nA6vX7rYBT4eKrnNO2IWyalTrOds2pvXDDKL7P5 9cuVZ2J92zWGf9dPSiheV9BJdn6l4N94pXbhnq6ay5PNT2x6ejLtfMjvT9zfGo3NN7CpmfpY p1zqkD2Q+SFO0yv+2+f7SizFGYmGWsxFxYkAR/c7yosCAAA= Archived-At: Cc: "Ace@ietf.org" Subject: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jan 2015 10:25:45 -0000 Hi Steffi, I continue the discussion of the authorization problem formulations in this thread: On 2015-01-13 15:37, "Stefanie Gerdes" wrote: >> >> - Sections 2.x.x. entitled "Authorization Problems Summary" >> I think most of the authorization problems make more sense with "device >> owner" replaced with "resource owner". Referring to Steffi's mail reply >>to >> Hannes (Subject: [ACE] Container Use Case) I think it is confusing to >>try >> to address server and client problems with one problem statement about >> "device owner". I would like to separate those so it is clear to whether >> the problem relates to server or client. Do you agree? >> > >We introduced the term "principal" in the new version of the draft to >address this problem. >From the new version of the draft: "Resource Owner: The subject who owns the resource and controls its access permissions. Device Owner: The subject who owns a certain device and controls its access permissions. Principal: A subject who is either a resource owner or a device owner or both." - I don=B9t see how the term =B3principal" is separating problems relating = to client from those relating to servers. Or do I misunderstand what you mean by =B3address this problem=B2? - Further, what is the relationship between device access permissions and resource access permissions? Is it so that access a resource on a device you need both device access permissions and resource access permissions? Would that mean that you may not be able to access the resource despite having been granted access by the resource owner because of not having the device authorization? And vice versa?=20 Some specific comments: o U1.1 Principals such as the fruit vendor, the transloading personnel or the container owners want to grant different access rights for their resource to different parties and want to control which devices are allowed to present data to their devices. - Is fruit vendor =B3resource owner=B2 or =B3device owner=B2 or both? The s= ame question for transloading personnel and container owner. =B3control which devices are allowed to present data to their devices" - What does this correspond to in the use case? o U1.2 Principals want to grant different access rights for different resources on a device. - Same question as above about what if device owner and resource owner set incompatible access policies? o U1.3 The principals require the integrity of sensor data. - I understand that, for example, a client requires integrity of sensor data, but I don=B9t understand why this would be a requirement of a =B3devi= ce owner=B2 o U1.4 The principals require the confidentiality of sensor data. - I understand that the resource owner requires confidentiality of sensor data, but I don=B9t understand why this would be a requirement of a =B3devi= ce owner=B2 o U3.1 A principal, such as the owner of a health monitoring device, wants to pre-configure access rights to specific data for persons or groups, in the context of an emergency. - The owner of a health monitoring device may be a patient, a caregiver organization or outsourced to a trusted third party. Independently of who owns the device, the resource owner should be able to set the access rights. So I think principal should be replaced by resource owner. o U3.2 A principal wants to selectively allow different persons or groups to access medical data. - As above, principal should be replaced with resource owner. o U5.1 Devices are installed in hostile environments where they are physically accessible by attackers. Principals want to make sure that an attacker cannot use a captured device to attack other parts of their infrastructure. - I see this primarily as a concern of the owner of the infrastructure, not a concern of a resource owner. Of course, if the infrastructure is attacked the resource owner may be inflicted, but preventing this kind of attack is nothing an entity in the role of resource owner can =B3make sure= =B2. So I propose to replace the term principal. o U5.2 Principals want to restrict which entities are allowed to write data to the devices and thus ensure the integrity of the data on their devices. - I agree that access control to and integrity protection of utility data is a relevant problem statement can be deduced from this use case, but I find this formulation somewhat confusing. In the case =B3principal=B2 means =B3resource owner", the formulation =B3write data to the devices=B2 or =B3integrity of the data on their devices=B2 does not make sense; the resou= rce owner does not necessarily own any devices and =B3data on devices" would better be formulated in terms of "resource representations=B2 or similar. o U5.7 Messages between a client and the device may need to be stored and forwarded over multiple nodes. =09 =09 - I think =B3device=B2 should be replaced by =B3resource server=B2. The dif= ference between "device" and =B3node=B2 is not clear. Analogous comments apply to other problem statements, let me get back with more details later. Regards, G=F6ran From nobody Wed Jan 14 02:55:22 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 163F61ACE50 for ; Wed, 14 Jan 2015 02:55:21 -0800 (PST) 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 n7bgTzLn8usn for ; Wed, 14 Jan 2015 02:55:19 -0800 (PST) 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 4C0891ACDF4 for ; Wed, 14 Jan 2015 02:55:19 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-21-54b64b1599af Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1A.88.04231.51B46B45; Wed, 14 Jan 2015 11:55:17 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.38]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 11:55:16 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Stefanie Gerdes Thread-Topic: Security considerations of the use case draft Thread-Index: AQHQL+iUadeGpGauRE+4gC/qoxvPNA== Date: Wed, 14 Jan 2015 10:55:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7CE62B07BFDF264489C187735C0633F9@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja6o97YQgyvPNS2+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJXxeOsdxoI/vBUvDws3MK7n7mLk5JAQMJG4 cm0aO4QtJnHh3nq2LkYuDiGBI4wShx/OYoVwFjNK7FvyixWkik3AVeLAg3dMILaIgLLE78Wf wGxmAUWJ3bPOgk0SFjCXuLR1DmMXIwdQjY3Eu54CiHI9idVn77GB2CwCqhINH9tYQUp4BSwk /vTEgIQZgW74fmoN1ERxiVtP5jNB3CYgsWTPeWYIW1Ti5eN/YNeIAo1ceb2JDSKuKLHzbDsz RK+exI2pU9ggbGuJm3/PQNnaEssWvgar4RUQlDg58wnLBEaxWUjWzULSPgtJ+ywk7bOQtC9g ZF3FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhTB7f81t3BuPq14yFGAQ5GJR7eDbe3hgix JpYVV+YeYpTmYFES581z2BAiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHQuFu7JjhNosJi 38tZUY8jP0oqaH7+onPkzrOX/ndt70xhq13PWlXrcFOnU+Yxt5jSq9KpS5/0LVL2UPSdyWaf 6MMWKnXm9r9u/bMt2nquYVvsHph3vOt4fOxIGmOxw7I7kz5FtWtVdv2r5rruviGBYzef03V9 x1Pe/V7/uXv9YhMUrRdsUWIpzkg01GIuKk4EABbhUnuKAgAA Archived-At: Cc: "Ace@ietf.org" Subject: [Ace] Security considerations of the 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: Wed, 14 Jan 2015 10:55:21 -0000 Hi Steffi, Some further comments on section 3. Section 3.2 "Configuration of Access Permissions" "The access control policies set by the Principals need to be provisioned to the device that enforces the authorization and applied to every incoming request." - These statements presuppose a specific solution - the provisioning of access control policies. An alternative solution is that an authorization decision is provisioned. Yet another solution is that client capabilities are provisioned. Another solution is that neither of this information is =B3configured/provisioned", but instead there is a request for an authorization decision. - "enforces the authorization" implies "applied to every incoming request= =B2 so the latter is redundant. "The device that makes the policy decisions should be able to evaluate context-based permissions such as location or time of access" "The device that makes the policy decisions should be able to take such conditions into account." - I agree that the resource server should be able to evaluate context-based conditions but these statements are problematic. Assuming the policy decision is separate in time and place from policy enforcement and that the result of a decision is an access token contains the information =B3access granted during office hours". In this case, the time and location of the access may not be known to the device that makes the policy decision.=20 Section 3.3 "It should be possible to update access control policies without manually re-provisioning individual devices" - This statement presupposes a particular solution, see above. (The statement may actually be trivially true with solutions that does not provision at all.) Regards G=F6ran From nobody Wed Jan 14 03:09:17 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 28E711B2C54 for ; Wed, 14 Jan 2015 03:08:57 -0800 (PST) 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 z2pUwjy-zfSa for ; Wed, 14 Jan 2015 03:08:52 -0800 (PST) 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 B5E4E1B2C4B for ; Wed, 14 Jan 2015 03:08:51 -0800 (PST) Received: from [192.168.131.147] ([80.92.123.55]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LiDrv-1XOrrO066d-00nQzT for ; Wed, 14 Jan 2015 12:08:49 +0100 Message-ID: <54B64E40.4040208@gmx.net> Date: Wed, 14 Jan 2015 12:08:48 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lacIdUDQS8xLcOwmEhNp0vVr9XMi9ljtp" X-Provags-ID: V03:K0:oOzwXx5r6OhgHX/Z+bST2JnMOlQduyWYzk+GnDrM9jM6GiZJWRl pxJEQNHfuuekVTulQw9lnQJsDKsMUrtNryhJDKzaLCdtTRqOiHuTFJmoz3q/Fb6aeNg3JEa mFP0Xtgc+tNaZ+tEFNEvgvRoNW/FriKzSF0SELwi6UIvV6lDbDGpdYXu6byboj744PYzhe9 rd4/doES0YmmdlNfUpJ5A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Slides and Recording from UMA Talk X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jan 2015 11:08:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lacIdUDQS8xLcOwmEhNp0vVr9XMi9ljtp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, here are the slides and the recording from the talk yesterday. Direct links: * Slides -- http://tschofenig.priv.at/tutorials/UMA-for-ACE.pdf * Recording in the Webex native format (ARF) -- http://tschofenig.priv.at/tutorials/UMA-for-ACE.arf * Recording converted to MP4 -- http://tschofenig.priv.at/tutorials/UMA-for-ACE.mp4 Links via the announcement: http://www.tschofenig.priv.at/wp/?p=3D1057 Thank you Eve for the presentation and the audience for showing up. Ciao Hannes --lacIdUDQS8xLcOwmEhNp0vVr9XMi9ljtp 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 iQEcBAEBCgAGBQJUtk5AAAoJEGhJURNOOiAtHfAH/1urGsku/ADnfw+Un18L3546 UdV+T5isqZr9rNazW3ShCnYMkam9rWFu9hFbBGzCYRHoaYgPNNGw6McOv9z6phqx QO9DNuAY2Pq0F1vxjYjKBbLzWr5PptXtpRABDNtYTpzLBvtWosABBXDkhUzT+A6L 7Nud70DWCa1NVSQvjOsbanRGrLK66UTb8NLuXBnAyUoevZ9zM0W0DS0h+43ipy7s LucJPPIXMf1k666fwk9stqC/mhGMW76nkCOhNSTzXe/yBUxOe/AqgeNVD8COH9VT hcfbsHUSG9BWv7VaYrpNS/ec3NXR8pUZlJGWM8vFYzUWA4QqCYlhoTA9vLRPxZM= =KngY -----END PGP SIGNATURE----- --lacIdUDQS8xLcOwmEhNp0vVr9XMi9ljtp-- From nobody Wed Jan 14 06:27:13 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 836CA1B2CB7 for ; Wed, 14 Jan 2015 06:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oguKiAKm-Iu for ; Wed, 14 Jan 2015 06:26:53 -0800 (PST) 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 5BA9C1B2CC0 for ; Wed, 14 Jan 2015 06:26:53 -0800 (PST) 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 t0EEQmEn000430; Wed, 14 Jan 2015 15:26:48 +0100 (CET) Received: from [IPv6:2001:638:708:30da:4ce2:33c7:1776:d289] (unknown [IPv6:2001:638:708:30da:4ce2:33c7:1776:d289]) (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 3kMrZH6Dw1z84Sd; Wed, 14 Jan 2015 15:26:47 +0100 (CET) Message-ID: <54B67C9D.9000703@tzi.de> Date: Wed, 14 Jan 2015 15:26:37 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?G=F6ran_Selander?= References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Security considerations of the use case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 14:26:56 -0000 Hi Göran, Thank you for your comments. On 01/14/2015 11:55 AM, Göran Selander wrote: > Hi Steffi, > > > Some further comments on section 3. > > Section 3.2 > > "Configuration of Access Permissions" > > "The access control policies set by the Principals need to be provisioned > to the device that enforces the authorization and applied to every > incoming request." > > - These statements presuppose a specific solution - the provisioning of > access control policies. An alternative solution is that an authorization > decision is provisioned. Yet another solution is that client capabilities > are provisioned. Another solution is that neither of this information is > ³configured/provisioned", but instead there is a request for an > authorization decision. I think this is a misunderstanding. I think we agree that the principals are defining access control policies for their devices, right? They have some security objectives in mind that they want their devices to ensure. These policies somehow have to get to the device that enforces the authorization because this is the device that counts. And the device has to apply these policies to every request because otherwise the policies of the principal would not be ensured and the security of the system would be threatened. You are right that there are a lot of different solutions to provide the policies to the device and it is not the intent of the paragraph to suggest a specific solution. Maybe rephrasing helps: "The access control policies set by the Principals need to be provided to the device that enforces the authorization and applied to every incoming request." What do you think? > - "enforces the authorization" implies "applied to every incoming request² > so the latter is redundant. > > > "The device that makes the policy decisions should be able to evaluate > context-based permissions such as location or time of access" > > "The device that makes the policy decisions should be able to take such > conditions into account." > > - I agree that the resource server should be able to evaluate > context-based conditions but these statements are problematic. Assuming > the policy decision is separate in time and place from policy enforcement > and that the result of a decision is an access token contains the > information ³access granted during office hours". In this case, the time > and location of the access may not be known to the device that makes the > policy decision. Okay, how about: "If permissions require a certain context to apply at the time of access such as location or time, this context needs to be validated before the access is granted". > Section 3.3 > > "It should be possible to update access control policies without manually > re-provisioning individual devices" > > - This statement presupposes a particular solution, see above. (The > statement may actually be trivially true with solutions that does not > provision at all.) As far as I remember this aims at the problem that it will often be impossible or at least very impractical to manually provision authorization information and/or keying material to the constrained devices for every change in the auhorization policies. Do you question that this is a problem or do you think that it is wrong to derive the above suggestion from the problem? Maybe it would help to rephrase it? Do you have a suggestion? Thanks, Steffi From nobody Thu Jan 15 00:15: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 7C7F11B2BAE for ; Thu, 15 Jan 2015 00:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cK1itY-6Nhd for ; Thu, 15 Jan 2015 00:15:42 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F061B2BAA for ; Thu, 15 Jan 2015 00:15:41 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-75-54b7772b8605 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 96.0B.24955.B2777B45; Thu, 15 Jan 2015 09:15:39 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.38]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 09:15:38 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "gerdes@tzi.de" Thread-Topic: Security considerations of the use case draft Thread-Index: AQHQMAYjjEfmLeQuiU+OPZH25He7ZpzA1taA Date: Thu, 15 Jan 2015 08:15:38 +0000 Message-ID: References: <54B67C9D.9000703@tzi.de> In-Reply-To: <54B67C9D.9000703@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rle7fHuIwZW/chbfv/UwW2y8eJfR gcljyZKfTB7b3n5lDmCK4rJJSc3JLEst0rdL4MroWPOQveCIdcXJv49YGxgbrLoYOTkkBEwk 7ixYzwRhi0lcuLeerYuRi0NI4AijRP+xlSwQzmJGia7lRxhBqtgEXCQeNDwC6xARUJZo+/MZ LM4soCixe9ZZdhBbWMBK4snCG1A11hJHZz5ihLCNJGZ97GIFsVkEVCV+n5oNZvMKWEjseXcL rEZIIERi7eNvQL0cHJwCahKPOmNBwoxAx30/tYYJYpW4xK0n86GOFpBYsuc8M4QtKvHy8T+w kaICehIrrzexQcQVJXaebWcGGcksoCmxfpc+xBhrif9/vsNdP6X7ITvENYISJ2c+YZnAKDEL ybZZCN2zkHTPQtI9C0n3AkbWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBMXhwy2/VHYyX 3zgeYhTgYFTi4S1I3R4ixJpYVlyZe4hRmoNFSZw3z2FDiJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGHNVJtpZLo9ZpJ2789WhesfCtRXm3b4lOu2C7sERwYlSi85Ss5EcPpYv7psX/bow5 XNR+7Jre3JAXF5Lu+jzu7I2zDOfZty/5y1G9L3e2CJe5OM/ON+6sEggXu1Nz73LhnICdHrs+ Lp541vlUn87OFbOLm/42nWure7Jnf6bhpJ/aSqFK8U0PlViKMxINtZiLihMBJBytRqICAAA= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Security considerations of the 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: Thu, 15 Jan 2015 08:15:43 -0000 SGkgU3RlZmZpLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuIENvbW1lbnRzIGlubGluZS4NCg0K T24gMjAxNS0wMS0xNCAxNToyNiwgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdy b3RlOg0KDQo+SGkgR8O2cmFuLA0KPg0KPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4NCj4N Cj5PbiAwMS8xNC8yMDE1IDExOjU1IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBIaSBT dGVmZmksDQo+Pg0KPj4NCj4+IFNvbWUgZnVydGhlciBjb21tZW50cyBvbiBzZWN0aW9uIDMuDQo+ Pg0KPj4gU2VjdGlvbiAzLjINCj4+DQo+PiAiQ29uZmlndXJhdGlvbiBvZiBBY2Nlc3MgUGVybWlz c2lvbnMiDQo+Pg0KPj4gIlRoZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBzZXQgYnkgdGhlIFBy aW5jaXBhbHMgbmVlZCB0byBiZQ0KPj5wcm92aXNpb25lZA0KPj4gdG8gdGhlIGRldmljZSB0aGF0 IGVuZm9yY2VzIHRoZSBhdXRob3JpemF0aW9uIGFuZCBhcHBsaWVkIHRvIGV2ZXJ5DQo+PiBpbmNv bWluZyByZXF1ZXN0LiINCj4+DQo+PiAtIFRoZXNlIHN0YXRlbWVudHMgcHJlc3VwcG9zZSBhIHNw ZWNpZmljIHNvbHV0aW9uIC0gdGhlIHByb3Zpc2lvbmluZyBvZg0KPj4gYWNjZXNzIGNvbnRyb2wg cG9saWNpZXMuIEFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIGlzIHRoYXQgYW4NCj4+YXV0aG9yaXph dGlvbg0KPj4gZGVjaXNpb24gaXMgcHJvdmlzaW9uZWQuIFlldCBhbm90aGVyIHNvbHV0aW9uIGlz IHRoYXQgY2xpZW50DQo+PmNhcGFiaWxpdGllcw0KPj4gYXJlIHByb3Zpc2lvbmVkLiBBbm90aGVy IHNvbHV0aW9uIGlzIHRoYXQgbmVpdGhlciBvZiB0aGlzIGluZm9ybWF0aW9uIGlzDQo+PiDCs2Nv bmZpZ3VyZWQvcHJvdmlzaW9uZWQiLCBidXQgaW5zdGVhZCB0aGVyZSBpcyBhIHJlcXVlc3QgZm9y IGFuDQo+PiBhdXRob3JpemF0aW9uIGRlY2lzaW9uLg0KPg0KPkkgdGhpbmsgdGhpcyBpcyBhIG1p c3VuZGVyc3RhbmRpbmcuIEkgdGhpbmsgd2UgYWdyZWUgdGhhdCB0aGUgcHJpbmNpcGFscw0KPmFy ZSBkZWZpbmluZyBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBmb3IgdGhlaXIgZGV2aWNlcywgcmln aHQ/DQoNClNvcnJ5IGZvciBuaXRwaWNraW5nLCBidXQgbGV04oCZcyBiZSBjYXJlZnVsIHdpdGgg dGhlIHdvcmRzOiBZb3UgbWFrZSB0aGUNCmRpc3RpbmN0aW9uIGJldHdlZW4g4oCccmVzb3VyY2Ug b3duZXLigJ0gYW5kIOKAnGRldmljZSBvd25lcuKAnSBhbmQgY2hhcmFjdGVyaXplDQpib3RoIGFz IHByaW5jaXBhbHMuIEluIHRoZSBjYXNlIG9mIHByaW5jaXBhbCA9ICJyZXNvdXJjZSBvd25lcuKA nSBJIHRoaW5rDQp0aGUgdGVybSDigJx0aGVpciBkZXZpY2Vz4oCdIGlzIG5vdCB3ZWxsIGRlZmlu ZWQuDQoNCj5UaGV5IGhhdmUgDQo+c29tZSBzZWN1cml0eSBvYmplY3RpdmVzIGluIG1pbmQgdGhh dCB0aGV5IHdhbnQgdGhlaXIgZGV2aWNlcyB0byBlbnN1cmUuDQo+VGhlc2UgcG9saWNpZXMgc29t ZWhvdyBoYXZlIHRvIGdldCB0byB0aGUgZGV2aWNlIHRoYXQgZW5mb3JjZXMgdGhlDQo+YXV0aG9y aXphdGlvbiBiZWNhdXNlIHRoaXMgaXMgdGhlIGRldmljZSB0aGF0IGNvdW50cy4gQW5kIHRoZSBk ZXZpY2UgaGFzDQo+dG8gYXBwbHkgdGhlc2UgcG9saWNpZXMgdG8gZXZlcnkgcmVxdWVzdCBiZWNh dXNlIG90aGVyd2lzZSB0aGUgcG9saWNpZXMNCj5vZiB0aGUgcHJpbmNpcGFsIHdvdWxkIG5vdCBi ZSBlbnN1cmVkIGFuZCB0aGUgc2VjdXJpdHkgb2YgdGhlIHN5c3RlbQ0KPndvdWxkIGJlIHRocmVh dGVuZWQuDQo+DQo+WW91IGFyZSByaWdodCB0aGF0IHRoZXJlIGFyZSBhIGxvdCBvZiBkaWZmZXJl bnQgc29sdXRpb25zIHRvIHByb3ZpZGUgdGhlDQo+cG9saWNpZXMgdG8gdGhlIGRldmljZSBhbmQg aXQgaXMgbm90IHRoZSBpbnRlbnQgb2YgdGhlIHBhcmFncmFwaCB0bw0KPnN1Z2dlc3QgYSBzcGVj aWZpYyBzb2x1dGlvbi4gTWF5YmUgcmVwaHJhc2luZyBoZWxwczoNCj4NCj4iVGhlIGFjY2VzcyBj b250cm9sIHBvbGljaWVzIHNldCBieSB0aGUgUHJpbmNpcGFscyBuZWVkIHRvIGJlIHByb3ZpZGVk DQo+dG8gdGhlIGRldmljZSB0aGF0IGVuZm9yY2VzIHRoZSBhdXRob3JpemF0aW9uIGFuZCBhcHBs aWVkIHRvIGV2ZXJ5DQo+aW5jb21pbmcgcmVxdWVzdC4iDQo+DQo+V2hhdCBkbyB5b3UgdGhpbms/ DQoNCldoYXQgSeKAmW0gc2F5aW5nIGlzIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IGFjY2Vz cyBjb250cm9sIHBvbGljaWVzIHRoYXQNCmFyZSDigJxwcm92aWRlZCB0byB0aGUgZGV2aWNlIiwg c28gd2Ugc2hvdWxkIHBlcmhhcHMgZm9ybXVsYXRlIGl0IGluIGENCmRpZmZlcmVudCB3YXk/IFNl ZSBiZWxvdy4NCg0KPg0KPj4gLSAiZW5mb3JjZXMgdGhlIGF1dGhvcml6YXRpb24iIGltcGxpZXMg ImFwcGxpZWQgdG8gZXZlcnkgaW5jb21pbmcNCj4+cmVxdWVzdMKyDQo+PiBzbyB0aGUgbGF0dGVy IGlzIHJlZHVuZGFudC4NCj4+DQo+Pg0KPj4gIlRoZSBkZXZpY2UgdGhhdCBtYWtlcyB0aGUgcG9s aWN5IGRlY2lzaW9ucyBzaG91bGQgYmUgYWJsZSB0byBldmFsdWF0ZQ0KPj4gY29udGV4dC1iYXNl ZCBwZXJtaXNzaW9ucyBzdWNoIGFzIGxvY2F0aW9uIG9yIHRpbWUgb2YgYWNjZXNzIg0KPj4NCj4+ ICJUaGUgZGV2aWNlIHRoYXQgbWFrZXMgdGhlIHBvbGljeSBkZWNpc2lvbnMgc2hvdWxkIGJlIGFi bGUgdG8gdGFrZSBzdWNoDQo+PiBjb25kaXRpb25zIGludG8gYWNjb3VudC4iDQo+Pg0KPj4gLSBJ IGFncmVlIHRoYXQgdGhlIHJlc291cmNlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBldmFsdWF0 ZQ0KPj4gY29udGV4dC1iYXNlZCBjb25kaXRpb25zIGJ1dCB0aGVzZSBzdGF0ZW1lbnRzIGFyZSBw cm9ibGVtYXRpYy4gQXNzdW1pbmcNCj4+IHRoZSBwb2xpY3kgZGVjaXNpb24gaXMgc2VwYXJhdGUg aW4gdGltZSBhbmQgcGxhY2UgZnJvbSBwb2xpY3kNCj4+ZW5mb3JjZW1lbnQNCj4+IGFuZCB0aGF0 IHRoZSByZXN1bHQgb2YgYSBkZWNpc2lvbiBpcyBhbiBhY2Nlc3MgdG9rZW4gY29udGFpbnMgdGhl DQo+PiBpbmZvcm1hdGlvbiDCs2FjY2VzcyBncmFudGVkIGR1cmluZyBvZmZpY2UgaG91cnMiLiBJ biB0aGlzIGNhc2UsIHRoZSB0aW1lDQo+PiBhbmQgbG9jYXRpb24gb2YgdGhlIGFjY2VzcyBtYXkg bm90IGJlIGtub3duIHRvIHRoZSBkZXZpY2UgdGhhdCBtYWtlcyB0aGUNCj4+IHBvbGljeSBkZWNp c2lvbi4NCj4NCj5Pa2F5LCBob3cgYWJvdXQ6ICJJZiBwZXJtaXNzaW9ucyByZXF1aXJlIGEgY2Vy dGFpbiBjb250ZXh0IHRvIGFwcGx5IGF0DQo+dGhlIHRpbWUgb2YgYWNjZXNzIHN1Y2ggYXMgbG9j YXRpb24gb3IgdGltZSwgdGhpcyBjb250ZXh0IG5lZWRzIHRvIGJlDQo+dmFsaWRhdGVkIGJlZm9y ZSB0aGUgYWNjZXNzIGlzIGdyYW50ZWQiLg0KPg0KPj4gU2VjdGlvbiAzLjMNCj4+DQo+PiAiSXQg c2hvdWxkIGJlIHBvc3NpYmxlIHRvIHVwZGF0ZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyB3aXRo b3V0DQo+Pm1hbnVhbGx5DQo+PiByZS1wcm92aXNpb25pbmcgaW5kaXZpZHVhbCBkZXZpY2VzIg0K Pj4NCj4+IC0gVGhpcyBzdGF0ZW1lbnQgcHJlc3VwcG9zZXMgYSBwYXJ0aWN1bGFyIHNvbHV0aW9u LCBzZWUgYWJvdmUuIChUaGUNCj4+IHN0YXRlbWVudCBtYXkgYWN0dWFsbHkgYmUgdHJpdmlhbGx5 IHRydWUgd2l0aCBzb2x1dGlvbnMgdGhhdCBkb2VzIG5vdA0KPj4gcHJvdmlzaW9uIGF0IGFsbC4p DQo+DQo+QXMgZmFyIGFzIEkgcmVtZW1iZXIgdGhpcyBhaW1zIGF0IHRoZSBwcm9ibGVtIHRoYXQg aXQgd2lsbCBvZnRlbiBiZQ0KPmltcG9zc2libGUgb3IgYXQgbGVhc3QgdmVyeSBpbXByYWN0aWNh bCB0byBtYW51YWxseSBwcm92aXNpb24NCj5hdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGFuZC9v ciBrZXlpbmcgbWF0ZXJpYWwgdG8gdGhlIGNvbnN0cmFpbmVkDQo+ZGV2aWNlcyBmb3IgZXZlcnkg Y2hhbmdlIGluIHRoZSBhdWhvcml6YXRpb24gcG9saWNpZXMuIERvIHlvdSBxdWVzdGlvbg0KPnRo YXQgdGhpcyBpcyBhIHByb2JsZW0gb3IgZG8geW91IHRoaW5rIHRoYXQgaXQgaXMgd3JvbmcgdG8g ZGVyaXZlIHRoZQ0KPmFib3ZlIHN1Z2dlc3Rpb24gZnJvbSB0aGUgcHJvYmxlbT8gTWF5YmUgaXQg d291bGQgaGVscCB0byByZXBocmFzZSBpdD8NCj5EbyB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24/DQoN CkFzIGEgbWF0dGVyIG9mIGZhY3QgSSBkbzogVXNlIHRoZSB0ZXJtaW5vbG9neSBhbmQgZm9ybXVs YXRpb25zIG9mIHNlY3Rpb24NCjQgb2YgZHJhZnQtc2VpdHotYWNlLXByb2JsZW0tZGVzY3JpcHRp b24uIFRoZSBwdXJwb3NlIG9mIHRoaXMgdGV4dCB3YXMgdG8NCmNvbWUgdXAgd2l0aCBhIGZvcm11 bGF0aW9uIG9mIHRoZSBwcm9ibGVtIHdoaWNoIGlzIGludGVuZGVkIHRvIGJlDQpzb2x1dGlvbi1p bmRlcGVuZGVudC4gSXQgaXMgYnkgbm8gbWVhbnMgcGVyZmVjdCBhbmQgaXQgbWF5IGxhY2sgc29t ZQ0KYXNwZWN0cyByZWxhdGVkIHRvIHJlY2VudCBjaGFuZ2VzIG9mIHRoZSB1c2UgY2FzZXMsIGJ1 dCBJIGhhdmVu4oCZdCBoZWFyZA0KYW55IHNlcmlvdXMgaXNzdWVzIChhcGFydCBmcm9tIHRoZSBs aXN0ZWQgb3BlbiBpc3N1ZXMpLiBUaGlzIG1heSBvZiBjb3Vyc2UNCmJlIGR1ZSB0byBubyBvbmUg aGFzIHJlYWQgaXQsIGFuZCB0aGVuIEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgdGltZSB0byBkbw0K c28gOikNCg0KVGhlIHBvaW50IEkgd2FzIHRyeWluZyB0byBtYWtlIHdpdGggdGhlIHByZXZpb3Vz IG1haWwgdGhyZWFkIHdhcyB0aGF0IGluDQpvcmRlciB0byBoYXZlIGFuIGludGVyZXN0aW5nIGRp c2N1c3Npb24gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQpzZWN0aW9uIHdlIG5lZWQg c29tZSBiYXNpYyB0ZXJtaW5vbG9neSBhbmQgYXNzdW1wdGlvbnMsIGxpa2UgdGhlcmUgaXMgaW4N CnRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIHVzZSBjYXNlIGRyYWZ0IGJ1dCBsZXNzIGxpbWl0 ZWQgdG8gc3BlY2lmaWMNCnNvbHV0aW9ucy4gVGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSBpbXBs eSB0aGF0IHdlIHNob3VsZCBicmluZyBpbiBhDQpkZXRhaWxlZCBhcmNoaXRlY3R1cmUgb3IgcHJl c2VudCBkaWZmZXJlbnQgb3B0aW9ucyBvZiB0aGUgYXJjaGl0ZWN0dXJlIGluDQp0aGUgdXNlIGNh c2UgZG9jdW1lbnQuIEFuIGFsdGVybmF0aXZlIGlzIHRvIG1vdmUgc29tZSBvZiB0aGlzIGNvbnRl bnQgZnJvbQ0KdGhlIHVzZSBjYXNlIGRvY3VtZW50IGludG8gYSBzZXBhcmF0ZSBkb2N1bWVudCwg YnV0IGFzIGZhciBhcyBJIHVuZGVyc3RhbmQNCml0IGlzIG5vdCB0aGUgaW50ZW50aW9uIHRvIGhh dmUgYWRkaXRpb25hbCBXRyBkb2N1bWVudHMuDQoNCkFuZCBJIGFncmVlIHdpdGggeW91ciBhbWJp dGlvbiBpbiB0aGlzIG1haWw6IEkgZG8gdGhpbmsgd2UgaGF2ZSBhIGNvbW1vbg0KdW5kZXJzdGFu ZGluZyBvZiBtb3N0IHRoaW5ncy4gSXQgaXMgImp1c3QiIGEgbWF0dGVyIG9mIGZvcm11bGF0aW5n IHRoZW0uDQpBbGxvdyBtZSB0byBjb21lIGJhY2sgd2l0aCBhIHByb3Bvc2FsIHNvb24gd2hlbiBJ IGhhdmUgbW9yZSB0aW1lLg0KDQpSZWdhcmRzDQpHw7ZyYW4NCg0K From nobody Thu Jan 15 08:19: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 751991B2D4D for ; Thu, 15 Jan 2015 08:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rh3BfOq3FxS for ; Thu, 15 Jan 2015 08:19:22 -0800 (PST) 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 8D55D1B2D2E for ; Thu, 15 Jan 2015 08:19:21 -0800 (PST) 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 t0FGJGsk003308; Thu, 15 Jan 2015 17:19:16 +0100 (CET) Received: from [IPv6:2001:638:708:30da:adfe:8008:671d:3cf8] (unknown [IPv6:2001:638:708:30da:adfe:8008:671d:3cf8]) (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 3kNW1b2JJJz833T; Thu, 15 Jan 2015 17:19:15 +0100 (CET) Message-ID: <54B7E75F.20808@tzi.de> Date: Thu, 15 Jan 2015 17:14:23 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?G=F6ran_Selander?= References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 16:19:24 -0000 Hi Göran, On 01/14/2015 11:25 AM, Göran Selander wrote: > Hi Steffi, > > I continue the discussion of the authorization problem formulations in > this thread: > > On 2015-01-13 15:37, "Stefanie Gerdes" wrote: > >>> - Sections 2.x.x. entitled "Authorization Problems Summary" >>> I think most of the authorization problems make more sense with "device >>> owner" replaced with "resource owner". Referring to Steffi's mail reply >>> to >>> Hannes (Subject: [ACE] Container Use Case) I think it is confusing to >>> try >>> to address server and client problems with one problem statement about >>> "device owner". I would like to separate those so it is clear to whether >>> the problem relates to server or client. Do you agree? >>> >> We introduced the term "principal" in the new version of the draft to >> address this problem. > >From the new version of the draft: > > "Resource Owner: The subject who owns the resource and controls its access > permissions. > > Device Owner: The subject who owns a certain device and controls its > access permissions. > > Principal: A subject who is either a resource owner or a device owner or > both." > > - I don¹t see how the term ³principal" is separating problems relating to > client from those relating to servers. Or do I misunderstand what you mean > by ³address this problem²? Maybe I misunderstood your problem. In the use cases draft we discuss authorization problems for a setting where one or more constrained devices communicate with each other. CoAP is the assumed to be the protocol to be used. RFC7252 [1] introduces the terms "server" and "client" for these devices, where the server is the "destination endpoint of a message" and the client is the "originating endpoint of a request". Authorization solutions propose other "roles" (I prefer to call them "actors" since the term "role" is a bit ambiguous in authorization because of RBAC) and functions. The use cases described in the draft should be independent of specific solutions and just describe problems in this area. That allows us to look at them with an open mind. Therefore it is difficult to apply the terminology of a specific solution to the use cases. Moreover, the use cases currently don't indicate that there are strong reasons to apply even the terms that are defined in CoAP to the participating entities. I understand that it would be useful for the development of an authorization solution if we could define that but I don't think it is a good idea to pick one arbitrarily. If there really are reasons for that, we should point them out. Another aspect of the terminology discussion is the distinction between the different types of "owners". During the ACE session in Honolulu, there was a discussion about the usage of the term Resource Owner in the actors draft [2]. What I took away from that discussion is that resource owners and device owners might differ and have different security objectives. Moreover, it might not even be correct to talk about owners at all. I don't see that there are good reasons to distinguish in the use cases if an issue is a resource owner or device owner problem. If there are good reasons to use one or the other in a use case, we should point this out in the document. The term "principal" was introduced in the document as a more general term for cases where it is not possible to determine whether someone is a device or a resource owner. > - Further, what is the relationship between device access permissions and > resource access permissions? > > Is it so that access a resource on a device you need both device access > permissions and resource access permissions? Would that mean that you may > not be able to access the resource despite having been granted access by > the resource owner because of not having the device authorization? And > vice versa? I don't know if there are good reasons to have device access permissions and resource access permissions for the same device. If there are use cases where this is necessary, it would be useful to point them out. You seem to assume that owners always want to authorize access to a resource, but that is not necessarily true. There are two parties communicating with each other, the client and the server. Client owners might want to define authorization policies for their devices, e.g. define when authorizations for presenting resource representations to the client are to be granted (see section 2 and 6.2 of [2]). Resource owners might want to define authorization policies for the resources on the server. HTH Steffi [1] http://tools.ietf.org/rfc/rfc7252 [2] http://tools.ietf.org/pdf/draft-gerdes-ace-actors.pdf From nobody Mon Jan 19 00:57: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 E93C51A8A4A for ; Mon, 19 Jan 2015 00:57:09 -0800 (PST) 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 3e9gOHyXm5oM for ; Mon, 19 Jan 2015 00:57:02 -0800 (PST) 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 E587A1AD210 for ; Mon, 19 Jan 2015 00:57:01 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-68-54bcc6dcec02 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2F.B3.04231.CD6CCB45; Mon, 19 Jan 2015 09:57:00 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.13]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 09:56:59 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "gerdes@tzi.de" Thread-Topic: [Ace] Role terminology in use case draft (Was: Container Use Case) Thread-Index: AQHQMN8Es9WispTBHE234PMCuF7ah5zHKgUA Date: Mon, 19 Jan 2015 08:56:59 +0000 Message-ID: References: <54B7E75F.20808@tzi.de> In-Reply-To: <54B7E75F.20808@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <2E29746D8850E44FBE37A52631CF0039@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3RvfOsT0hBh8+Clh8/9bDbLHx4l1G ByaPJUt+Mnlse/uVOYApissmJTUnsyy1SN8ugSvjxMYrTAVtGRV/Fm9ibWDckNrFyMEhIWAi cf2QRxcjJ5ApJnHh3nq2LkYuDiGBI4wSd5d+Y4dwFjNKbJn7mAmkik3AReJBwyMwW0RAWaLt z2dGEJtZQFFi96yz7CC2sECgRNOhx2wQNUES8x90M0LYRhJPZhxiAbFZBFQljjSdBYvzClhI rPn6AswWAqp/vfErM4jNKaAisXfnG7A4I9B130+tYYLYJS5x68l8JoirBSSW7DnPDGGLSrx8 /I8VxBYV0JNYeb2JDSKuJLHo9mcmkIeZBTQl1u/ShxhjLXFmeg8LzPlTuh+yQ5wjKHFy5hOW CYwSs5Bsm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERiDB7f8 1t3BuPq14yFGAQ5GJR5eg+I9IUKsiWXFlbmHGKU5WJTEefMcNoQICaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYCyz28hytvXI3FNpLs4h1e8dn7k0fwhYXrI1KbW9QMn5ydfExP2mWfcv9j8p Ma4xEXVSbLq+7XqV2IWn53n63x47M/FckLa4e8fhTjW9C+yGu99N2hm19Uns7CdCXQbnOVtk bsYIqu3uupdw3GvTF77jRffSpqxMX3+wt+VIacI2ne32+z5kvFJiKc5INNRiLipOBACuZgkl ogIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 08:57:10 -0000 SGkgU3RlZmZpDQoNCk9uIDIwMTUtMDEtMTUgMTc6MTQsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJk ZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj4NCj5PbiAwMS8xNC8yMDE1IDEx OjI1IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBIaSBTdGVmZmksDQo+Pg0KPj4gSSBj b250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtIGZvcm11 bGF0aW9ucyBpbg0KPj4gdGhpcyB0aHJlYWQ6DQo+Pg0KPj4gT24gMjAxNS0wMS0xMyAxNTozNywg IlN0ZWZhbmllIEdlcmRlcyI8Z2VyZGVzQHR6aS5kZT4gIHdyb3RlOg0KPj4NCj4+Pj4gLSBTZWN0 aW9ucyAyLngueC4gZW50aXRsZWQgIkF1dGhvcml6YXRpb24gUHJvYmxlbXMgU3VtbWFyeSINCj4+ Pj4gSSB0aGluayBtb3N0IG9mIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zIG1ha2UgbW9yZSBz ZW5zZSB3aXRoDQo+Pj4+ImRldmljZQ0KPj4+PiBvd25lciIgcmVwbGFjZWQgd2l0aCAicmVzb3Vy Y2Ugb3duZXIiLiBSZWZlcnJpbmcgdG8gU3RlZmZpJ3MgbWFpbA0KPj4+PnJlcGx5DQo+Pj4+IHRv DQo+Pj4+IEhhbm5lcyAoU3ViamVjdDogW0FDRV0gQ29udGFpbmVyIFVzZSBDYXNlKSBJIHRoaW5r IGl0IGlzIGNvbmZ1c2luZyB0bw0KPj4+PiB0cnkNCj4+Pj4gdG8gYWRkcmVzcyBzZXJ2ZXIgYW5k IGNsaWVudCBwcm9ibGVtcyB3aXRoIG9uZSBwcm9ibGVtIHN0YXRlbWVudCBhYm91dA0KPj4+PiAi ZGV2aWNlIG93bmVyIi4gSSB3b3VsZCBsaWtlIHRvIHNlcGFyYXRlIHRob3NlIHNvIGl0IGlzIGNs ZWFyIHRvDQo+Pj4+d2hldGhlcg0KPj4+PiB0aGUgcHJvYmxlbSByZWxhdGVzIHRvIHNlcnZlciBv ciBjbGllbnQuIERvIHlvdSBhZ3JlZT8NCj4+Pj4NCj4+PiBXZSBpbnRyb2R1Y2VkIHRoZSB0ZXJt ICJwcmluY2lwYWwiIGluIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgdG8NCj4+PiBhZGRy ZXNzIHRoaXMgcHJvYmxlbS4NCj4+ID5Gcm9tIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQ6 DQo+Pg0KPj4gIlJlc291cmNlIE93bmVyOiBUaGUgc3ViamVjdCB3aG8gb3ducyB0aGUgcmVzb3Vy Y2UgYW5kIGNvbnRyb2xzIGl0cw0KPj5hY2Nlc3MNCj4+IHBlcm1pc3Npb25zLg0KPj4NCj4+IERl dmljZSBPd25lcjogVGhlIHN1YmplY3Qgd2hvIG93bnMgYSBjZXJ0YWluIGRldmljZSBhbmQgY29u dHJvbHMgaXRzDQo+PiBhY2Nlc3MgcGVybWlzc2lvbnMuDQo+Pg0KPj4gUHJpbmNpcGFsOiBBIHN1 YmplY3Qgd2hvIGlzIGVpdGhlciBhIHJlc291cmNlIG93bmVyIG9yIGEgZGV2aWNlIG93bmVyIG9y DQo+PiBib3RoLiINCj4+DQo+PiAtIEkgZG9uwrl0IHNlZSBob3cgdGhlIHRlcm0gInByaW5jaXBh bCIgaXMgc2VwYXJhdGluZyBwcm9ibGVtcyByZWxhdGluZw0KPj50bw0KPj4gY2xpZW50IGZyb20g dGhvc2UgcmVsYXRpbmcgdG8gc2VydmVycy4gT3IgZG8gSSBtaXN1bmRlcnN0YW5kIHdoYXQgeW91 DQo+Pm1lYW4NCj4+IGJ5ICJhZGRyZXNzIHRoaXMgcHJvYmxlbSI/DQo+DQo+TWF5YmUgSSBtaXN1 bmRlcnN0b29kIHlvdXIgcHJvYmxlbS4gSW4gdGhlIHVzZSBjYXNlcyBkcmFmdCB3ZSBkaXNjdXNz DQo+YXV0aG9yaXphdGlvbiBwcm9ibGVtcyBmb3IgYSBzZXR0aW5nIHdoZXJlIG9uZSBvciBtb3Jl IGNvbnN0cmFpbmVkDQo+ZGV2aWNlcyBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIuIENvQVAg aXMgdGhlIGFzc3VtZWQgdG8gYmUgdGhlDQo+cHJvdG9jb2wgdG8gYmUgdXNlZC4gUkZDNzI1MiBb MV0gaW50cm9kdWNlcyB0aGUgdGVybXMgInNlcnZlciIgYW5kDQo+ImNsaWVudCIgZm9yIHRoZXNl IGRldmljZXMsIHdoZXJlIHRoZSBzZXJ2ZXIgaXMgdGhlICJkZXN0aW5hdGlvbg0KPmVuZHBvaW50 IG9mIGEgbWVzc2FnZSIgYW5kIHRoZSBjbGllbnQgaXMgdGhlICJvcmlnaW5hdGluZyBlbmRwb2lu dCBvZiBhDQo+cmVxdWVzdCIuDQo+DQo+QXV0aG9yaXphdGlvbiBzb2x1dGlvbnMgcHJvcG9zZSBv dGhlciAicm9sZXMiIChJIHByZWZlciB0byBjYWxsIHRoZW0NCj4iYWN0b3JzIiBzaW5jZSB0aGUg dGVybSAicm9sZSIgaXMgYSBiaXQgYW1iaWd1b3VzIGluIGF1dGhvcml6YXRpb24NCj5iZWNhdXNl IG9mIFJCQUMpIGFuZCBmdW5jdGlvbnMuIFRoZSB1c2UgY2FzZXMgZGVzY3JpYmVkIGluIHRoZSBk cmFmdA0KPnNob3VsZCBiZSBpbmRlcGVuZGVudCBvZiBzcGVjaWZpYyBzb2x1dGlvbnMgYW5kIGp1 c3QgZGVzY3JpYmUgcHJvYmxlbXMNCj5pbiB0aGlzIGFyZWEuIFRoYXQgYWxsb3dzIHVzIHRvIGxv b2sgYXQgdGhlbSB3aXRoIGFuIG9wZW4gbWluZC4NCj5UaGVyZWZvcmUgaXQgaXMgZGlmZmljdWx0 IHRvIGFwcGx5IHRoZSB0ZXJtaW5vbG9neSBvZiBhIHNwZWNpZmljDQo+c29sdXRpb24gdG8gdGhl IHVzZSBjYXNlcy4NCg0KDQpbR1NdIEnigJltIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCDigJx0ZXJt aW5vbG9neSBvZiBhIHNwZWNpZmljIHNvbHV0aW9u4oCdLiBJDQp0aGluayB3ZSBhbGwgYWdyZWUg dGhhdCB3ZSBhcmUgYXNzdW1pbmcgc29tZXRoaW5nIGxpa2UgUkVTVCwgdGhhdCB0aGVyZQ0KYXJl IHJlc291cmNlcywgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcy4gVGhlbiB0aGVyZSBuZWVkcyB0byBi ZSBzb21lIGVudGl0eQ0KdGhhdCByZXF1ZXN0cyBhbmQgc29tZSB0aGUgcmVzcG9uZHMgZXRjLiBB bmQgdGhlbiB3ZSBjYW4gZm9ybXVsYXRlIHRoZQ0KYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBpbiB0 ZXJtcyBvZiB0aGVzZSBuYW1lcy4gV2h5IGlzIHRoZXJlIGFyZSBwcm9ibGVtDQpzZXBhcmF0aW5n IGF1dGhvcml6YXRpb24gcHJvYmxlbXMgb24gdGhlIHJlcXVlc3Rpbmcgc2lkZSBmcm9tIHRob3Nl IG9uIHRoZQ0KcmVzcG9uZGluZyBzaWRlPw0KDQoNCg0KPg0KPk1vcmVvdmVyLCB0aGUgdXNlIGNh c2VzIGN1cnJlbnRseSBkb24ndCBpbmRpY2F0ZSB0aGF0IHRoZXJlIGFyZSBzdHJvbmcNCj5yZWFz b25zIHRvIGFwcGx5IGV2ZW4gdGhlIHRlcm1zIHRoYXQgYXJlIGRlZmluZWQgaW4gQ29BUCB0byB0 aGUNCj5wYXJ0aWNpcGF0aW5nIGVudGl0aWVzLiBJIHVuZGVyc3RhbmQgdGhhdCBpdCB3b3VsZCBi ZSB1c2VmdWwgZm9yIHRoZQ0KPmRldmVsb3BtZW50IG9mIGFuIGF1dGhvcml6YXRpb24gc29sdXRp b24gaWYgd2UgY291bGQgZGVmaW5lIHRoYXQgYnV0IEkNCj5kb24ndCB0aGluayBpdCBpcyBhIGdv b2QgaWRlYSB0byBwaWNrIG9uZSBhcmJpdHJhcmlseS4gSWYgdGhlcmUgcmVhbGx5DQo+YXJlIHJl YXNvbnMgZm9yIHRoYXQsIHdlIHNob3VsZCBwb2ludCB0aGVtIG91dC4NCg0KW0dTXSBJ4oCZbSBz b3JyeSBidXQgSSBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5kIHRoaXMgZWl0aGVyLiBXaGF0IGlz IHRoZQ0KcHJvYmxlbSB3aXRoIOKAnHBpY2sgb25lIFt0ZXJtaW5vbG9neV0gYXJiaXRyYXJpbHni gJ0/IEkgYmVsaWV2ZSBpdCBzaG91bGQgYmUNCnBvc3NpYmxlIHRvIHRyYW5zbGF0ZSB0ZXJtaW5v bG9neSwgbGlrZSBoYXMgYmVlbiBkb25lIGJldHdlZW4gVU1BIGFuZA0KT0F1dGguIEZvciB0aGUg dXNlIGNhc2UgdGVybWlub2xvZ3kgd2UgbmVlZCBvbmUgc28ganVzdCBwaWNrIG9uZS4NCg0KPg0K PkFub3RoZXIgYXNwZWN0IG9mIHRoZSB0ZXJtaW5vbG9neSBkaXNjdXNzaW9uIGlzIHRoZSBkaXN0 aW5jdGlvbiBiZXR3ZWVuDQo+dGhlIGRpZmZlcmVudCB0eXBlcyBvZiAib3duZXJzIi4gRHVyaW5n IHRoZSBBQ0Ugc2Vzc2lvbiBpbiBIb25vbHVsdSwNCj50aGVyZSB3YXMgYSBkaXNjdXNzaW9uIGFi b3V0IHRoZSB1c2FnZSBvZiB0aGUgdGVybSBSZXNvdXJjZSBPd25lciBpbiB0aGUNCj5hY3RvcnMg ZHJhZnQgWzJdLiBXaGF0IEkgdG9vayBhd2F5IGZyb20gdGhhdCBkaXNjdXNzaW9uIGlzIHRoYXQg cmVzb3VyY2UNCj5vd25lcnMgYW5kIGRldmljZSBvd25lcnMgbWlnaHQgZGlmZmVyIGFuZCBoYXZl IGRpZmZlcmVudCBzZWN1cml0eQ0KPm9iamVjdGl2ZXMuIA0KDQpbR1NdIEkgY2Fu4oCZdCBmaW5k IHRoYXQgaW4gdGhlIGF1ZGlvIHJlY29yZGluZ3Mgb2YgdGhlIHNlc3Npb24sIGNvdWxkIHlvdQ0K cGxlYXNlIHJlcGVhdCB0aGUgYXJndW1lbnQ/IEkgZGlkIGZpbmQgc2V2ZXJhbCBjb21tZW50cyBh Ym91dCBhIFJlc291cmNlDQpTZXJ2ZXIgaGF2aW5nIG11bHRpcGxlIFJlc291cmNlcyB3aGljaCBt YXkgaGF2ZSBkaWZmZXJlbnQgUmVzb3VyY2UgT3duZXJzLA0Kd2FzIHRoaXMgd2hhdCB5b3Ugd2Vy ZSByZWZlcnJpbmcgdG8/IEkgdGhpbmsgdGhhdCBjb21tZW50IHdhcnJhbnRzIHRoZQ0KZm9ybXVs YXRpb24gb2YgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBpbiB0ZXJtcyBvZiB0aGUgUmVzb3VyY2Ug T3duZXJzIGFuZA0KUmVzb3VyY2VzLCBub3QgdGhhdCB3ZSBuZWVkIHRvIGludHJvZHVjZSBhbm90 aGVyIHJvbGUuDQoNCg0KDQo+TW9yZW92ZXIsIGl0IG1pZ2h0IG5vdCBldmVuIGJlIGNvcnJlY3Qg dG8gdGFsayBhYm91dCBvd25lcnMNCj5hdCBhbGwuIEkgZG9uJ3Qgc2VlIHRoYXQgdGhlcmUgYXJl IGdvb2QgcmVhc29ucyB0byBkaXN0aW5ndWlzaCBpbiB0aGUNCj51c2UgY2FzZXMgaWYgYW4gaXNz dWUgaXMgYSByZXNvdXJjZSBvd25lciBvciBkZXZpY2Ugb3duZXIgcHJvYmxlbS4gSWYNCj50aGVy ZSBhcmUgZ29vZCByZWFzb25zIHRvIHVzZSBvbmUgb3IgdGhlIG90aGVyIGluIGEgdXNlIGNhc2Us IHdlIHNob3VsZA0KPnBvaW50IHRoaXMgb3V0IGluIHRoZSBkb2N1bWVudC4NCj4NCj5UaGUgdGVy bSAicHJpbmNpcGFsIiB3YXMgaW50cm9kdWNlZCBpbiB0aGUgZG9jdW1lbnQgYXMgYSBtb3JlIGdl bmVyYWwNCj50ZXJtIGZvciBjYXNlcyB3aGVyZSBpdCBpcyBub3QgcG9zc2libGUgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgc29tZW9uZSBpcw0KPmEgZGV2aWNlIG9yIGEgcmVzb3VyY2Ugb3duZXIuDQoN CltHU10gQXMgbWVudGlvbmVkIGFib3ZlLCBJIG1pc3MgdGhlIHJhdGlvbmFsZSBmb3Igc3BlYWtp bmcgYWJvdXQgZGV2aWNlDQpvd25lcnMgYXQgYWxsLiBUaGUgdXNlIG9mIHRoZSB0ZXJtIHByaW5j aXBhbCwgd2hpY2ggaGFzIG11bHRpcGxlIG1lYW5pbmdzLA0KaXMgY29uZnVzaW5nIHRoZSBmb3Jt dWxhdGlvbiBvZiB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBhcyBJIHNob3cgaW4NCnRoZSBz cGVjaWZpYyBjb21tZW50cyBJIGdhdmUgb24gdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbXMuDQoN Cg0KPg0KPj4gLSBGdXJ0aGVyLCB3aGF0IGlzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBkZXZp Y2UgYWNjZXNzIHBlcm1pc3Npb25zDQo+PmFuZA0KPj4gcmVzb3VyY2UgYWNjZXNzIHBlcm1pc3Np b25zPw0KPj4NCj4+IElzIGl0IHNvIHRoYXQgYWNjZXNzIGEgcmVzb3VyY2Ugb24gYSBkZXZpY2Ug eW91IG5lZWQgYm90aCBkZXZpY2UgYWNjZXNzDQo+PiBwZXJtaXNzaW9ucyBhbmQgcmVzb3VyY2Ug YWNjZXNzIHBlcm1pc3Npb25zPyBXb3VsZCB0aGF0IG1lYW4gdGhhdCB5b3UNCj4+bWF5DQo+PiBu b3QgYmUgYWJsZSB0byBhY2Nlc3MgdGhlIHJlc291cmNlIGRlc3BpdGUgaGF2aW5nIGJlZW4gZ3Jh bnRlZCBhY2Nlc3MgYnkNCj4+IHRoZSByZXNvdXJjZSBvd25lciBiZWNhdXNlIG9mIG5vdCBoYXZp bmcgdGhlIGRldmljZSBhdXRob3JpemF0aW9uPyBBbmQNCj4+IHZpY2UgdmVyc2E/DQo+DQo+SSBk b24ndCBrbm93IGlmIHRoZXJlIGFyZSBnb29kIHJlYXNvbnMgdG8gaGF2ZSBkZXZpY2UgYWNjZXNz IHBlcm1pc3Npb25zDQo+YW5kIHJlc291cmNlIGFjY2VzcyBwZXJtaXNzaW9ucyBmb3IgdGhlIHNh bWUgZGV2aWNlLiBJZiB0aGVyZSBhcmUgdXNlDQo+Y2FzZXMgd2hlcmUgdGhpcyBpcyBuZWNlc3Nh cnksIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBwb2ludCB0aGVtIG91dC4NCj4NCj5Zb3Ugc2VlbSB0 byBhc3N1bWUgdGhhdCBvd25lcnMgYWx3YXlzIHdhbnQgdG8gYXV0aG9yaXplIGFjY2VzcyB0byBh DQo+cmVzb3VyY2UsIGJ1dCB0aGF0IGlzIG5vdCBuZWNlc3NhcmlseSB0cnVlLiBUaGVyZSBhcmUg dHdvIHBhcnRpZXMNCj5jb21tdW5pY2F0aW5nIHdpdGggZWFjaCBvdGhlciwgdGhlIGNsaWVudCBh bmQgdGhlIHNlcnZlci4gQ2xpZW50IG93bmVycw0KPm1pZ2h0IHdhbnQgdG8gZGVmaW5lIGF1dGhv cml6YXRpb24gcG9saWNpZXMgZm9yIHRoZWlyIGRldmljZXMsIGUuZy4NCj5kZWZpbmUgd2hlbiBh dXRob3JpemF0aW9ucyBmb3IgcHJlc2VudGluZyByZXNvdXJjZSByZXByZXNlbnRhdGlvbnMgdG8N Cj50aGUgY2xpZW50IGFyZSB0byBiZSBncmFudGVkIChzZWUgc2VjdGlvbiAyIGFuZCA2LjIgb2Yg WzJdKS4gUmVzb3VyY2UNCj5vd25lcnMgbWlnaHQgd2FudCB0byBkZWZpbmUgYXV0aG9yaXphdGlv biBwb2xpY2llcyBmb3IgdGhlIHJlc291cmNlcyBvbg0KPnRoZSBzZXJ2ZXIuDQoNCltHU10gT0ss IGxldOKAmXMgc2VlIGlmIEkgdW5kZXJzdGFuZC4gU28g4oCcRGV2aWNlIiBtYXkgbWVhbiAiQ2xp ZW504oCdIG9yDQrigJxSZXNvdXJjZSBTZXJ2ZXLigJ0uIEhlbmNlIOKAnERldmljZSBPd25lcuKA nSBtYXkgbWVhbiDigJxDbGllbnQgT3duZXLigJ0gb3INCuKAnFJlc291cmNlIFNlcnZlciBPd25l cuKAnS4gUHJpbmNpcGFsIHRodXMgbWF5IG1lYW4gIkNsaWVudCBPd25lcuKAnSBvcg0K4oCcUmVz b3VyY2UgT3duZXLigJ0gb3Ig4oCcUmVzb3VyY2UgU2VydmVyIE93bmVy4oCdLiBJcyB0aGF0IGNv cnJlY3Q/DQoNCk5vdywgbW9zdCBBdXRob3JpemF0aW9uIFByb2JsZW1zIGluIHRoZSB1c2UgY2Fz ZSBkcmFmdCBhcmUgZm9ybXVsYXRlZCBpbg0KdGVybXMgb2Yg4oCcUHJpbmNpcGFs4oCdLiBUaGUg dGVybXMgIkNsaWVudCBPd25lcuKAnSBhbmQgIlJlc291cmNlIFNlcnZlciBPd25lcuKAnQ0KYXJl IGV2ZW4gbWlzc2luZyBmcm9tIHRoZSB0ZXJtaW5vbG9neS4gU2luY2UgbW9zdCBBdXRob3JpemF0 aW9uIFByb2JsZW1zDQphcmUgZm9ybXVsYXRlZCBpbiB0ZXJtcyBvZiDigJxQcmluY2lwYWwiIGl0 IGJsdXJzIGFueSBkaXN0aW5jdGlvbiBiZXR3ZWVuDQrigJxDbGllbnQgT3duZXLigJ0sIOKAnFJl c291cmNlIFNlcnZlciBPd25lcuKAnSBhbmQg4oCcUmVzb3VyY2UgT3duZXLigJ0gYW5kIHlvdSBj YW7igJl0DQpldmVuIGV4cHJlc3MgYW55IHNwZWNpZmljIGFzcGVjdHMgb2YgdGhlc2UgYmVjYXVz ZSBvZiBtaXNzaW5nIHRlcm1pbm9sb2d5Lg0KU28gdGhlIGNob2ljZSBvZiB0ZXJtaW5vbG9neSBp cyBhY3R1YWxseSBoaWRpbmcgYW55IHBvdGVudGlhbCBkaWZmZXJlbmNlcw0KYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCByZXNvdXJjZSBzaWRlLg0KDQpJbiBvdGhlciB3b3JkcywgeW91IGFyZSBlc3Nl bnRpYWxseSBvbmx5IGNvbnNpZGVyaW5nIGF1dGhvcml6YXRpb24NCnByb2JsZW1zIHdoaWNoIGFy ZSBhYnN0cmFjdCBlbm91Z2ggdG8gYmUgc3ltbWV0cmljIGluIHRlcm1zIG9mIGNsaWVudCBzaWRl DQphbmQgcmVzb3VyY2Ugc2lkZSBhbmQgZG9u4oCZdCB3YW50IHRvIGludHJvZHVjZSB0ZXJtaW5v bG9neSB0aGF0IGFsbG93cyBhDQpkaXN0aWN0aW9uLiANCg0KSSB0aGluayB0aGUgYXBwcm9hY2gg dGhhdCB5b3UgcHJvcG9zZSBpbiB5b3VyIERDQUYgc29sdXRpb24gZHJhZnQgYW5kIHlvdXINCkFj dG9ycyB0ZXJtaW5vbG9neSBkcmFmdCBpcyBpbnRlcmVzdGluZy4gQW5kIHdlIGFncmVlZCB0aGF0 IHRoZQ0KdGVybWlub2xvZ3kgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0IHNob3VsZCBub3QgcHJvbW90 ZSBhIHNwZWNpZmljIHNvbHV0aW9uLg0KSSBiZWxpZXZlIHlvdSBhY3QgaW4gZ29vZCBmYWl0aCBh bmQgd2l0aCBhbGwgcmVzcGVjdCwgSSB0aGluayB0aGUgY3VycmVudA0KdGVybWlub2xvZ3kgYW5k IGF1dGhvcml6YXRpb24gcHJvYmxlbSBmb3JtdWxhdGlvbiB3aGljaCB0cmVhdCB0aGUgcmVzb3Vy Y2UNCnNpZGUgYW5kIGNsaWVudCBzaWRlIGluIGEg4oCcc3ltbWV0cmlj4oCdIHdheSBpcyBhIGJp dCBmb3JjZWQgYW5kIG5vdCBkZWR1Y2VkDQpmcm9tIHRoZSB1c2UgY2FzZXMuIElmIG5vdCBmb3Ig YW55IG90aGVyIHJlYXNvbiwgdGhlbiBzaW1wbHkgYmVjYXVzZSB0aGUNCmJhc2ljIHJlc291cmNl IGFjY2VzcyBwcm9ibGVtIGlzIGEgcHJpb3JpIG5vdCBzeW1tZXRyaWM6IEkgYWdyZWUgdGhhdA0K dGhlcmUgbWF5IGJlIGF1dGhvcml6YXRpb24gYXNwZWN0cyBhbHNvIG9uIHRoZSBjbGllbnQgc2lk ZS4gSSBhZ3JlZSB0aGF0DQp0aGVyZSBhcmUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIHNlbnQg aW4gYm90aCBkaXJlY3Rpb25zIGJldHdlZW4gY2xpZW50DQphbmQgcmVzb3VyY2Ugc2VydmVyLiBC dXQgSSBkaXNhZ3JlZSB3aXRoIHRoZSBmb3JtdWxhdGlvbiB0aGF0IHRoZQ0KYXV0aG9yaXphdGlv biBwcm9ibGVtcyBhcmUgYSBwcmlvcmkgc3ltbWV0cmljIGluIGNsaWVudCBhbmQgcmVzb3VyY2Uu IE9uZQ0Kb2J2aW91cyByZWFzb24gZm9yIGFzeW1tZXRyeSBpcyB0aGF0IHRoZSBjbGllbnQgcmVx dWVzdHMgYSByZXNvdXJjZSBhbmQNCm5vdCB2aWNlIHZlcnNhLiANCg0KV2UgaGF2ZSB0d28gb3B0 aW9uczogMSkgRWl0aGVyIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zIGFyZSBkaWZmZXJlbnQN CmRlcGVuZGluZyBvbiB3aGljaCB5b3UgdGVybSDigJxjbGllbnTigJ0gYW5kIHdoaWNoIHlvdSB0 ZXJtIOKAnHJlc291cmNlIiBvciAyKQ0KdGhlcmUgaXMgbm8gZGlmZmVyZW5jZS4gSW4gY2FzZSAx KSB3ZSBzaG91bGQgdXNlIG1vcmUgc3BlY2lmaWMgdGVybWlub2xvZ3kNCnRvIHVuZGVyc3RhbmQg dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgY2xpZW50IHNpZGUgYW5kIHRoZSByZXNvdXJjZQ0K c2lkZS4gSW4gY2FzZSAyKSwgaWYgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSwgdGhlbiBpdCBkb2Vz buKAmXQgbWF0dGVyIHdoYXQNCndlIHRlcm0gYXMg4oCcY2xpZW504oCdIGFuZCDigJxyZXNvdXJj ZeKAnSBpbiB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcywgZG9lcyBpdD8NClNvIHRoZW4gd2Ug Y2FuIGFzc2lnbiB0aGUgcm9sZXMgYXJiaXRyYXJpbHkgYW5kIGZvcm11bGF0ZSB0aGUNCmF1dGhv cml6YXRpb24gcHJvYmxlbXMgd2l0aG91dCBsb3NzIG9mIGdlbmVyYWxpdHkuIFNvIEkgZG9u4oCZ dCBzZWUgYQ0KcHJvYmxlbSBiZWluZyBtb3JlIHNwZWNpZmljLg0KDQpJbiBzdW1tYXJ5LCBJIHN0 cm9uZ2x5IHByb3Bvc2UgdGhhdCBpbnN0ZWFkIG9mIGhpZGluZyB0aGUgZGlmZmVyZW5jZXMNCmJl dHdlZW4gcmVzb3VyY2UgYW5kIGNsaWVudCwgbWFrZSBpdCBleHBsaWNpdCB3aGF0IGFyZSB0aGUg cHJvYmxlbXMgb24gdGhlDQpjbGllbnQgYW5kIHJlc291cmNlIHNpZGUgaW4gZWFjaCB1c2UgY2Fz ZS4gVGhlbiBldmVyeW9uZSBjYW4gZm9ybSBpdHMgb3duDQpvcGluaW9uIGFib3V0IHRoZSBkZWdy ZWUgb2Ygc3ltbWV0cnksIHJhdGhlciB0aGFuIGFzc3VtaW5nIGJlZm9yZWhhbmQgdGhhdA0KaXQg aXMgc3ltbWV0cmljLiBBIHNlY29uZCBwcm9wb3NhbCBpcyB0byB1c2UgZXN0YWJsaXNoZWQgdGVy bWlub2xvZ3kgc3VjaA0KYXMgT0FVdGggb3IgVU1BLiBCdXQgdGhlIGNob2ljZSBvZiB0ZXJtaW5v bG9neSBpcyBsZXNzIGltcG9ydGFudCBzaW5jZSB3ZQ0Kc2hvdWxkIGJlIGFibGUgdG8gbWFwIGJl dHdlZW4gdGhlbS4NCg0KDQoNCkRpZCB5b3UgYWxzbyBpbnRlbmQgdG8gYW5zd2VyIHRoZSBzcGVj aWZpYyBjb21tZW50cyBJIGdhdmUgb24gdGhlDQphdXRob3JpemF0aW9uIHByb2JsZW1zPw0KDQoN ClJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= From nobody Wed Jan 21 03:40:10 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9E91A1A06 for ; Wed, 21 Jan 2015 03:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msszYijpgF7q for ; Wed, 21 Jan 2015 03:40:07 -0800 (PST) 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 6FBE61A1A14 for ; Wed, 21 Jan 2015 03:40:07 -0800 (PST) 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 t0LBe1Zi016601; Wed, 21 Jan 2015 12:40:02 +0100 (CET) Received: from [192.168.1.130] (p57A63E02.dip0.t-ipconnect.de [87.166.62.2]) (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 3kS4Xd0QCRz83vf; Wed, 21 Jan 2015 12:40:00 +0100 (CET) Message-ID: <54BF9005.1050605@tzi.de> Date: Wed, 21 Jan 2015 12:39:49 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <54B7E75F.20808@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 11:40:09 -0000 Hi Göran, On 01/19/2015 09:56 AM, Göran Selander wrote: > > [GS] I’m not sure I understand “terminology of a specific solutionâ€. I > think we all agree that we are assuming something like REST, that there > are resources, requests and responses. Then there needs to be some entity > that requests and some the responds etc. And then we can formulate the > authorization problems in terms of these names. Why is there are problem > separating authorization problems on the requesting side from those on the > responding side? Because we don't know in the use cases which side is the requesting side (the CoAP client) and which one is the responding (the CoAP server). If there are good reasons to say which one is which, we should point this out in the use cases and use the respective terminology. I think that in the most cases this will not be possible as there might be reasons for each setting. Moreover, a single device will at one time act as the server while later on it will act as the client. If you have ideas how to solve this, please provide text. > [GS] OK, let’s see if I understand. So “Device" may mean "Client†or > “Resource Serverâ€. Hence “Device Owner†may mean “Client Owner†or > “Resource Server Ownerâ€. Principal thus may mean "Client Owner†or > “Resource Owner†or “Resource Server Ownerâ€. Is that correct? > > Now, most Authorization Problems in the use case draft are formulated in > terms of “Principalâ€. The terms "Client Owner†and "Resource Server Owner†> are even missing from the terminology. Since most Authorization Problems > are formulated in terms of “Principal" it blurs any distinction between > “Client Ownerâ€, “Resource Server Owner†and “Resource Owner†and you can’t > even express any specific aspects of these because of missing terminology. > So the choice of terminology is actually hiding any potential differences > between the client and resource side. > We can add the terms "Client Owner" and "Resource Server Owner" to the terminology if that helps things. Thanks, Steffi From nobody Wed Jan 21 03:40:28 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 02DEA1A1A1E for ; Wed, 21 Jan 2015 03:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0oMGiqt7CZH for ; Wed, 21 Jan 2015 03:40:21 -0800 (PST) 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 15AFE1A1A1C for ; Wed, 21 Jan 2015 03:40:20 -0800 (PST) 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 t0LBeHOv019317; Wed, 21 Jan 2015 12:40:17 +0100 (CET) Received: from [192.168.1.130] (p57A63E02.dip0.t-ipconnect.de [87.166.62.2]) (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 3kS4Xw2V02z83vg; Wed, 21 Jan 2015 12:40:15 +0100 (CET) Message-ID: <54BF901E.7070905@tzi.de> Date: Wed, 21 Jan 2015 12:40:14 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <54B67C9D.9000703@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Security considerations of the use case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 11:40:22 -0000 Hi Göran, On 01/15/2015 09:15 AM, Göran Selander wrote: > > On 2015-01-14 15:26, "Stefanie Gerdes" wrote: > >> You are right that there are a lot of different solutions to provide the >> policies to the device and it is not the intent of the paragraph to >> suggest a specific solution. Maybe rephrasing helps: >> >> "The access control policies set by the Principals need to be provided >> to the device that enforces the authorization and applied to every >> incoming request." >> >> What do you think? > What I’m saying is that it is not necessarily access control policies that > are “provided to the device", so we should perhaps formulate it in a > different way? See below. How about: The information that is needed to implement the access control policies of the principal needs to be provided to the device that enforces the authorization and applied to every incoming request. If you don't agree with this phrasing, please provide text. Thanks, Steffi From nobody Wed Jan 21 03:40: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 86DFA1A1A19 for ; Wed, 21 Jan 2015 03:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8Z615zj-hEM for ; Wed, 21 Jan 2015 03:40:31 -0800 (PST) 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 8D34C1A1A20 for ; Wed, 21 Jan 2015 03:40:31 -0800 (PST) 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 t0LBeRjJ019684; Wed, 21 Jan 2015 12:40:27 +0100 (CET) Received: from [192.168.1.130] (p57A63E02.dip0.t-ipconnect.de [87.166.62.2]) (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 3kS4Y61t4Nz83vt; Wed, 21 Jan 2015 12:40:26 +0100 (CET) Message-ID: <54BF9029.4060200@tzi.de> Date: Wed, 21 Jan 2015 12:40:25 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?windows-1252?Q?G=F6ran_Selander?= References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 11:40:33 -0000 Hi Göran, I agree that we should look over the correct usage of the terminology for the next version. But as I stated before, I find it difficult to define if a device is a client or a server. Maybe an example helps: In the medical use case patients should be able to control the access rights to their data which indicates that the patient should be the resource owner. If this data is transmitted to the device of their practitioner, there are two possible solutions: either the patient's medical device is the server and the practitioner's device is the client or the vice versa. For either case, both the practitioner and the patient will want to make sure that the transmitted information is transmitted securely. If the practitioner's device is the server, the patient's device will write data to the practitioner's resource and the practitioner will be the resource owner. I see no reason to prohibit either version and thus I am not comfortable with arbitrarily picking one of them. Steffi On 01/14/2015 11:25 AM, Göran Selander wrote: > > Some specific comments: > > o U1.1 Principals such as the fruit vendor, the transloading personnel or > the container owners want to grant different access rights for their > resource to different parties and want to control which devices are > allowed to present data to their devices. > > - Is fruit vendor ³resource owner² or ³device owner² or both? The same > question for transloading personnel and container owner. > > > ³control which devices are allowed to present data to their devices" > > - What does this correspond to in the use case? > > > > o U1.2 Principals want to grant different access rights for different > resources on a device. > > - Same question as above about what if device owner and resource owner set > incompatible access policies? > > > > o U1.3 The principals require the integrity of sensor data. > > - I understand that, for example, a client requires integrity of sensor > data, but I don¹t understand why this would be a requirement of a ³device > owner² > > > o U1.4 The principals require the confidentiality of sensor data. > > - I understand that the resource owner requires confidentiality of sensor > data, but I don¹t understand why this would be a requirement of a ³device > owner² > > > > o U3.1 A principal, such as the owner of a health monitoring device, > wants to pre-configure access rights to specific data for persons or > groups, in the context of an emergency. > > - The owner of a health monitoring device may be a patient, a caregiver > organization or outsourced to a trusted third party. Independently of who > owns the device, the resource owner should be able to set the access > rights. So I think principal should be replaced by resource owner. > > > > o U3.2 A principal wants to selectively allow different persons or groups > to access medical data. > > - As above, principal should be replaced with resource owner. > > > > o U5.1 Devices are installed in hostile environments where they are > physically accessible by attackers. Principals want to make sure that an > attacker cannot use a captured device to attack other parts of their > infrastructure. > > - I see this primarily as a concern of the owner of the infrastructure, > not a concern of a resource owner. Of course, if the infrastructure is > attacked the resource owner may be inflicted, but preventing this kind of > attack is nothing an entity in the role of resource owner can ³make sure². > So I propose to replace the term principal. > > > > o U5.2 Principals want to restrict which entities are allowed to write > data to the devices and thus ensure the integrity of the data on their > devices. > > - I agree that access control to and integrity protection of utility data > is a relevant problem statement can be deduced from this use case, but I > find this formulation somewhat confusing. In the case ³principal² means > ³resource owner", the formulation ³write data to the devices² or > ³integrity of the data on their devices² does not make sense; the resource > owner does not necessarily own any devices and ³data on devices" would > better be formulated in terms of "resource representations² or similar. > > > > o U5.7 Messages between a client and the device may need to be stored and > forwarded over multiple nodes. > > - I think ³device² should be replaced by ³resource server². The difference > between "device" and ³node² is not clear. > > > From nobody Wed Jan 21 06: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 28EFD1A1AB3; Wed, 21 Jan 2015 06:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4YP-CaXIiYD; Wed, 21 Jan 2015 06:06:14 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 64AF91A1AC2; Wed, 21 Jan 2015 06:06:04 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 27DDEED71; Wed, 21 Jan 2015 15:06:03 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t0LE621J012703 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jan 2015 15:06:02 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id B4FCA42C; Wed, 21 Jan 2015 15:06:02 +0100 (CET) Message-ID: <54BFB249.1060000@sics.se> Date: Wed, 21 Jan 2015 15:06:01 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "ace@ietf.org" , core References: <54BF8185.9090609@sics.se> In-Reply-To: <54BF8185.9090609@sics.se> X-Forwarded-Message-Id: <54BF8185.9090609@sics.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090300080908090401020203" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NGC62nr - 7b7024d4e081 - 20150121 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NGC62nr&m=7b7024d4e081&t=20150121&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NGC62nr&m=7b7024d4e081&t=20150121&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NGC62nr&m=7b7024d4e081&t=20150121&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [Ace] Unique resource identifiers X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 14:06:19 -0000 This is a cryptographically signed message in MIME format. --------------ms090300080908090401020203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I'm just (re-)thinking the issue of authorization tokens and how to encode authorization decisions, and the following problem has come up: We need to uniquely identify a resource in order to do any kind of non-local authorization on it. At first the obvious approach seemed to be to use Uri-host and Uri-path of the origin server, but there are several problems with this: 1.) The origin server might change address, see e.g. http://www.ietf.org/mail-archive/web/core/current/msg05625.html 2.) The resource might not be on the origin server when access control has to be performed, say e.g. a store-and-forward scenario, or a publish-subscribe scenario as in http://tools.ietf.org/html/draft-koster-core-coapmq-00. I think we might need some unique resource identifier that is neither dependent on the host address nor on the internal resource hierarchies on the origin server. The added benefit would be that a proxy could handle encrypted resource representations, without gaining any knowledge about the internal resource structure on the origin server. What do you think about this issue? Regards, Ludwig Seitz PS: Sorry for cross-posting this to CoRE, but I suspect we might get some useful input from there. --=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 --------------ms090300080908090401020203 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 KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAxMjExNDA2MDFaMCMGCSqGSIb3DQEJBDEW BBTrttOlMe7KJuOSt4+XM282KBI7XTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAVxdlaMK0NXElnqKLuaUlbZ2+4B8tT3/DY5OYgYfn9Q1LoxmOeNcGZUpr8P4mXKPEK43N OUnnUtAH3XkWudXxHbpAmwJjpKAZBTtSaNgpUxApfEyxFMPkHokbTL09/zeNoR1cvACTG8mf U802hJokrVQFU1oOzX7LDZT/JGvbZxuvSx1wrIf/Mtq5xiu9y4FUV01FDhNRyQZRSh3N98mC LKXu2NlEoihadXAyQmpo4tc5XKwifBUwn3BTDqbSWYyaMsBJzEdlnlvK9sZnr1VlKxIR3iPY 1sz23AaR9opa2CkA/oJD4OyeM2neVodwbpzSuy8K2FeMHNYOsdmh0UDU0wAAAAAAAA== --------------ms090300080908090401020203-- From nobody Wed Jan 21 06:23: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 7FF9C1A1AB4; Wed, 21 Jan 2015 06:23:14 -0800 (PST) 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, MIME_QP_LONG_LINE=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 KTGhGAySUZHb; Wed, 21 Jan 2015 06:23:08 -0800 (PST) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id DD67D1A1AAB; Wed, 21 Jan 2015 06:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1421850181; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=eEC7S3BoDn9UrXFTjkzNfzmhQesHL7ynkpaySqSJYhQ=; b=BiZsrwZexS93YtNxJ4Fx1dFZn+Ztx6YM/kvC7FIWq5NrgwVXhApEwpUYXwrvwnw5KIc15Z980WwZS5wMcX36JTRFIOTZWQRFyfsrnOyuxWpT3pUztbcWaGWcXdSk94ptl+EP0v2HAwVGB+6gH9TiDH8UUfMiQhSrSqNBlxBLB24= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05020; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.22.16.140(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.202) by smtp.aliyun-inc.com(127.0.0.1); Wed, 21 Jan 2015 22:22:59 +0800 User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Wed, 21 Jan 2015 22:22:54 +0800 From: "Kepeng Li" To: Ludwig Seitz , "ace@ietf.org" , core Message-ID: Thread-Topic: [Ace] Unique resource identifiers References: <54BF8185.9090609@sics.se> <54BFB249.1060000@sics.se> In-Reply-To: <54BFB249.1060000@sics.se> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] Unique resource identifiers X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 14:23:14 -0000 One possible way is to use EndpointID to identify the origin server, instead of using Uri-host. EndpointID should be unique within one Resource Directory domain. It works in case of IP address change, and store-and-forward scenario, or publish-subscribe scenario. This may add burden to the Authorization Server to correlate EndpointIDs and Uri-hosts. Kind Regards Kepeng =E5=9C=A8 21/1/15 10:06 pm=EF=BC=8C "Ludwig Seitz" =E5=86=99=E5=85=A5: >Hello, > >I'm just (re-)thinking the issue of authorization tokens and how to >encode authorization decisions, and the following problem has come up: > >We need to uniquely identify a resource in order to do any kind of >non-local authorization on it. > >At first the obvious approach seemed to be to use Uri-host and Uri-path >of the origin server, but there are several problems with this: > > >1.) The origin server might change address, see e.g. >http://www.ietf.org/mail-archive/web/core/current/msg05625.html > >2.) The resource might not be on the origin server when access control >has to be performed, say e.g. a store-and-forward scenario, or a >publish-subscribe scenario as in >http://tools.ietf.org/html/draft-koster-core-coapmq-00. > >I think we might need some unique resource identifier that is neither >dependent on the host address nor on the internal resource hierarchies >on the origin server. > >The added benefit would be that a proxy could handle encrypted >resource representations, without gaining any knowledge about the >internal resource structure on the origin server. > >What do you think about this issue? > >Regards, > >Ludwig Seitz > >PS: Sorry for cross-posting this to CoRE, but I suspect we might get >some useful input from there. > >--=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 > > > > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Wed Jan 21 06:27: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 772401A1AC1; Wed, 21 Jan 2015 06:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d80NwptVM5pf; Wed, 21 Jan 2015 06:27:30 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592DC1A1ABE; Wed, 21 Jan 2015 06:27:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3ADABE2035; Wed, 21 Jan 2015 09:27:29 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 01687-08; Wed, 21 Jan 2015 09:27:22 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 6960FE203F; Wed, 21 Jan 2015 09:27:22 -0500 (EST) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 21 Jan 2015 09:27:22 -0500 Message-ID: <0b817fa68ac001f46f044508eafe521e.squirrel@mail2.ihtfp.org> In-Reply-To: <54BFB249.1060000@sics.se> References: <54BF8185.9090609@sics.se> <54BFB249.1060000@sics.se> Date: Wed, 21 Jan 2015 09:27:22 -0500 From: "Derek Atkins" To: "Ludwig Seitz" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: core , "ace@ietf.org" Subject: Re: [Ace] Unique resource identifiers X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 14:27:32 -0000 Sounds like you are trying to re-invent HIP. (See RFC 5201 and RFC 4423) -derek On Wed, January 21, 2015 9:06 am, Ludwig Seitz wrote: > Hello, > > I'm just (re-)thinking the issue of authorization tokens and how to > encode authorization decisions, and the following problem has come up: > > We need to uniquely identify a resource in order to do any kind of > non-local authorization on it. > > At first the obvious approach seemed to be to use Uri-host and Uri-path > of the origin server, but there are several problems with this: > > > 1.) The origin server might change address, see e.g. > http://www.ietf.org/mail-archive/web/core/current/msg05625.html > > 2.) The resource might not be on the origin server when access control > has to be performed, say e.g. a store-and-forward scenario, or a > publish-subscribe scenario as in > http://tools.ietf.org/html/draft-koster-core-coapmq-00. > > I think we might need some unique resource identifier that is neither > dependent on the host address nor on the internal resource hierarchies > on the origin server. > > The added benefit would be that a proxy could handle encrypted > resource representations, without gaining any knowledge about the > internal resource structure on the origin server. > > What do you think about this issue? > > Regards, > > Ludwig Seitz > > PS: Sorry for cross-posting this to CoRE, but I suspect we might get > some useful input from there. > > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelevägen 17 > SE-223 70 Lund > > Phone +46(0)70-349 92 51 > http://www.sics.se > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jan 22 00:12: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 203941A0271 for ; Thu, 22 Jan 2015 00:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcYqy_l7AqcN for ; Thu, 22 Jan 2015 00:12:01 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBC81A0278 for ; Thu, 22 Jan 2015 00:12:00 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-60-54c0b0cf7f21 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2C.04.24955.FC0B0C45; Thu, 22 Jan 2015 09:11:59 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.13]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 09:11:58 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "gerdes@tzi.de" Thread-Topic: [Ace] Role terminology in use case draft (Was: Container Use Case) Thread-Index: AQHQNW8OY2BIXPo9OU6z1ZDeRGr/mZzLy0+A Date: Thu, 22 Jan 2015 08:11:58 +0000 Message-ID: References: <54BF9029.4060200@tzi.de> In-Reply-To: <54BF9029.4060200@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <7A6D3170B8EE3A4B96C0DF62E9AD1C42@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rvf8hgMhBs3L+S2+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJUx82dlwTKnims/1rI0MJ5x6GLk5JAQMJFo n72eEcIWk7hwbz1bFyMXh5DAEUaJK+cuMkI4ixklXp3YzA5SxSbgIvGg4RETiC0ioCzR9ucz WDezgKLE7llnwWqEBQIlmg49ZoOoCZKY/6CbEcI2krg7+yQriM0ioCrxe9dssHpeAQuJ98fv AsU5gJaFSOzrcAUJcwqoSdz7/QisnBHouO+n1jBBrBKXuPVkPhPE0QISS/acZ4awRSVePv4H Vi8qoCex8noTG0RcSWLt4e0sIOOZBTQl1u/ShzCtJWZf5IM5fkr3Q6hjBCVOznzCMoFRYhaS ZbMQmmchNM9C0jwLSfMCRtZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIHRd3DLb9UdjJff OB5iFOBgVOLh/TD/QIgQa2JZcWXuIUZpDhYlcd48hw0hQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhgrLGvkGXUCE8+smq3Q2nnHiT+Jc7Fl0ddbuzyKm9apZDqteflvm3BHcVps0Z2PE6NN zm9UsJyy+9PiPpudDvWPO191X7gWmTbl7vFpG3Vevinf7dMSkJ9prxYapFX6dY9gB7fRxLPT bysavDI7u/o89wyTaRX3YiyP/JC/U+AUdDJG0Vz6g5cSS3FGoqEWc1FxIgCbFmi7nwIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 08:12:04 -0000 SGkgU3RlZmZpLA0KDQpPbiAyMDE1LTAxLTIxIDEyOjQwLCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2Vy ZGVzQHR6aS5kZT4gd3JvdGU6DQoNCj5IaSBHw7ZyYW4sDQo+DQo+SSBhZ3JlZSB0aGF0IHdlIHNo b3VsZCBsb29rIG92ZXIgdGhlIGNvcnJlY3QgdXNhZ2Ugb2YgdGhlIHRlcm1pbm9sb2d5DQo+Zm9y IHRoZSBuZXh0IHZlcnNpb24uIEJ1dCBhcyBJIHN0YXRlZCBiZWZvcmUsIEkgZmluZCBpdCBkaWZm aWN1bHQgdG8NCj5kZWZpbmUgaWYgYSBkZXZpY2UgaXMgYSBjbGllbnQgb3IgYSBzZXJ2ZXIuIE1h eWJlIGFuIGV4YW1wbGUgaGVscHM6DQo+DQo+SW4gdGhlIG1lZGljYWwgdXNlIGNhc2UgcGF0aWVu dHMgc2hvdWxkIGJlIGFibGUgdG8gY29udHJvbCB0aGUgYWNjZXNzDQo+cmlnaHRzIHRvIHRoZWly IGRhdGEgd2hpY2ggaW5kaWNhdGVzIHRoYXQgdGhlIHBhdGllbnQgc2hvdWxkIGJlIHRoZQ0KPnJl c291cmNlIG93bmVyLg0KDQpJbiANCmh0dHA6Ly9rYW50YXJhaW5pdGlhdGl2ZS5vcmcvY29uZmx1 ZW5jZS9kaXNwbGF5L3VtYS9VTUErVHJ1c3QrTW9kZWwrVXNlcitndQ0KaWRlDQp0aGVyZSBpcyBh IGhlYWx0aGNhcmUgc2NlbmFyaW8gd2hlcmUgdGhlIHBhdGllbnQgaXMgcmVzb3VyY2Ugb3duZXIN Cig9YXV0aG9yaXppbmcgcGFydHkpIGFuZCBzZXRzIGFjY2VzcyBwb2xpY2llcy4NCg0KDQoNCj5J ZiB0aGlzIGRhdGEgaXMgdHJhbnNtaXR0ZWQgdG8gdGhlIGRldmljZSBvZiB0aGVpcg0KPnByYWN0 aXRpb25lciwgdGhlcmUgYXJlIHR3byBwb3NzaWJsZSBzb2x1dGlvbnM6IGVpdGhlciB0aGUgcGF0 aWVudCdzDQo+bWVkaWNhbCBkZXZpY2UgaXMgdGhlIHNlcnZlciBhbmQgdGhlIHByYWN0aXRpb25l cidzIGRldmljZSBpcyB0aGUgY2xpZW50DQo+b3IgdGhlIHZpY2UgdmVyc2EuIEZvciBlaXRoZXIg Y2FzZSwgYm90aCB0aGUgcHJhY3RpdGlvbmVyIGFuZCB0aGUNCj5wYXRpZW50IHdpbGwgd2FudCB0 byBtYWtlIHN1cmUgdGhhdCB0aGUgdHJhbnNtaXR0ZWQgaW5mb3JtYXRpb24gaXMNCj50cmFuc21p dHRlZCBzZWN1cmVseS4NCg0KSSBkb27igJl0IHVuZGVyc3RhbmQgd2hhdCB0aGlzIGhhcyB0byBk byB3aXRoIHRoZSByb2xlIGFsbG9jYXRpb24uDQoNCj5JZiB0aGUgcHJhY3RpdGlvbmVyJ3MgZGV2 aWNlIGlzIHRoZSBzZXJ2ZXIsIHRoZQ0KPnBhdGllbnQncyBkZXZpY2Ugd2lsbCB3cml0ZSBkYXRh IHRvIHRoZSBwcmFjdGl0aW9uZXIncyByZXNvdXJjZSBhbmQgdGhlDQo+cHJhY3RpdGlvbmVyIHdp bGwgYmUgdGhlIHJlc291cmNlIG93bmVyLg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgZGV2 aWNlIG93bmVyc2hpcCBpbXBsaWVzIHJlc291cmNlIG93bmVyc2hpcC4gSQ0KdGhpbmsgcmVzb3Vy Y2Ugb3duZXJzaGlwIGlzIGEgbWF0dGVyIG9mIGxlZ2lzbGF0aW9uIGFuZCBhZ3JlZW1lbnRzLiBJ ZiBhDQpwYXRpZW50ICBzaWducyB1cCB3aXRoIGEgY2FyZWdpdmVyIG9yIHNvbWUgb3RoZXIgaGVh bHRoY2FyZSBzeXN0ZW0sIGl0IG1heQ0Kb3IgbWF5IG5vdCByZXRhaW4gaXRzIGFiaWxpdHkgdG8g c2V0IGFjY2VzcyBwb2xpY2llcyAoaS5lLiBiZSByZXNvdXJjZQ0Kb3duZXIpLiANCg0KSW4gU3dl ZGVuLCB0aGUgY2FyZWdpdmVyIHdpbGwgc2V0IGFjY2VzcyBwb2xpY2llcyBhbmQgYXMgYSBwYXRp ZW50IHlvdSBhcmUNCm5vdCBhbHdheXMgYW5kIGFsbCB0aGUgdGltZSBlbnRpdGxlZCB0byB5b3Vy IHJlY29yZHMgKG9yIHJlc2V0dGluZyB0aGUNCnBvbGljaWVzKS4gVGhpcyBtYXkgZGVwZW5kIG9u IHRoZSBtZW50YWwgY29uZGl0aW9uIG9mIHRoZSBwYXRpZW50LiBJdCBtYXkNCmFsc28gZGVwZW5k IG9uIHRoZSB0eXBlIG9mIG1lZGljYWwgZGF0YSwgZS5nLiBpZiBhIHJlY2VudCBleGFtaW5hdGlv bg0KaW5kaWNhdGUgdGhhdCB5b3UgbWF5IGhhdmUgYSBsZXRoYWwgZGlzZWFzZSwgeW91IG1heSBu b3QgYmUgYWJsZSB0byBsb29rDQp0aGF0IHVwIGJlZm9yZSB5b3UgaGF2ZSB0YWxrZWQgdG8geW91 ciBkb2N0b3IuDQoNCkJ1dCBpcnJlc3BlY3RpdmUgb2Ygd2hvIGlzIHJlc291cmNlIG93bmVyLCBj YXJlZ2l2ZXIgb3IgcGF0aWVudCwgdGhlDQpxdWVzdGlvbiBvZiBkZXZpY2Ugb3duZXJzaGlwIGlz IHNlcGFyYXRlLg0KDQoNCj4NCj5JIHNlZSBubyByZWFzb24gdG8gcHJvaGliaXQgZWl0aGVyIHZl cnNpb24gYW5kIHRodXMgSSBhbSBub3QgY29tZm9ydGFibGUNCj53aXRoIGFyYml0cmFyaWx5IHBp Y2tpbmcgb25lIG9mIHRoZW0uDQoNCkFnYWluLCBsb29rIGF0IHRoZSBleGFtcGxlIGZyb20gVU1B LiBXaHkgY2Fu4oCZdCB3ZSB1c2UgdGhhdCB0ZXJtaW5vbG9neT8NCkFsdGVybmF0aXZlIHRlcm1p bm9sb2d5IGlzIGluIHNlY3Rpb24gMi4xLjEgb2YNCmh0dHBzOi8vZG9jcy5rYW50YXJhaW5pdGlh dGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS10cnVzdC5odG1sDQoNCg0KDQpSZWdhcmRzLA0KR8O2cmFu DQoNCg0KDQoNCj4NCj5TdGVmZmkNCj4NCj4NCj5PbiAwMS8xNC8yMDE1IDExOjI1IEFNLCBHw7Zy YW4gU2VsYW5kZXIgd3JvdGU6DQo+Pg0KPj4gU29tZSBzcGVjaWZpYyBjb21tZW50czoNCj4+DQo+ PiBvIFUxLjEgUHJpbmNpcGFscyBzdWNoIGFzIHRoZSBmcnVpdCB2ZW5kb3IsIHRoZSB0cmFuc2xv YWRpbmcgcGVyc29ubmVsDQo+Pm9yDQo+PiB0aGUgY29udGFpbmVyIG93bmVycyB3YW50IHRvIGdy YW50IGRpZmZlcmVudCBhY2Nlc3MgcmlnaHRzIGZvciB0aGVpcg0KPj4gcmVzb3VyY2UgdG8gZGlm ZmVyZW50IHBhcnRpZXMgYW5kIHdhbnQgdG8gY29udHJvbCB3aGljaCBkZXZpY2VzIGFyZQ0KPj4g YWxsb3dlZCB0byBwcmVzZW50IGRhdGEgdG8gdGhlaXIgZGV2aWNlcy4NCj4+DQo+PiAtIElzIGZy dWl0IHZlbmRvciDCs3Jlc291cmNlIG93bmVywrIgb3IgwrNkZXZpY2Ugb3duZXLCsiBvciBib3Ro PyBUaGUgc2FtZQ0KPj4gcXVlc3Rpb24gZm9yIHRyYW5zbG9hZGluZyBwZXJzb25uZWwgYW5kIGNv bnRhaW5lciBvd25lci4NCj4+DQo+Pg0KPj4gwrNjb250cm9sIHdoaWNoIGRldmljZXMgYXJlIGFs bG93ZWQgdG8gcHJlc2VudCBkYXRhIHRvIHRoZWlyIGRldmljZXMiDQo+Pg0KPj4gLSBXaGF0IGRv ZXMgdGhpcyBjb3JyZXNwb25kIHRvIGluIHRoZSB1c2UgY2FzZT8NCj4+DQo+Pg0KPj4NCj4+IG8g VTEuMiBQcmluY2lwYWxzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9y IGRpZmZlcmVudA0KPj4gcmVzb3VyY2VzIG9uIGEgZGV2aWNlLg0KPj4NCj4+IC0gU2FtZSBxdWVz dGlvbiBhcyBhYm92ZSBhYm91dCB3aGF0IGlmIGRldmljZSBvd25lciBhbmQgcmVzb3VyY2Ugb3du ZXINCj4+c2V0DQo+PiBpbmNvbXBhdGlibGUgYWNjZXNzIHBvbGljaWVzPw0KPj4NCj4+DQo+Pg0K Pj4gbyBVMS4zIFRoZSBwcmluY2lwYWxzIHJlcXVpcmUgdGhlIGludGVncml0eSBvZiBzZW5zb3Ig ZGF0YS4NCj4+DQo+PiAtIEkgdW5kZXJzdGFuZCB0aGF0LCBmb3IgZXhhbXBsZSwgYSBjbGllbnQg cmVxdWlyZXMgaW50ZWdyaXR5IG9mIHNlbnNvcg0KPj4gZGF0YSwgYnV0IEkgZG9uwrl0IHVuZGVy c3RhbmQgd2h5IHRoaXMgd291bGQgYmUgYSByZXF1aXJlbWVudCBvZiBhDQo+PsKzZGV2aWNlDQo+ PiBvd25lcsKyDQo+Pg0KPj4NCj4+IG8gIFUxLjQgVGhlIHByaW5jaXBhbHMgcmVxdWlyZSB0aGUg Y29uZmlkZW50aWFsaXR5IG9mIHNlbnNvciBkYXRhLg0KPj4NCj4+IC0gSSB1bmRlcnN0YW5kIHRo YXQgdGhlIHJlc291cmNlIG93bmVyIHJlcXVpcmVzIGNvbmZpZGVudGlhbGl0eSBvZg0KPj5zZW5z b3INCj4+IGRhdGEsIGJ1dCBJIGRvbsK5dCB1bmRlcnN0YW5kIHdoeSB0aGlzIHdvdWxkIGJlIGEg cmVxdWlyZW1lbnQgb2YgYQ0KPj7Cs2RldmljZQ0KPj4gb3duZXLCsg0KPj4NCj4+DQo+Pg0KPj4g byAgVTMuMSBBIHByaW5jaXBhbCwgc3VjaCBhcyB0aGUgb3duZXIgb2YgYSBoZWFsdGggbW9uaXRv cmluZyBkZXZpY2UsDQo+PiB3YW50cyB0byBwcmUtY29uZmlndXJlIGFjY2VzcyByaWdodHMgdG8g c3BlY2lmaWMgZGF0YSBmb3IgcGVyc29ucyBvcg0KPj4gZ3JvdXBzLCBpbiB0aGUgY29udGV4dCBv ZiBhbiBlbWVyZ2VuY3kuDQo+Pg0KPj4gLSBUaGUgb3duZXIgb2YgYSBoZWFsdGggbW9uaXRvcmlu ZyBkZXZpY2UgbWF5IGJlIGEgcGF0aWVudCwgYSBjYXJlZ2l2ZXINCj4+IG9yZ2FuaXphdGlvbiBv ciBvdXRzb3VyY2VkIHRvIGEgdHJ1c3RlZCB0aGlyZCBwYXJ0eS4gSW5kZXBlbmRlbnRseSBvZg0K Pj53aG8NCj4+IG93bnMgdGhlIGRldmljZSwgdGhlIHJlc291cmNlIG93bmVyIHNob3VsZCBiZSBh YmxlIHRvIHNldCB0aGUgYWNjZXNzDQo+PiByaWdodHMuIFNvIEkgdGhpbmsgcHJpbmNpcGFsIHNo b3VsZCBiZSByZXBsYWNlZCBieSByZXNvdXJjZSBvd25lci4NCj4+DQo+Pg0KPj4NCj4+IG8gIFUz LjIgQSBwcmluY2lwYWwgd2FudHMgdG8gc2VsZWN0aXZlbHkgYWxsb3cgZGlmZmVyZW50IHBlcnNv bnMgb3INCj4+Z3JvdXBzDQo+PiB0byBhY2Nlc3MgbWVkaWNhbCBkYXRhLg0KPj4NCj4+IC0gQXMg YWJvdmUsIHByaW5jaXBhbCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCByZXNvdXJjZSBvd25lci4N Cj4+DQo+Pg0KPj4NCj4+IG8gIFU1LjEgRGV2aWNlcyBhcmUgaW5zdGFsbGVkIGluIGhvc3RpbGUg ZW52aXJvbm1lbnRzIHdoZXJlIHRoZXkgYXJlDQo+PiBwaHlzaWNhbGx5IGFjY2Vzc2libGUgYnkg YXR0YWNrZXJzLiAgUHJpbmNpcGFscyB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0DQo+PmFuDQo+PiBh dHRhY2tlciBjYW5ub3QgdXNlIGEgY2FwdHVyZWQgZGV2aWNlIHRvIGF0dGFjayBvdGhlciBwYXJ0 cyBvZiB0aGVpcg0KPj4gaW5mcmFzdHJ1Y3R1cmUuDQo+Pg0KPj4gLSBJIHNlZSB0aGlzIHByaW1h cmlseSBhcyBhIGNvbmNlcm4gb2YgdGhlIG93bmVyIG9mIHRoZSBpbmZyYXN0cnVjdHVyZSwNCj4+ IG5vdCBhIGNvbmNlcm4gb2YgYSByZXNvdXJjZSBvd25lci4gT2YgY291cnNlLCBpZiB0aGUgaW5m cmFzdHJ1Y3R1cmUgaXMNCj4+IGF0dGFja2VkIHRoZSByZXNvdXJjZSBvd25lciBtYXkgYmUgaW5m bGljdGVkLCBidXQgcHJldmVudGluZyB0aGlzIGtpbmQNCj4+b2YNCj4+IGF0dGFjayBpcyBub3Ro aW5nIGFuIGVudGl0eSBpbiB0aGUgcm9sZSBvZiByZXNvdXJjZSBvd25lciBjYW4gwrNtYWtlDQo+ PnN1cmXCsi4NCj4+IFNvIEkgcHJvcG9zZSB0byByZXBsYWNlIHRoZSB0ZXJtIHByaW5jaXBhbC4N Cj4+DQo+Pg0KPj4NCj4+IG8gIFU1LjIgUHJpbmNpcGFscyB3YW50IHRvIHJlc3RyaWN0IHdoaWNo IGVudGl0aWVzIGFyZSBhbGxvd2VkIHRvIHdyaXRlDQo+PiBkYXRhIHRvIHRoZSBkZXZpY2VzIGFu ZCB0aHVzIGVuc3VyZSB0aGUgaW50ZWdyaXR5IG9mIHRoZSBkYXRhIG9uIHRoZWlyDQo+PiBkZXZp Y2VzLg0KPj4NCj4+IC0gSSBhZ3JlZSB0aGF0IGFjY2VzcyBjb250cm9sIHRvIGFuZCBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiBvZiB1dGlsaXR5DQo+PmRhdGENCj4+IGlzIGEgcmVsZXZhbnQgcHJvYmxl bSBzdGF0ZW1lbnQgY2FuIGJlIGRlZHVjZWQgZnJvbSB0aGlzIHVzZSBjYXNlLCBidXQgSQ0KPj4g ZmluZCB0aGlzIGZvcm11bGF0aW9uIHNvbWV3aGF0IGNvbmZ1c2luZy4gSW4gdGhlIGNhc2UgwrNw cmluY2lwYWzCsiBtZWFucw0KPj4gwrNyZXNvdXJjZSBvd25lciIsIHRoZSBmb3JtdWxhdGlvbiDC s3dyaXRlIGRhdGEgdG8gdGhlIGRldmljZXPCsiBvcg0KPj4gwrNpbnRlZ3JpdHkgb2YgdGhlIGRh dGEgb24gdGhlaXIgZGV2aWNlc8KyIGRvZXMgbm90IG1ha2Ugc2Vuc2U7IHRoZQ0KPj5yZXNvdXJj ZQ0KPj4gb3duZXIgZG9lcyBub3QgbmVjZXNzYXJpbHkgb3duIGFueSBkZXZpY2VzIGFuZCDCs2Rh dGEgb24gZGV2aWNlcyIgd291bGQNCj4+IGJldHRlciBiZSBmb3JtdWxhdGVkIGluIHRlcm1zIG9m ICJyZXNvdXJjZSByZXByZXNlbnRhdGlvbnPCsiBvciBzaW1pbGFyLg0KPj4NCj4+DQo+Pg0KPj4g byAgVTUuNyBNZXNzYWdlcyBiZXR3ZWVuIGEgY2xpZW50IGFuZCB0aGUgZGV2aWNlIG1heSBuZWVk IHRvIGJlIHN0b3JlZA0KPj5hbmQNCj4+IGZvcndhcmRlZCBvdmVyIG11bHRpcGxlIG5vZGVzLgkJ DQo+PiAJDQo+PiAtIEkgdGhpbmsgwrNkZXZpY2XCsiBzaG91bGQgYmUgcmVwbGFjZWQgYnkgwrNy ZXNvdXJjZSBzZXJ2ZXLCsi4gVGhlDQo+PmRpZmZlcmVuY2UNCj4+IGJldHdlZW4gImRldmljZSIg YW5kIMKzbm9kZcKyIGlzIG5vdCBjbGVhci4NCj4+DQo+Pg0KPj4NCj4NCg0K From nobody Thu Jan 22 01:04:26 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314C1A1DBC for ; Thu, 22 Jan 2015 01:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92tHnASFK7Q1 for ; Thu, 22 Jan 2015 01:04:20 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 39C8D1A01AA for ; Thu, 22 Jan 2015 01:04:20 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 7D0E8EDD4 for ; Thu, 22 Jan 2015 10:04:19 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t0M94IK9010287 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 Jan 2015 10:04:18 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 87C0538D for ; Thu, 22 Jan 2015 10:04:18 +0100 (CET) Message-ID: <54C0BD0A.4060806@sics.se> Date: Thu, 22 Jan 2015 10:04:10 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ace@ietf.org References: <54BF8185.9090609@sics.se> <54BFB249.1060000@sics.se> <0b817fa68ac001f46f044508eafe521e.squirrel@mail2.ihtfp.org> In-Reply-To: <0b817fa68ac001f46f044508eafe521e.squirrel@mail2.ihtfp.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040400070909080701000801" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NGV4i1r - 8bf1e71b1cd1 - 20150122 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NGV4i1r&m=8bf1e71b1cd1&t=20150122&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NGV4i1r&m=8bf1e71b1cd1&t=20150122&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NGV4i1r&m=8bf1e71b1cd1&t=20150122&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] Unique resource identifiers X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 09:04:24 -0000 This is a cryptographically signed message in MIME format. --------------ms040400070909080701000801 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 01/21/2015 03:27 PM, Derek Atkins wrote: > Sounds like you are trying to re-invent HIP. (See RFC 5201 and RFC 442= 3) > > -derek > > Thank you Derek, but I'm actually not so much interested in the host=20 identity, what I need in order to do access control is a stable resource = identifier. It seems to me that in certain cases Uri-host + Uri-path=20 isn't as stable as one would like. So perhaps it would be useful to first discuss if we agree that there is = a problem. If so, we can start looking if there already is a solution or = if we need to find one ourselves. /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 --------------ms040400070909080701000801 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 KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAxMjIwOTA0MTBaMCMGCSqGSIb3DQEJBDEW BBR5iTZC4rRvLGfmesrVm0eB7LBjJTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAC+uDSXGZ3KKpDUf480N6SBzadGf1pmEeWqYqGIQVRrn9VCox15ZPfqCwCdlIxAQEk6a1 w9SIwhaKiyRLlPdSc1nBM18B2W0Lxy2WfF5r4cIZMcw3d8JW5PXNpVQ92RE8NLCzbv+o10nB Ve6214xa5KoDaJVerKAUdYMfPfThHAV1Uj6jlO3LDkxEf78w0lH4g0WJm1EotlI4IIHwCj17 1ysmBmj5hK2Smxykcpk7PWuop+pn4nl+/c9A/oyGpNWOKlY+0rcNBqZ6CQ3tRaYFyeXSb/Yt C8FM5Kcx17hQQnMIGa6RXorMiRFTps2gnI0G/u+g6ofSrFVjg3EDFw3rqgAAAAAAAA== --------------ms040400070909080701000801-- From nobody Thu Jan 22 03:15: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 A6AFD1ACC8B for ; Thu, 22 Jan 2015 03:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 gftYVR9Tu8aZ for ; Thu, 22 Jan 2015 03:14:51 -0800 (PST) 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 AC08A1ACC89 for ; Thu, 22 Jan 2015 03:14:47 -0800 (PST) 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 t0MBEhBZ028232; Thu, 22 Jan 2015 12:14:43 +0100 (CET) Received: from aung.tzi.org (p57A63FB4.dip0.t-ipconnect.de [87.166.63.180]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kSgwz3yNZz83m5; Thu, 22 Jan 2015 12:14:43 +0100 (CET) From: Olaf Bergmann To: Ludwig Seitz References: <54BF8185.9090609@sics.se> <54BFB249.1060000@sics.se> <0b817fa68ac001f46f044508eafe521e.squirrel@mail2.ihtfp.org> <54C0BD0A.4060806@sics.se> Date: Thu, 22 Jan 2015 12:14:43 +0100 In-Reply-To: <54C0BD0A.4060806@sics.se> (Ludwig Seitz's message of "Thu, 22 Jan 2015 10:04:10 +0100") Message-ID: <87sif3ysm4.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Unique resource identifiers X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 11:14:55 -0000 Ludwig Seitz writes: > On 01/21/2015 03:27 PM, Derek Atkins wrote: >> Sounds like you are trying to re-invent HIP. (See RFC 5201 and RFC 4423) >> >> -derek >> >> > Thank you Derek, but I'm actually not so much interested in the host > identity, what I need in order to do access control is a stable > resource identifier. It seems to me that in certain cases Uri-host + > Uri-path isn't as stable as one would like. The path components of URIs should be stable in the REST world, don't they? Isn't this an important aspect of URIs. [0] However, if you really feel addressing content objects "on the wire", you should have a look into the ICN work going on the IRTF, but I think this is not on the short-term agenda for ACE, right? [0] http://www.w3.org/Provider/Style/URI.html Gr=C3=BC=C3=9Fe Olaf From nobody Thu Jan 22 04:16:23 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 229651A1A1D for ; Thu, 22 Jan 2015 04:16:21 -0800 (PST) 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 xLf2RVb6Ow9S for ; Thu, 22 Jan 2015 04:16:19 -0800 (PST) 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 EA51D1ACC85 for ; Thu, 22 Jan 2015 04:16:18 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-1a-54c0ea10e730 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.53.04484.01AE0C45; Thu, 22 Jan 2015 13:16:17 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.13]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 13:16:16 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "gerdes@tzi.de" Thread-Topic: [Ace] Role terminology in use case draft (Was: Container Use Case) Thread-Index: AQHQMN8Es9WispTBHE234PMCuF7ah5zHKgUAgANBZoCAAa1GgA== Date: Thu, 22 Jan 2015 12:16:15 +0000 Message-ID: References: <54B7E75F.20808@tzi.de> <54BF9005.1050605@tzi.de> In-Reply-To: <54BF9005.1050605@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <6985A4C126B06345BFC73CDCBCEF61FE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvja7gqwMhBvtnMlt8/9bDbLHx4l1G ByaPJUt+Mnlse/uVOYApissmJTUnsyy1SN8ugStj15KzrAVPFCu6jxxibmD8otDFyMEhIWAi 0bohuYuRE8gUk7hwbz1bFyMXh5DAEUaJN3MWMkE4ixkljp9fwAZSxSbgIvGg4RETiC0ioCzR 9uczI4jNLKAosXvWWXYQW1ggUKLp0GM2iJogifkPuhkhbCeJ782XwGpYBFQlpu54CVbDK2Ah 0bl5C9Tm2YwSLce/gy3gFFCTuLhpA1gzI9B530+tYYJYJi5x68l8JoizBSSW7DnPDGGLSrx8 /I8VxBYV0JNYeb2JDSKuJLFi+yVGkI+ZBTQl1u/ShxhjLTGh9RPc/VO6H7JD3CMocXLmE5YJ jBKzkGybhdA9C0n3LCTds5B0L2BkXcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGIUHt/w2 2MH48rnjIUYBDkYlHt4P8w+ECLEmlhVX5h5ilOZgURLnzXPYECIkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBsfDaH+Pv1vKXSrzVl5efnrNT3m/Z5VUrPgjN2CIh9H6ux+nWNqeZX+K0WE+Y tSau95/iWevqI7pnV8GJQxOPOfz49V9Dpr5Cxvhvb8S/aY/W3z5w4t/qzzdnnHlfwy/VYaD5 49ZtLtk6ydXlbXYS95SjdyyUeGx+2ezTsWfLmJtmTrDddEpYd6ISS3FGoqEWc1FxIgCe+QEU owIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 12:16:21 -0000 SGkgU3RlZmZpLA0KDQpPbiAyMDE1LTAxLTIxIDEyOjM5LCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2Vy ZGVzQHR6aS5kZT4gd3JvdGU6DQoNCj5IaSBHw7ZyYW4sDQo+DQo+T24gMDEvMTkvMjAxNSAwOTo1 NiBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4NCj4+IFtHU10gSeKAmW0gbm90IHN1cmUg SSB1bmRlcnN0YW5kIOKAnHRlcm1pbm9sb2d5IG9mIGEgc3BlY2lmaWMgc29sdXRpb27igJ0uIEkN Cj4+IHRoaW5rIHdlIGFsbCBhZ3JlZSB0aGF0IHdlIGFyZSBhc3N1bWluZyBzb21ldGhpbmcgbGlr ZSBSRVNULCB0aGF0IHRoZXJlDQo+PiBhcmUgcmVzb3VyY2VzLCByZXF1ZXN0cyBhbmQgcmVzcG9u c2VzLiBUaGVuIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUNCj4+ZW50aXR5DQo+PiB0aGF0IHJlcXVl c3RzIGFuZCBzb21lIHRoZSByZXNwb25kcyBldGMuIEFuZCB0aGVuIHdlIGNhbiBmb3JtdWxhdGUg dGhlDQo+PiBhdXRob3JpemF0aW9uIHByb2JsZW1zIGluIHRlcm1zIG9mIHRoZXNlIG5hbWVzLiBX aHkgaXMgdGhlcmUgYXJlIHByb2JsZW0NCj4+IHNlcGFyYXRpbmcgYXV0aG9yaXphdGlvbiBwcm9i bGVtcyBvbiB0aGUgcmVxdWVzdGluZyBzaWRlIGZyb20gdGhvc2Ugb24NCj4+dGhlDQo+PiByZXNw b25kaW5nIHNpZGU/DQo+DQo+QmVjYXVzZSB3ZSBkb24ndCBrbm93IGluIHRoZSB1c2UgY2FzZXMg d2hpY2ggc2lkZSBpcyB0aGUgcmVxdWVzdGluZyBzaWRlDQo+KHRoZSBDb0FQIGNsaWVudCkgYW5k IHdoaWNoIG9uZSBpcyB0aGUgcmVzcG9uZGluZyAodGhlIENvQVAgc2VydmVyKS4gSWYNCj50aGVy ZSBhcmUgZ29vZCByZWFzb25zIHRvIHNheSB3aGljaCBvbmUgaXMgd2hpY2gsIHdlIHNob3VsZCBw b2ludCB0aGlzDQo+b3V0IGluIHRoZSB1c2UgY2FzZXMgYW5kIHVzZSB0aGUgcmVzcGVjdGl2ZSB0 ZXJtaW5vbG9neS4NCj4NCj5JIHRoaW5rIHRoYXQgaW4gdGhlIG1vc3QgY2FzZXMgdGhpcyB3aWxs IG5vdCBiZSBwb3NzaWJsZSBhcyB0aGVyZSBtaWdodA0KPmJlIHJlYXNvbnMgZm9yIGVhY2ggc2V0 dGluZy4gTW9yZW92ZXIsIGEgc2luZ2xlIGRldmljZSB3aWxsIGF0IG9uZSB0aW1lDQo+YWN0IGFz IHRoZSBzZXJ2ZXIgd2hpbGUgbGF0ZXIgb24gaXQgd2lsbCBhY3QgYXMgdGhlIGNsaWVudC4NCj4N Cj5JZiB5b3UgaGF2ZSBpZGVhcyBob3cgdG8gc29sdmUgdGhpcywgcGxlYXNlIHByb3ZpZGUgdGV4 dC4NCg0KQXMgbWVudGlvbmVkLCBJIHByb3Bvc2Ugd2UgdXNlIGFuIGV4aXN0aW5nIHRlcm1pbm9s b2d5IHN1Y2ggYXMgT0F1dGggb3INCnNlY3Rpb24gMi4xLjEgb2YNCmh0dHBzOi8vZG9jcy5rYW50 YXJhaW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS10cnVzdC5odG1sIGFuZCByZXBsYWNlDQp0 aGUgdGVybXMgInByaW5jaXBhbOKAnSBhbmQg4oCcZGV2aWNl4oCdIHdpdGggdGVybXMgbGlrZSDi gJxyZXNvdXJjZSBvd25lcuKAnSBvcg0KInJlc291cmNlIHNlcnZlciIgb3Igd2hhdGV2ZXIgaXMg YXBwcm9wcmlhdGUuIEZvciBleGFtcGxlcyBvZiBob3cgdGhlIHRleHQNCndvdWxkIGNoYW5nZSwg cGxlYXNlIHNlZSBteSBkZXRhaWxlZCBjb21tZW50cyBvbiB0aGUgYXV0aG9yaXphdGlvbg0KcHJv YmxlbXMgYXQgdGhlIGVuZCBvZiB0aGUgcHJldmlvdXMgbWFpbC4NCg0KDQpJIGNhbiBkbyB0aGlz IGV4ZXJjaXNlLCBidXQgcGxlYXNlIGZpcnN0IHJlcGx5IHRvIG15IGNvbW1lbnRzIHNvIEkga25v dw0KdGhhdCB3ZSBhZ3JlZSBvbiB0aGlzLg0KDQo+DQo+DQo+PiBbR1NdIE9LLCBsZXTigJlzIHNl ZSBpZiBJIHVuZGVyc3RhbmQuIFNvIOKAnERldmljZSIgbWF5IG1lYW4gIkNsaWVudOKAnSBvcg0K Pj4g4oCcUmVzb3VyY2UgU2VydmVy4oCdLiBIZW5jZSDigJxEZXZpY2UgT3duZXLigJ0gbWF5IG1l YW4g4oCcQ2xpZW50IE93bmVy4oCdIG9yDQo+PiDigJxSZXNvdXJjZSBTZXJ2ZXIgT3duZXLigJ0u IFByaW5jaXBhbCB0aHVzIG1heSBtZWFuICJDbGllbnQgT3duZXLigJ0gb3INCj4+IOKAnFJlc291 cmNlIE93bmVy4oCdIG9yIOKAnFJlc291cmNlIFNlcnZlciBPd25lcuKAnS4gSXMgdGhhdCBjb3Jy ZWN0Pw0KPj4NCj4+IE5vdywgbW9zdCBBdXRob3JpemF0aW9uIFByb2JsZW1zIGluIHRoZSB1c2Ug Y2FzZSBkcmFmdCBhcmUgZm9ybXVsYXRlZCBpbg0KPj4gdGVybXMgb2Yg4oCcUHJpbmNpcGFs4oCd LiBUaGUgdGVybXMgIkNsaWVudCBPd25lcuKAnSBhbmQgIlJlc291cmNlIFNlcnZlcg0KPj5Pd25l cuKAnQ0KPj4gYXJlIGV2ZW4gbWlzc2luZyBmcm9tIHRoZSB0ZXJtaW5vbG9neS4gU2luY2UgbW9z dCBBdXRob3JpemF0aW9uIFByb2JsZW1zDQo+PiBhcmUgZm9ybXVsYXRlZCBpbiB0ZXJtcyBvZiDi gJxQcmluY2lwYWwiIGl0IGJsdXJzIGFueSBkaXN0aW5jdGlvbiBiZXR3ZWVuDQo+PiDigJxDbGll bnQgT3duZXLigJ0sIOKAnFJlc291cmNlIFNlcnZlciBPd25lcuKAnSBhbmQg4oCcUmVzb3VyY2Ug T3duZXLigJ0gYW5kIHlvdQ0KPj5jYW7igJl0DQo+PiBldmVuIGV4cHJlc3MgYW55IHNwZWNpZmlj IGFzcGVjdHMgb2YgdGhlc2UgYmVjYXVzZSBvZiBtaXNzaW5nDQo+PnRlcm1pbm9sb2d5Lg0KPj4g U28gdGhlIGNob2ljZSBvZiB0ZXJtaW5vbG9neSBpcyBhY3R1YWxseSBoaWRpbmcgYW55IHBvdGVu dGlhbA0KPj5kaWZmZXJlbmNlcw0KPj4gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCByZXNvdXJjZSBz aWRlLg0KPj4NCj4NCj5XZSBjYW4gYWRkIHRoZSB0ZXJtcyAiQ2xpZW50IE93bmVyIiBhbmQgIlJl c291cmNlIFNlcnZlciBPd25lciIgdG8gdGhlDQo+dGVybWlub2xvZ3kgaWYgdGhhdCBoZWxwcyB0 aGluZ3MuDQoNCkkgdGhpbmsgd2hhdCB3b3VsZCBoZWxwIGlzIGlmIHdlIGZpcnN0IGV4cHJlc3Mg d2hhdCBhcmUgdGhlIGF1dGhvcml6YXRpb24NCnByb2JsZW1zIGluIHRlcm1zIG9mIGUuZy4g4oCc Q2xpZW50IE93bmVy4oCdIChpbiBhIGdpdmVuIG1vZGVsKSBpbnN0ZWFkIG9mDQpleHByZXNzaW5n IHRoZW0gaW4gdGVybXMgb2YgIOKAnGRldmljZSBvd25lcuKAnSAod2hpY2ggZ2l2ZXMgdGhlIGlt cHJlc3Npb24NCnRoYXQgdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbXMgYXJlIGlkZW50aWNhbCBv biB0aGUgY2xpZW50IGFuZCByZXNvdXJjZQ0Kc2lkZSkuDQoNClRoYW5rcw0KR8O2cmFuDQoNCj4N Cj5UaGFua3MsDQo+U3RlZmZpDQoNCg== From nobody Thu Jan 22 04:28: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 BE7931ACC8B for ; Thu, 22 Jan 2015 04:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g-zEZc85sEE for ; Thu, 22 Jan 2015 04:28:30 -0800 (PST) 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 ADDE21ACC89 for ; Thu, 22 Jan 2015 04:28:29 -0800 (PST) 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 t0MCSO7K017277; Thu, 22 Jan 2015 13:28:24 +0100 (CET) Received: from aung.tzi.org (p57A63FB4.dip0.t-ipconnect.de [87.166.63.180]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kSjZ050mwz83Vk; Thu, 22 Jan 2015 13:28:24 +0100 (CET) From: Olaf Bergmann To: =?utf-8?Q?G=C3=B6ran?= Selander References: <54B7E75F.20808@tzi.de> <54BF9005.1050605@tzi.de> Date: Thu, 22 Jan 2015 13:28:24 +0100 In-Reply-To: (=?utf-8?Q?=22G?= =?utf-8?Q?=C3=B6ran?= Selander"'s message of "Thu, 22 Jan 2015 12:16:15 +0000") Message-ID: <87y4ovxamv.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "gerdes@tzi.de" , "Ace@ietf.org" Subject: Re: [Ace] Role terminology in 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: Thu, 22 Jan 2015 12:28:30 -0000 G=C3=B6ran Selander writes: > I think what would help is if we first express what are the authorization > problems in terms of e.g. =E2=80=9CClient Owner=E2=80=9D (in a given mode= l) instead of > expressing them in terms of =E2=80=9Cdevice owner=E2=80=9D (which gives = the impression > that the authorization problems are identical on the client and resource > side). There is an excellent I-D with well-defined terminology for this, see [0]. [0] https://tools.ietf.org/html/draft-gerdes-ace-actors Best regards Olaf From nobody Fri Jan 23 03:11:49 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 DD02F1A9091 for ; Fri, 23 Jan 2015 03:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpf2VDna_o2E for ; Fri, 23 Jan 2015 03:11:45 -0800 (PST) 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 A700A1A9078 for ; Fri, 23 Jan 2015 03:11:41 -0800 (PST) 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 t0NBBYC8023617; Fri, 23 Jan 2015 12:11:34 +0100 (CET) Received: from [IPv6:2001:638:708:30da:194b:911a:d0b1:794d] (unknown [IPv6:2001:638:708:30da:194b:911a:d0b1:794d]) (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 3kTHps3BRPz83JG; Fri, 23 Jan 2015 12:11:33 +0100 (CET) Message-ID: <54C22C2C.9050709@tzi.de> Date: Fri, 23 Jan 2015 12:10:36 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <54BF9029.4060200@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 11:11:47 -0000 Hi Göran, Thank you for your comments. On 01/22/2015 09:11 AM, Göran Selander wrote: > On 2015-01-21 12:40, "Stefanie Gerdes" wrote: >> If the practitioner's device is the server, the >> patient's device will write data to the practitioner's resource and the >> practitioner will be the resource owner. > I don’t understand why device ownership implies resource ownership. I > think resource ownership is a matter of legislation and agreements. If a > patient signs up with a caregiver or some other healthcare system, it may > or may not retain its ability to set access policies (i.e. be resource > owner). > > In Sweden, the caregiver will set access policies and as a patient you are > not always and all the time entitled to your records (or resetting the > policies). This may depend on the mental condition of the patient. It may > also depend on the type of medical data, e.g. if a recent examination > indicate that you may have a lethal disease, you may not be able to look > that up before you have talked to your doctor. > > But irrespective of who is resource owner, caregiver or patient, the > question of device ownership is separate. Yes, I agree that we should not use the term "device owner" if we are not sure that the device owner is in control of the access permissions. We should change this with the next version. Nevertheless, you seem to assume that it is clear who the resource owner (the one that controls the access policies for a resource) is in a scenario. But it depends on the concrete solution which one of the parties is the resource owner in a given scenario. Moreover, in a scenario where two different parties may be involved, one that requests a representation of the resource and one that provides the resource representation, these two parties may have different interests and thus have different problems that need to be solved by an authorization solution. Thus, the resource owner's problems are not the only problems we need to consider. For CoAP, the entity that controls the access permissions to a CoAP resource will likely be the resource owner, and thus the owner of the data that is stored there. If you are transmitting data to that resource, you are the resource owner as long as you control the access permissions for this resource. If you are transmitting data to someone else's CoAP resource you are giving up ownership for this copy of the data. If you want to make sure that the owner of the data never changes you will have to make sure that the resource owner can control the access permissions for this data on all devices where the data is transmitted to. Even if data is transmitted to a requesting client you are giving up ownership for the copy of the data that you are transmitting, unless you can control access policies for the data on the client. You may control your own copy of the data, but not the client's copy. I don't think it's so clear that the patient is always the resource owner in a healthcare scenario. Let's assume that in the personal health monitoring case, a practitioner receives data from John's heart rate monitor with her smartphone. John is the owner of the heart rate information while it is on the heart rate monitor. He wants to control who is able to access this data. But I think it is unlikely that the practitioner will let John configure access policies for data on her device. She gains ownership for her copy of John's data since she is the one that controls the access policies. You may say that you only want to solve John's problem, i.e. protecting his medical data. But then you are not considering the practitioner's interest. She will want to be sure that only authorized data is transmitted to her smartphone. If you want to use CoAP for the transmission of the data, it is not even clear which device will be the client and which will be the server. It might be useful if the heart rate monitor is the server and the smartphone is the client that requests data. But it might also be useful if the heart rate monitor is the client. I don't see a good reason to rule out one of these settings. I guess it is not possible to reduce all authorization problems in the use cases to the protection of resources (unless we say that we have resources on both sides which will result in having two resource owners). Thus it is not sufficient to only list the resource owner's problems. The use cases must also reflect the problems of the other involved party, regardless of how you name this one (I think your suggestion was client owner). Since we don't know yet which solution we will use, it might be more useful to only use CoAP terminology: * Endpoint: An entity participating in the CoAP protocol. Colloquially, an endpoint lives on a "Node", although "Host" would be more consistent with Internet standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port number and a security association * Client: The originating endpoint of a request; the destination endpoint of a response. * Server: The destination endpoint of a request; the originating endpoint of a response And in addition (to be able to address the owner's interest): * Resource Principal: The subject that controls the access permissions for a resource. (several people remarked that the term "owner" is misleading) * Client Principal: The subject that controls the access permissions for a client. * Principal: A subject that is either a resource owner or a client owner or both. It might also be helpful to add this to the terminology: * Resource: An item of interest Best regards, Steffi From nobody Mon Jan 26 00:28:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2C11A8741 for ; Mon, 26 Jan 2015 00:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLYvWaZ7Lnqq for ; Mon, 26 Jan 2015 00:27:58 -0800 (PST) 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 806AB1A8746 for ; Mon, 26 Jan 2015 00:27:57 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-ee-54c5fa8b06e8 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2B.13.04076.B8AF5C45; Mon, 26 Jan 2015 09:27:55 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.13]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 09:27:55 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "gerdes@tzi.de" Thread-Topic: [Ace] Role terminology in use case draft (Was: Container Use Case) Thread-Index: AQHQNW8OY2BIXPo9OU6z1ZDeRGr/mZzLy0+AgAGzfACABJpLgA== Date: Mon, 26 Jan 2015 08:27:54 +0000 Message-ID: References: <54BF9029.4060200@tzi.de> <54C22C2C.9050709@tzi.de> In-Reply-To: <54C22C2C.9050709@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+JvjW73r6MhBtvOaFh8/9bDbLHx4l1G ByaPJUt+Mnlse/uVOYApissmJTUnsyy1SN8ugStj/27Nghm1FVd+LGBtYPxT2cXIySEhYCKx 5OoLVghbTOLCvfVsXYxcHEICRxglPu1bwwLhLGaUeLa6gx2kik3AReJBwyMmEFtEQFmi7c9n RhCbWUBRYvess2A1wgKBEk2HHrNB1ARJzH/QzQhhO0k8fXIGbBuLgKrEvW0XmUFsXgELiQ3n JkMtm8so0X1gCVgRp4CaRO/f5WBFjEDnfT+1hglimbjErSfzmSDOFpBYsuc8M4QtKvHy8T+w XlEBPYmV15vYIOJKEotufwaq5wDq1ZRYv0sfYoy1xNSXN9lh7p/S/ZAd4h5BiZMzn7BMYJSY hWTbLITuWUi6ZyHpnoWkewEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwCg8uOW31Q7G g88dDzEKcDAq8fBuWHs0RIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjJLb2nJK2NK8anf6/1//XoTbaevl/7WOT7TqdJ/f8EpoKbl788aBD4+s9QXW+a0o Xcl11K/g7pOXqfMUj7P7py0IjT5i4JCoqzE5ROfd4tmStyN8QxXsWOamlv7mYXk5S/vvNVb/ GYf8Ou75VjFPctO7ti/B1+QA37rbZk03eJZUqgjvENxtpsRSnJFoqMVcVJwIAO2ygP2jAgAA Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 08:28:01 -0000 SGkgU3RlZmZpLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcGF0aWVudCBleHBsYW5hdGlvbnMuIEkg YW0gaGFwcHkgdGhhdCB3ZSBhZ3JlZSB0byBsZWF2ZQ0Kb3V0IGRldmljZSBvd25lcnNoaXAuDQoN ClJlZ2FyZGluZyB0aGUgcmVtYWluaW5nIGFyZ3VtZW50YXRpb24gSeKAmW0gc2FkIHRvIHNheSB0 aGF0IEnigJltIHN0aWxsIG5vdA0KY29udmluY2VkLiBJbiBzaG9ydDogSSB0aGluayB3ZSBzaG91 bGQgaGF2ZSBhIHRlcm1pbm9sb2d5IGluIHRoZSB1c2UgY2FzZQ0KZG9jdW1lbnQgd2hpY2ggYWxs b3cgdXMgdG8gZXhwcmVzcyB0aGUgY29uY3JldGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBvZg0K dGhlIHVzZSBjYXNlcyBpbiB0ZXJtcyBvZiB0aGlzIHRlcm1pbm9sb2d5LiBJZiBJIHVuZGVyc3Rh bmQgeW91IHJpZ2h0LCB5b3UNCnNheSB0aGF0IHdlIGNhbuKAmXQgZXhwcmVzcyB0aGUgYXV0aG9y aXphdGlvbiBwcm9ibGVtcyBpbiB0ZXJtcyBvZiBSZXNvdXJjZSwNClJlc291cmNlIE93bmVyICg9 IFJlc291cmNlIFByaW5jaXBhbCksIGV0Yy4gYmVjYXVzZSB3aG8gaXMgUmVzb3VyY2UgT3duZXIN Cm1heSBkZXBlbmQgb24gc29sdXRpb24uIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZW4gSSB0aGlu ayB3ZSBoYXZlIGENCnByb2JsZW0uIEluIG15IG9waW5pb24sIGVpdGhlciB0aGUgdGVybWlub2xv Z3kgaXMgbm90IGFwcHJvcHJpYXRlLCBvcg0KdGhlcmUgaXMgc29tZSBwcm9ibGVtIHdpdGggdGhl IGFwcGxpY2F0aW9uIG9mIHRoZSB0ZXJtaW5vbG9neSB0byB0aGUgdXNlDQpjYXNlcy4NCg0KVG8g ZWxpbWluYXRlIHRoZSBmb3JtZXIsIGFsbG93IG1lIHRvIHRha2UgYSBzdGVwIGJhY2sgYW5kIGF0 dGVtcHQgYQ0KcHJlbGltaW5hcnkgdGVybWlub2xvZ3kgdG8gcmVhY2ggYSBjb21tb24gZ3JvdW5k IG9mIHVuZGVyc3RhbmRpbmcuIExldCBtZQ0Ka25vdyB0byB3aGF0IGV4dGVudCB3ZSBjYW4gYWdy ZWUgb24gdGhpczoNCg0KSW4gdGhlIHVzZSBjYXNlcyB3ZSBmb2N1cyBvbiDigJx0aGluZ3MiIGxp a2Ugc2Vuc29ycyAodGVtcGVyYXR1cmUgc2Vuc29ycywNCmhlYXJ0IHJhdGUgc2Vuc29ycyBldGMu KSBhbmQgYWN0dWF0b3JzIChmYW4gYWN0dWF0b3JzLCBsb2NrIGFjdHVhdG9ycw0KZXRjLik7IGFu ZCByZWxhdGVkIGRhdGEgbGlrZSBzZW5zb3IgbWVhc3VyZW1lbnRzICh0ZW1wZXJhdHVyZXMsIGhl YXJ0DQpyYXRlcywgZXRjLikgYW5kIGFjdHVhdG9yIHNldHRpbmdzIChmYW4gY29uZmlndXJhdGlv biBzZXR0aW5ncywgbG9jaw0Kb3Blbi9jbG9zZWQsIGV0Yy4gKS4gQWxsIHRoZXNlIGFyZSAiaXRl bXMgb2YgaW50ZXJlc3QiLCBvciAiYXNzZXRzIiB0aGF0DQpuZWVkcyB0byBiZSBwcm90ZWN0ZWQs IHNvbWUgb2Ygd2hpY2ggaXMgaW4gc2NvcGUgb2YgdGhpcyB3b3JraW5nIGdyb3VwLg0KDQpJbiBv cmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSBwYXJ0eSBwcm92aWRpbmcgYSBzZW5zb3Iv YWN0dWF0b3INCnNlcnZpY2UgYW5kIHRoZSBwYXJ0eSB1c2luZyB0aGUgc2VydmljZSB3ZSBjYW4g dXNlIHRoZSB0ZXJtaW5vbG9neQ0K4oCccHJvdmlkZXLigJ0gKG9mIHNlbnNvci9hY3R1YXRvciBz ZXJ2aWNlcykgYW5kIOKAnHVzZXLigJ0gKG9mIHNlbnNvci9hY3R1YXRvcg0Kc2VydmljZXMpLiBP bmUgaW1wb3J0YW50IHNlY3VyaXR5IHByb2JsZW0gaW4gc2NvcGUgb2YgdGhpcyB3b3JraW5nIGdy b3VwDQpkZWFscyB3aGljaCBkZXZpY2VzIGFyZSBhbGxvd2VkIHRvIHJlYWQgZnJvbSBhIHNlbnNv ciBvciB3cml0ZSB0byBhbg0KYWN0dWF0b3IuIEluIGRldGFpbCB0aGlzIG1lYW5zIGZvciBleGFt cGxlIHRoYXQgYSBkZXZpY2UgYXNzb2NpYXRlZCB0byBhDQp1c2VyIG1heSBvciBtYXkgbm90IOKA nHJlYWQiIG1lYXN1cmVtZW50cyBmcm9tIGEgZGV2aWNlIGFzc29jaWF0ZWQgdG8gYQ0KcHJvdmlk ZXIgb2Ygc2Vuc29yIHNlcnZpY2VzLiBBbmFsb2dvdXNseSBhIGRldmljZSBhc3NvY2lhdGVkIHRv IGEgdXNlciBtYXkNCm9yIG1heSBub3Qg4oCcd3JpdGUiIGFjdHVhdG9yIHNldHRpbmdzIHRvIGEg ZGV2aWNlIGFzc29jaWF0ZWQgd2l0aCBhDQpwcm92aWRlciBvZiBhY3R1YXRvciBzZXJ2aWNlcy4g IFRoZXJlIG1heSBiZSBvdGhlciBzZWN1cml0eSBwcm9ibGVtcyBhcw0Kd2VsbCBhbmQgd2Ugc2hv dWxkIGxpc3QgdGhlbSBhbmQgZGVjaWRlIGlmIHRoZXkgYXJlIGluIHNjb3BlLg0KDQpBcmUgd2Ug T0sgb24gdGhpcyBsZXZlbD8NCg0KRnVydGhlciBjb21tZW50cyBiZWxvdy4NCg0KDQpPbiAyMDE1 LTAxLTIzIDEyOjEwLCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2VyZGVzQHR6aS5kZT4gd3JvdGU6DQoN Cj5IaSBHw7ZyYW4sDQo+DQo+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLg0KPg0KPk9uIDAx LzIyLzIwMTUgMDk6MTEgQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+IE9uIDIwMTUtMDEt MjEgMTI6NDAsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCj4+PiBJ ZiB0aGUgcHJhY3RpdGlvbmVyJ3MgZGV2aWNlIGlzIHRoZSBzZXJ2ZXIsIHRoZQ0KPj4+IHBhdGll bnQncyBkZXZpY2Ugd2lsbCB3cml0ZSBkYXRhIHRvIHRoZSBwcmFjdGl0aW9uZXIncyByZXNvdXJj ZSBhbmQgdGhlDQo+Pj4gcHJhY3RpdGlvbmVyIHdpbGwgYmUgdGhlIHJlc291cmNlIG93bmVyLg0K Pj4gSSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGRldmljZSBvd25lcnNoaXAgaW1wbGllcyByZXNv dXJjZSBvd25lcnNoaXAuIEkNCj4+IHRoaW5rIHJlc291cmNlIG93bmVyc2hpcCBpcyBhIG1hdHRl ciBvZiBsZWdpc2xhdGlvbiBhbmQgYWdyZWVtZW50cy4gSWYgYQ0KPj4gcGF0aWVudCAgc2lnbnMg dXAgd2l0aCBhIGNhcmVnaXZlciBvciBzb21lIG90aGVyIGhlYWx0aGNhcmUgc3lzdGVtLCBpdA0K Pj5tYXkNCj4+IG9yIG1heSBub3QgcmV0YWluIGl0cyBhYmlsaXR5IHRvIHNldCBhY2Nlc3MgcG9s aWNpZXMgKGkuZS4gYmUgcmVzb3VyY2UNCj4+IG93bmVyKS4gDQo+Pg0KPj4gSW4gU3dlZGVuLCB0 aGUgY2FyZWdpdmVyIHdpbGwgc2V0IGFjY2VzcyBwb2xpY2llcyBhbmQgYXMgYSBwYXRpZW50IHlv dQ0KPj5hcmUNCj4+IG5vdCBhbHdheXMgYW5kIGFsbCB0aGUgdGltZSBlbnRpdGxlZCB0byB5b3Vy IHJlY29yZHMgKG9yIHJlc2V0dGluZyB0aGUNCj4+IHBvbGljaWVzKS4gVGhpcyBtYXkgZGVwZW5k IG9uIHRoZSBtZW50YWwgY29uZGl0aW9uIG9mIHRoZSBwYXRpZW50LiBJdA0KPj5tYXkNCj4+IGFs c28gZGVwZW5kIG9uIHRoZSB0eXBlIG9mIG1lZGljYWwgZGF0YSwgZS5nLiBpZiBhIHJlY2VudCBl eGFtaW5hdGlvbg0KPj4gaW5kaWNhdGUgdGhhdCB5b3UgbWF5IGhhdmUgYSBsZXRoYWwgZGlzZWFz ZSwgeW91IG1heSBub3QgYmUgYWJsZSB0byBsb29rDQo+PiB0aGF0IHVwIGJlZm9yZSB5b3UgaGF2 ZSB0YWxrZWQgdG8geW91ciBkb2N0b3IuDQo+Pg0KPj4gQnV0IGlycmVzcGVjdGl2ZSBvZiB3aG8g aXMgcmVzb3VyY2Ugb3duZXIsIGNhcmVnaXZlciBvciBwYXRpZW50LCB0aGUNCj4+IHF1ZXN0aW9u IG9mIGRldmljZSBvd25lcnNoaXAgaXMgc2VwYXJhdGUuDQo+DQo+WWVzLCBJIGFncmVlIHRoYXQg d2Ugc2hvdWxkIG5vdCB1c2UgdGhlIHRlcm0gImRldmljZSBvd25lciIgaWYgd2UgYXJlDQo+bm90 IHN1cmUgdGhhdCB0aGUgZGV2aWNlIG93bmVyIGlzIGluIGNvbnRyb2wgb2YgdGhlIGFjY2VzcyBw ZXJtaXNzaW9ucy4NCj5XZSBzaG91bGQgY2hhbmdlIHRoaXMgd2l0aCB0aGUgbmV4dCB2ZXJzaW9u Lg0KDQpHb29kLg0KDQo+DQo+TmV2ZXJ0aGVsZXNzLCB5b3Ugc2VlbSB0byBhc3N1bWUgdGhhdCBp dCBpcyBjbGVhciB3aG8gdGhlIHJlc291cmNlIG93bmVyDQo+KHRoZSBvbmUgdGhhdCBjb250cm9s cyB0aGUgYWNjZXNzIHBvbGljaWVzIGZvciBhIHJlc291cmNlKSBpcyBpbiBhDQo+c2NlbmFyaW8u IEJ1dCBpdCBkZXBlbmRzIG9uIHRoZSBjb25jcmV0ZSBzb2x1dGlvbiB3aGljaCBvbmUgb2YgdGhl DQo+cGFydGllcyBpcyB0aGUgcmVzb3VyY2Ugb3duZXIgaW4gYSBnaXZlbiBzY2VuYXJpby4NCg0K SSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdGhhdCB3ZSBoYXZlIHRlcm0gdG8gZXhwcmVzcyBhIHJv bGUgcHJvdmlkaW5nIGENCnNlbnNvci9hY3R1YXRvciBzZXJ2aWNlLCBhbmQgYSByb2xlIHVzaW5n IGl0Lg0KDQo+TW9yZW92ZXIsIGluIGENCj5zY2VuYXJpbyB3aGVyZSB0d28gZGlmZmVyZW50IHBh cnRpZXMgbWF5IGJlIGludm9sdmVkLCBvbmUgdGhhdCByZXF1ZXN0cw0KPmEgcmVwcmVzZW50YXRp b24gb2YgdGhlIHJlc291cmNlIGFuZCBvbmUgdGhhdCBwcm92aWRlcyB0aGUgcmVzb3VyY2UNCj5y ZXByZXNlbnRhdGlvbiwgdGhlc2UgdHdvIHBhcnRpZXMgbWF5IGhhdmUgZGlmZmVyZW50IGludGVy ZXN0cyBhbmQgdGh1cw0KPmhhdmUgZGlmZmVyZW50IHByb2JsZW1zIHRoYXQgbmVlZCB0byBiZSBz b2x2ZWQgYnkgYW4gYXV0aG9yaXphdGlvbg0KPnNvbHV0aW9uLiBUaHVzLCB0aGUgcmVzb3VyY2Ug b3duZXIncyBwcm9ibGVtcyBhcmUgbm90IHRoZSBvbmx5IHByb2JsZW1zDQo+d2UgbmVlZCB0byBj b25zaWRlci4NCg0KDQpXaGF0IHlvdSBqdXN0IHN0YXRlZCBpcyB2ZXJ5IGNsb3NlIHRvIHRoZSBw b2ludCBJIHdhbnQgdG8gbWFrZS4gSXQgc2VlbXMNCndlIGFncmVlIHRoYXQgdGhlcmUgaXMgYSBk aWZmZXJlbmNlIGJldHdlZW4gdGhlIHBhcnR5IHByb3ZpZGluZyBhbmQgdGhlDQpwYXJ0eSByZXF1 ZXN0aW5nLiBUaGVyZWZvcmUgd2UgbmVlZCBhIHRlcm1pbm9sb2d5IHRvIGRlc2NyaWJlIGhvdyB0 aGlzDQpkaWZmZXJlbmNlIGFwcGxpZXMgdG8gdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbXMgIChp biB0aGUgc2VjdGlvbnMNCmVudGl0bGVkIOKAnEF1dGhvcml6YXRpb24gUHJvYmxlbSBTdW1tYXJ5 4oCdIGluIHRoZSB1c2UgY2FzZSBkb2N1bWVudCkuDQoNCg0KPg0KPkZvciBDb0FQLCB0aGUgZW50 aXR5IHRoYXQgY29udHJvbHMgdGhlIGFjY2VzcyBwZXJtaXNzaW9ucyB0byBhIENvQVANCj5yZXNv dXJjZSB3aWxsIGxpa2VseSBiZSB0aGUgcmVzb3VyY2Ugb3duZXIsIGFuZCB0aHVzIHRoZSBvd25l ciBvZiB0aGUNCj5kYXRhIHRoYXQgaXMgc3RvcmVkIHRoZXJlLiBJZiB5b3UgYXJlIHRyYW5zbWl0 dGluZyBkYXRhIHRvIHRoYXQNCj5yZXNvdXJjZSwgeW91IGFyZSB0aGUgcmVzb3VyY2Ugb3duZXIg YXMgbG9uZyBhcyB5b3UgY29udHJvbCB0aGUgYWNjZXNzDQo+cGVybWlzc2lvbnMgZm9yIHRoaXMg cmVzb3VyY2UuIElmIHlvdSBhcmUgdHJhbnNtaXR0aW5nIGRhdGEgdG8gc29tZW9uZQ0KPmVsc2Un cyBDb0FQIHJlc291cmNlIHlvdSBhcmUgZ2l2aW5nIHVwIG93bmVyc2hpcCBmb3IgdGhpcyBjb3B5 IG9mIHRoZQ0KPmRhdGEuDQoNCkkgYWdyZWUgdGhhdCBzZW5zb3IgYW5kIGFjdHVhdG9yIHJlbGF0 ZWQgZGF0YSBuZWVkcyB0byBiZSBzZWN1cmVkDQplbmQtdG8tZW5kIGJldHdlZW4gdXNlciBkZXZp Y2UgYW5kIHByb3ZpZGVyIGRldmljZSwgYW5kIHRoYXQgdGhpcyBpcyBwYXJ0DQpvZiB0aGUgYXV0 aG9yaXphdGlvbiBwcm9ibGVtOiBhY2Nlc3MgY29udHJvbCB0byBzZW5zb3IgZGF0YSBtYXkgYmUg b2YNCmxpbWl0ZWQgdmFsdWUgaWYgc2VudCBpbiBwbGFpbiB0ZXh0OyBhY2Nlc3MgY29udHJvbCB0 byBhY3R1YXRpb24gZGF0YQ0KbmVlZHMgdG8gYmUgaW50ZWdyaXR5IHByb3RlY3RlZCwgZXRjLiBC dXQgSeKAmW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQNCnlvdSBtZWFuIHdpdGggImRhdGEg b3duZXJzaGlw4oCdLiBTZW5zb3IgZGF0YSBpcyBwcm92aWRlZCBpbiBwcm90ZWN0ZWQgZm9ybQ0K dG8gYW4gYXV0aG9yaXplZCB1c2VyLCB3aGF0IHRoZSB1c2VyIGRvZXMgd2l0aCB0aGlzIGRhdGEg aXMgYmV5b25kIHRoZQ0Kc2NvcGUgb2YgdGhpcyB3b3JraW5nIGdyb3VwLCBpc27igJl0IGl0PyBJ c27igJl0IHRoYXQgbW9yZSBsaWtlIGFuIGFncmVlbWVudA0KYmV0d2VlbiB0aGUgcGFydGllcz8g SSBhc3N1bWUgeW91IGFyZSBub3QgdGhpbmtpbmcgb2YgZGlnaXRhbCByaWdodHMNCm1hbmFnZW1l bnQuDQoNCj4NCj5JZiB5b3Ugd2FudCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgb3duZXIgb2YgdGhl IGRhdGEgbmV2ZXIgY2hhbmdlcyB5b3UNCj53aWxsIGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQgdGhl IHJlc291cmNlIG93bmVyIGNhbiBjb250cm9sIHRoZSBhY2Nlc3MNCj5wZXJtaXNzaW9ucyBmb3Ig dGhpcyBkYXRhIG9uIGFsbCBkZXZpY2VzIHdoZXJlIHRoZSBkYXRhIGlzIHRyYW5zbWl0dGVkDQo+ dG8uIEV2ZW4gaWYgZGF0YSBpcyB0cmFuc21pdHRlZCB0byBhIHJlcXVlc3RpbmcgY2xpZW50IHlv dSBhcmUgZ2l2aW5nIHVwDQo+b3duZXJzaGlwIGZvciB0aGUgY29weSBvZiB0aGUgZGF0YSB0aGF0 IHlvdSBhcmUgdHJhbnNtaXR0aW5nLCB1bmxlc3MgeW91DQo+Y2FuIGNvbnRyb2wgYWNjZXNzIHBv bGljaWVzIGZvciB0aGUgZGF0YSBvbiB0aGUgY2xpZW50LiBZb3UgbWF5IGNvbnRyb2wNCj55b3Vy IG93biBjb3B5IG9mIHRoZSBkYXRhLCBidXQgbm90IHRoZSBjbGllbnQncyBjb3B5Lg0KPg0KPkkg ZG9uJ3QgdGhpbmsgaXQncyBzbyBjbGVhciB0aGF0IHRoZSBwYXRpZW50IGlzIGFsd2F5cyB0aGUg cmVzb3VyY2UNCj5vd25lciBpbiBhIGhlYWx0aGNhcmUgc2NlbmFyaW8uDQoNClllcywgYXMgSSBt ZW50aW9uZWQgaW4gbXkgcHJldmlvdXMgbWFpbCDigJxJbiBTd2VkZW4sIHRoZSBjYXJlZ2l2ZXIg d2lsbCBzZXQNCmFjY2VzcyBwb2xpY2llcyDigJwuIElzIHRoZXJlIHNvbWUgY29uZnVzaW9uIGFi b3V0IHRoZSB0ZXJtIOKAnGNhcmVnaXZlcuKAnT8gSQ0KbWVhbnQgdGhlIGFkbWluaXN0cmF0aXZl IHJlcHJlc2VudGF0aXZlIG9mIHRoZSBkb2N0b3IgZXRjLiAtIHJvdWdobHkgdGhlDQpzYW1lIGFz IHlvdXIgdGVybSDigJxwcmFjdGl0aW9uZXLigJ0uDQoNCg0KDQo+TGV0J3MgYXNzdW1lIHRoYXQg aW4gdGhlIHBlcnNvbmFsIGhlYWx0aA0KPm1vbml0b3JpbmcgY2FzZSwgYSBwcmFjdGl0aW9uZXIg cmVjZWl2ZXMgZGF0YSBmcm9tIEpvaG4ncyBoZWFydCByYXRlDQo+bW9uaXRvciB3aXRoIGhlciBz bWFydHBob25lLiBKb2huIGlzIHRoZSBvd25lciBvZiB0aGUgaGVhcnQgcmF0ZQ0KPmluZm9ybWF0 aW9uIHdoaWxlIGl0IGlzIG9uIHRoZSBoZWFydCByYXRlIG1vbml0b3IuIEhlIHdhbnRzIHRvIGNv bnRyb2wNCj53aG8gaXMgYWJsZSB0byBhY2Nlc3MgdGhpcyBkYXRhLiBCdXQgSSB0aGluayBpdCBp cyB1bmxpa2VseSB0aGF0IHRoZQ0KPnByYWN0aXRpb25lciB3aWxsIGxldCBKb2huIGNvbmZpZ3Vy ZSBhY2Nlc3MgcG9saWNpZXMgZm9yIGRhdGEgb24gaGVyDQo+ZGV2aWNlLiBTaGUgZ2FpbnMgb3du ZXJzaGlwIGZvciBoZXIgY29weSBvZiBKb2huJ3MgZGF0YSBzaW5jZSBzaGUgaXMgdGhlDQo+b25l IHRoYXQgY29udHJvbHMgdGhlIGFjY2VzcyBwb2xpY2llcy4NCg0KSSBzZWUgdHdvIChvciBvbmUt YW5kLWEtaGFsZikgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBoZXJlLiBUaGUgZmlyc3QNCmF1dGhv cml6YXRpb24gcHJvYmxlbSBpcyB3aXRoIEpvaG4gYXMg4oCccHJvdmlkZXLigJ0gb2Ygc2Vuc29y IG1lYXN1cm1lbnRzIGFuZA0KdGhlIHByYWN0aXRpb25lciBhcyDigJx1c2Vy4oCdLiAgVGhlIHNl Y29uZCBwcm9ibGVtIGlzIHdpdGggdGhlIHByYWN0aXRpb25lcg0KYXMgcHJvdmlkZXIgKHRydXN0 ZWQgcHJveHkpLCBidXQgaG93IHRoYXQgZGF0YSBpcyB1c2VkIGlzIG5vdCBkZXNjcmliZWQNCih0 aGlzIGlzIHdoYXQgSSBtZWFudCBieSDigJxhbmQtYS1oYWxm4oCdKS4NCg0KSWYgd2UgY2FuIGhh dmUgYSBzb2x1dGlvbiB0byBob3cgYSBwcm92aWRlciBjYW4gc2V0IHBvbGljaWVzIGZvciBhY2Nl c3MgdG8NCmRhdGEgYW5kIG9ubHkgZ3JhbnQgYWNjZXNzIHRvIGF1dGhvcml6ZWQgdXNlcnMsIHRo ZW4gd2UgY291bGQgYXBwbHkgdGhpcw0Kc29sdXRpb24gdHdpY2U6IGZpcnN0IHdpdGggSm9obiBh cyBwcm92aWRlciwgdGhlbiB3aXRoIHRoZSBwcmFjdGl0aW9uZXIgYXMNCnByb3ZpZGVyLiBPZiBj b3Vyc2UsIHRoZXJlIG11c3QgYmUgYW4gYWdyZWVtZW50IGJldHdlZW4gSm9obiBhbmQgdGhlDQpw cmFjdGl0aW9uZXIgYWJvdXQgdGhlIHByYWN0aXRpb25lciBhY3RpbmcgcHJvdmlkZXIgZm9yIHRo aXMgZGF0YSwgYnV0IEkNCmRvbuKAmXQgdGhpbmsgdGhhdCBpcyBpbiBzY29wZSBvZiB0aGlzIHdv cmtpbmcgZ3JvdXAuDQoNCj4NCj5Zb3UgbWF5IHNheSB0aGF0IHlvdSBvbmx5IHdhbnQgdG8gc29s dmUgSm9obidzIHByb2JsZW0sIGkuZS4gcHJvdGVjdGluZw0KPmhpcyBtZWRpY2FsIGRhdGEuIEJ1 dCB0aGVuIHlvdSBhcmUgbm90IGNvbnNpZGVyaW5nIHRoZSBwcmFjdGl0aW9uZXIncw0KPmludGVy ZXN0LiBTaGUgd2lsbCB3YW50IHRvIGJlIHN1cmUgdGhhdCBvbmx5IGF1dGhvcml6ZWQgZGF0YSBp cw0KPnRyYW5zbWl0dGVkIHRvIGhlciBzbWFydHBob25lLg0KDQoNCldoYXQgZG9lcyAiYXV0aG9y aXplZCBkYXRh4oCdIG1lYW4/IFdpdGggdGhlIGFwcHJvcHJpYXRlIHNlY3VyaXR5IHNldHVwLCB0 aGUNCnNtYXJ0cGhvbmUgKHVzZXIgZGV2aWNlKSBjb3VsZCBhdXRoZW50aWNhdGUgdGhlIGhlYXJ0 IHJhdGUgbW9uaXRvcg0KKHByb3ZpZGVyIGRldmljZSksIHZlcmlmeSB0aGUgaW50ZWdyaXR5IG9m IHRoZSBkYXRhLCB2ZXJpZnkgdGhhdCBpdCBpcyBub3QNCmEgcmVwbGF5IG9mIGFuIG9sZCBjb21t dW5pY2F0aW9uLCB2ZXJpZnkg4oCcZnJlc2huZXNzIiBvZiB0aGUgY29tbXVuaWNhdGlvbg0KZXRj LiBCdXQgSSBndWVzcyB5b3UgbWVhbiBzb21ldGhpbmcgZWxzZT8NCg0KPg0KPklmIHlvdSB3YW50 IHRvIHVzZSBDb0FQIGZvciB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBkYXRhLCBpdCBpcyBub3Qg ZXZlbg0KPmNsZWFyIHdoaWNoIGRldmljZSB3aWxsIGJlIHRoZSBjbGllbnQgYW5kIHdoaWNoIHdp bGwgYmUgdGhlIHNlcnZlci4gSXQNCj5taWdodCBiZSB1c2VmdWwgaWYgdGhlIGhlYXJ0IHJhdGUg bW9uaXRvciBpcyB0aGUgc2VydmVyIGFuZCB0aGUNCj5zbWFydHBob25lIGlzIHRoZSBjbGllbnQg dGhhdCByZXF1ZXN0cyBkYXRhLiBCdXQgaXQgbWlnaHQgYWxzbyBiZSB1c2VmdWwNCj5pZiB0aGUg aGVhcnQgcmF0ZSBtb25pdG9yIGlzIHRoZSBjbGllbnQuIEkgZG9uJ3Qgc2VlIGEgZ29vZCByZWFz b24gdG8NCj5ydWxlIG91dCBvbmUgb2YgdGhlc2Ugc2V0dGluZ3MuDQoNCkxldOKAmXMgdHJ5IHRo ZSB0ZXJtaW5vbG9neSBhYm92ZTogdGhlIGhlYXJ0IHJhdGUgc2Vuc29yIGlzIGEgInByb3ZpZGVy IG9mDQpzZW5zb3IgZGF0YSIgYW5kIHRoZSBzbWFydHBob25lIGlzIGEgInVzZXIgb2Ygc2Vuc29y IGRhdGEiLiBEb2VzIHRoYXQgbWFrZQ0KbW9yZSBzZW5zZT8NCg0KPg0KPkkgZ3Vlc3MgaXQgaXMg bm90IHBvc3NpYmxlIHRvIHJlZHVjZSBhbGwgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBpbiB0aGUN Cj51c2UgY2FzZXMgdG8gdGhlIHByb3RlY3Rpb24gb2YgcmVzb3VyY2VzICh1bmxlc3Mgd2Ugc2F5 IHRoYXQgd2UgaGF2ZQ0KPnJlc291cmNlcyBvbiBib3RoIHNpZGVzIHdoaWNoIHdpbGwgcmVzdWx0 IGluIGhhdmluZyB0d28gcmVzb3VyY2UNCj5vd25lcnMpLiBUaHVzIGl0IGlzIG5vdCBzdWZmaWNp ZW50IHRvIG9ubHkgbGlzdCB0aGUgcmVzb3VyY2Ugb3duZXIncw0KPnByb2JsZW1zLiBUaGUgdXNl IGNhc2VzIG11c3QgYWxzbyByZWZsZWN0IHRoZSBwcm9ibGVtcyBvZiB0aGUgb3RoZXINCj5pbnZv bHZlZCBwYXJ0eSwgcmVnYXJkbGVzcyBvZiBob3cgeW91IG5hbWUgdGhpcyBvbmUgKEkgdGhpbmsg eW91cg0KPnN1Z2dlc3Rpb24gd2FzIGNsaWVudCBvd25lcikuDQoNCklmIHRoZXJlIGlzIGEgcHJv YmxlbSB3aXRoIHRoZSB3b3JkIOKAnHJlc291cmNl4oCdLCBtYXliZSB3ZSBjb3VsZCB0aGluayBp bg0KdGVybXMgb2Yg4oCcYXNzZXRz4oCdL+KAnGl0ZW1zIG9mIGludGVyZXN04oCdIChlLmcuIHRo aW5ncyBhbmQgcmVsYXRlZCBkYXRhKSBvbg0KdGhlIHByb3ZpZGVyIHNpZGUgYW5kIHVzZXIgc2lk ZSBhbmQgZm9ybXVsYXRlIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zDQppbiB0ZXJtcyBvZiB0 aGVzZT8NCg0KPg0KPlNpbmNlIHdlIGRvbid0IGtub3cgeWV0IHdoaWNoIHNvbHV0aW9uIHdlIHdp bGwgdXNlLCBpdCBtaWdodCBiZSBtb3JlDQo+dXNlZnVsIHRvIG9ubHkgdXNlIENvQVAgdGVybWlu b2xvZ3k6DQo+DQo+KiBFbmRwb2ludDogQW4gZW50aXR5IHBhcnRpY2lwYXRpbmcgaW4gdGhlIENv QVAgcHJvdG9jb2wuIENvbGxvcXVpYWxseSwNCj5hbiBlbmRwb2ludCBsaXZlcyBvbiBhICJOb2Rl IiwgYWx0aG91Z2ggIkhvc3QiIHdvdWxkIGJlIG1vcmUgY29uc2lzdGVudA0KPndpdGggSW50ZXJu ZXQgc3RhbmRhcmRzIHVzYWdlLCBhbmQgaXMgZnVydGhlciBpZGVudGlmaWVkIGJ5DQo+dHJhbnNw b3J0LWxheWVyIG11bHRpcGxleGluZyBpbmZvcm1hdGlvbiB0aGF0IGNhbiBpbmNsdWRlIGEgVURQ IHBvcnQNCj5udW1iZXIgYW5kIGEgc2VjdXJpdHkgYXNzb2NpYXRpb24NCj4NCj4qIENsaWVudDog VGhlIG9yaWdpbmF0aW5nIGVuZHBvaW50IG9mIGEgcmVxdWVzdDsgdGhlIGRlc3RpbmF0aW9uDQo+ ZW5kcG9pbnQgb2YgYSByZXNwb25zZS4NCj4NCj4qIFNlcnZlcjogVGhlIGRlc3RpbmF0aW9uIGVu ZHBvaW50IG9mIGEgcmVxdWVzdDsgdGhlIG9yaWdpbmF0aW5nDQo+ZW5kcG9pbnQgb2YgYSByZXNw b25zZQ0KPg0KPkFuZCBpbiBhZGRpdGlvbiAodG8gYmUgYWJsZSB0byBhZGRyZXNzIHRoZSBvd25l cidzIGludGVyZXN0KToNCj4NCj4qIFJlc291cmNlIFByaW5jaXBhbDogVGhlIHN1YmplY3QgdGhh dCBjb250cm9scyB0aGUgYWNjZXNzIHBlcm1pc3Npb25zDQo+Zm9yIGEgcmVzb3VyY2UuDQo+KHNl dmVyYWwgcGVvcGxlIHJlbWFya2VkIHRoYXQgdGhlIHRlcm0gIm93bmVyIiBpcyBtaXNsZWFkaW5n KQ0KPg0KPiogQ2xpZW50IFByaW5jaXBhbDogVGhlIHN1YmplY3QgdGhhdCBjb250cm9scyB0aGUg YWNjZXNzIHBlcm1pc3Npb25zIGZvcg0KPmEgY2xpZW50Lg0KPg0KPiogUHJpbmNpcGFsOiBBIHN1 YmplY3QgdGhhdCBpcyBlaXRoZXIgYSByZXNvdXJjZSBvd25lciBvciBhIGNsaWVudCBvd25lcg0K Pm9yIGJvdGguDQo+DQo+SXQgbWlnaHQgYWxzbyBiZSBoZWxwZnVsIHRvIGFkZCB0aGlzIHRvIHRo ZSB0ZXJtaW5vbG9neToNCj4NCj4qIFJlc291cmNlOiBBbiBpdGVtIG9mIGludGVyZXN0DQo+DQoN Cg0KQXMgYSBzdW1tYXJ5LCBJIHRoaW5rIHRoZSBtYWluIHB1cnBvc2Ugb2YgdGhlIHRlcm1pbm9s b2d5IGluIHRoZSB1c2UgY2FzZQ0KZG9jdW1lbnQgc2hvdWxkIGJlIHRvIGJlIGFibGUgdG8gZXhw cmVzcyB0aGUgY29uY3JldGUgYXV0aG9yaXphdGlvbg0KcHJvYmxlbXMgaW4gc3VmZmljaWVudCBk ZXRhaWwuIEUuZy4gd2Ugc2hvdWxkIGJlIGFibGUgdG8gZGlzdGluZ3Vpc2gNCmJldHdlZW4gdGhl IHJvbGUgYXNzb2NpYXRlZCB0byB0aGUgZGV2aWNlIHJlYWRpbmcgdGhlIHNlbnNvciBkYXRhIGZy b20gdGhlDQpyb2xlIGFzc29jaWF0ZWQgdG8gZGV2aWNlIGZyb20gd2hpY2ggc2Vuc29yIGRhdGEg aXMgYmVpbmcgcmVhZC4gSWYgd2UgY2FuDQpkbyB0aGF0IHdpdGggdGhpcyB0ZXJtaW5vbG9neSwg ZmluZS4gSWYgbm90IHRoZW4gd2Ugc2hvdWxkIG1heWJlIHNlbGVjdA0KYW5vdGhlcj8NCg0KQmVz dCByZWdhcmRzLA0KR8O2cmFuDQoNCg0K From nobody Mon Jan 26 06:24: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 1F32A1A8846 for ; Mon, 26 Jan 2015 06:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk8bcs5EIDGY for ; Mon, 26 Jan 2015 06:24:02 -0800 (PST) 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 B1A341A8843 for ; Mon, 26 Jan 2015 06:24:01 -0800 (PST) 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 t0QENtvx028538; Mon, 26 Jan 2015 15:23:55 +0100 (CET) Received: from [192.168.1.130] (p57A63D9A.dip0.t-ipconnect.de [87.166.61.154]) (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 3kWCxQ3sxFz83gD; Mon, 26 Jan 2015 15:23:54 +0100 (CET) Message-ID: <54C64DEE.3040608@tzi.de> Date: Mon, 26 Jan 2015 15:23:42 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <54BF9029.4060200@tzi.de> <54C22C2C.9050709@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gerdes@tzi.de List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 14:24:05 -0000 Hi Göran, On 01/26/2015 09:27 AM, Göran Selander wrote: > Hi Steffi, > > Thank you for your patient explanations. I am happy that we agree to leave > out device ownership. > > Regarding the remaining argumentation I’m sad to say that I’m still not > convinced. In short: I think we should have a terminology in the use case > document which allow us to express the concrete authorization problems of > the use cases in terms of this terminology. If I understand you right, you > say that we can’t express the authorization problems in terms of Resource, > Resource Owner (= Resource Principal), etc. because who is Resource Owner > may depend on solution. If that is the case, then I think we have a > problem. In my opinion, either the terminology is not appropriate, or > there is some problem with the application of the terminology to the use > cases. > > To eliminate the former, allow me to take a step back and attempt a > preliminary terminology to reach a common ground of understanding. Let me > know to what extent we can agree on this: > > In the use cases we focus on “things" like sensors (temperature sensors, > heart rate sensors etc.) and actuators (fan actuators, lock actuators > etc.); and related data like sensor measurements (temperatures, heart > rates, etc.) and actuator settings (fan configuration settings, lock > open/closed, etc. ). All these are "items of interest", or "assets" that > needs to be protected, some of which is in scope of this working group. > > In order to distinguish between the party providing a sensor/actuator > service and the party using the service we can use the terminology > “provider†(of sensor/actuator services) and “user†(of sensor/actuator > services). One important security problem in scope of this working group > deals which devices are allowed to read from a sensor or write to an > actuator. In detail this means for example that a device associated to a > user may or may not “read" measurements from a device associated to a > provider of sensor services. Analogously a device associated to a user may > or may not “write" actuator settings to a device associated with a > provider of actuator services. There may be other security problems as > well and we should list them and decide if they are in scope. > > Are we OK on this level? I don't see how this terminology will help us with the authorization solution. In CoAP, the server is not necessarily the sensor/actuator. The protection of sensor or actuator values does not really fit to the protection of CoAP resources (that are identified by a URI). Moreover, one of the endpoints may be a sensor while the other may be an actuator and we thus would have two providers. I agree that we want to protect items of interest. If you want to cut down the problem to "we protect the item of interest by defining who is allowed to read/write the item on one side" you are only addressing half of the problem. We don't get around the problem that there may be two parties with different interests involved by renaming them or by trying to fit the use cases to a model, where it is clear which party requests and which party provides an item of interest. We will only gain an authorization solution that restricts the possibilities of CoAP. I don't like the term "user" since it implies the presence of a human being. I don't know if that's what you have in mind? > Further comments below. > > > On 2015-01-23 12:10, "Stefanie Gerdes" wrote: >> Nevertheless, you seem to assume that it is clear who the resource owner >> (the one that controls the access policies for a resource) is in a >> scenario. But it depends on the concrete solution which one of the >> parties is the resource owner in a given scenario. > I think it is important that we have term to express a role providing a > sensor/actuator service, and a role using it. Considering what I wrote above, I don't see what we gain from introducing these roles. >> Moreover, in a >> scenario where two different parties may be involved, one that requests >> a representation of the resource and one that provides the resource >> representation, these two parties may have different interests and thus >> have different problems that need to be solved by an authorization >> solution. Thus, the resource owner's problems are not the only problems >> we need to consider. > > What you just stated is very close to the point I want to make. It seems > we agree that there is a difference between the party providing and the > party requesting. Therefore we need a terminology to describe how this > difference applies to the authorization problems (in the sections > entitled “Authorization Problem Summary†in the use case document). I don't think that these differences apply to the security objectives that the involved parties may want to achieve. As a principal, I don't care whether I request an item or provide an item. Regardless of the setting I want to make sure that my security objectives are achieved. >> For CoAP, the entity that controls the access permissions to a CoAP >> resource will likely be the resource owner, and thus the owner of the >> data that is stored there. If you are transmitting data to that >> resource, you are the resource owner as long as you control the access >> permissions for this resource. If you are transmitting data to someone >> else's CoAP resource you are giving up ownership for this copy of the >> data. > I agree that sensor and actuator related data needs to be secured > end-to-end between user device and provider device, and that this is part > of the authorization problem: access control to sensor data may be of > limited value if sent in plain text; access control to actuation data > needs to be integrity protected, etc. But I’m not sure I understand what > you mean with "data ownershipâ€. Sensor data is provided in protected form > to an authorized user, what the user does with this data is beyond the > scope of this working group, isn’t it? Isn’t that more like an agreement > between the parties? I assume you are not thinking of digital rights > management. I don't think the term "user" is helpful here. There may be two devices communicating without any user interaction. I am just trying to explain that there are two parties involved in exchanging an item of interest. Each one of these parties may have their own security objectives. The sender will want to make sure that the receiver is authorized to get the data, the receiver will want to make sure that the sender is authorized to send the data. In a concrete use case, I see no evidence who the sender and who the receiver will be. > >> If you want to make sure that the owner of the data never changes you >> will have to make sure that the resource owner can control the access >> permissions for this data on all devices where the data is transmitted >> to. Even if data is transmitted to a requesting client you are giving up >> ownership for the copy of the data that you are transmitting, unless you >> can control access policies for the data on the client. You may control >> your own copy of the data, but not the client's copy. >> >> I don't think it's so clear that the patient is always the resource >> owner in a healthcare scenario. > Yes, as I mentioned in my previous mail “In Sweden, the caregiver will set > access policies “. Is there some confusion about the term “caregiverâ€? I > meant the administrative representative of the doctor etc. - roughly the > same as your term “practitionerâ€. It seemed to me that you wanted to suggest that we use the terminology from UMA where in one use case the patient is the resource owner. In this case the patient would be the one that is in control of the access policies. So we agree that it's not clear whether the patient or the caregiver/practitioner is the resource owner? >> Let's assume that in the personal health >> monitoring case, a practitioner receives data from John's heart rate >> monitor with her smartphone. John is the owner of the heart rate >> information while it is on the heart rate monitor. He wants to control >> who is able to access this data. But I think it is unlikely that the >> practitioner will let John configure access policies for data on her >> device. She gains ownership for her copy of John's data since she is the >> one that controls the access policies. > I see two (or one-and-a-half) authorization problems here. The first > authorization problem is with John as “provider†of sensor measurments and > the practitioner as “userâ€. The second problem is with the practitioner > as provider (trusted proxy), but how that data is used is not described > (this is what I meant by “and-a-halfâ€). > > If we can have a solution to how a provider can set policies for access to > data and only grant access to authorized users, then we could apply this > solution twice: first with John as provider, then with the practitioner as > provider. Of course, there must be an agreement between John and the > practitioner about the practitioner acting provider for this data, but I > don’t think that is in scope of this working group. Okay, so we agree that we need a solution that addresses the authorization problems of both endpoints in a conversation? >> You may say that you only want to solve John's problem, i.e. protecting >> his medical data. But then you are not considering the practitioner's >> interest. She will want to be sure that only authorized data is >> transmitted to her smartphone. > > What does "authorized data†mean? With the appropriate security setup, the > smartphone (user device) could authenticate the heart rate monitor > (provider device), verify the integrity of the data, verify that it is not > a replay of an old communication, verify “freshness" of the communication > etc. But I guess you mean something else? I meant that practitioner will want to be sure that the data transmitted to the practitioner's smartphone stems from an authorized source. > >> If you want to use CoAP for the transmission of the data, it is not even >> clear which device will be the client and which will be the server. It >> might be useful if the heart rate monitor is the server and the >> smartphone is the client that requests data. But it might also be useful >> if the heart rate monitor is the client. I don't see a good reason to >> rule out one of these settings. > Let’s try the terminology above: the heart rate sensor is a "provider of > sensor data" and the smartphone is a "user of sensor data". Does that make > more sense? Hm, I don't see how this helps us. If you want to be able to distinguish the practitioner's security objectives from John's security objectives, we could state that explicitely in the problem summary. >> I guess it is not possible to reduce all authorization problems in the >> use cases to the protection of resources (unless we say that we have >> resources on both sides which will result in having two resource >> owners). Thus it is not sufficient to only list the resource owner's >> problems. The use cases must also reflect the problems of the other >> involved party, regardless of how you name this one (I think your >> suggestion was client owner). > If there is a problem with the word “resourceâ€, maybe we could think in > terms of “assetsâ€/“items of interest†(e.g. things and related data) on > the provider side and user side and formulate the authorization problems > in terms of these? At some point we will have to map it to CoAP, so I don't understand how this exercise would be useful. >> Since we don't know yet which solution we will use, it might be more >> useful to only use CoAP terminology: >> >> * Endpoint: An entity participating in the CoAP protocol. Colloquially, >> an endpoint lives on a "Node", although "Host" would be more consistent >> with Internet standards usage, and is further identified by >> transport-layer multiplexing information that can include a UDP port >> number and a security association >> >> * Client: The originating endpoint of a request; the destination >> endpoint of a response. >> >> * Server: The destination endpoint of a request; the originating >> endpoint of a response >> >> And in addition (to be able to address the owner's interest): >> >> * Resource Principal: The subject that controls the access permissions >> for a resource. >> (several people remarked that the term "owner" is misleading) >> >> * Client Principal: The subject that controls the access permissions for >> a client. >> >> * Principal: A subject that is either a resource owner or a client owner >> or both. >> >> It might also be helpful to add this to the terminology: >> >> * Resource: An item of interest >> > > As a summary, I think the main purpose of the terminology in the use case > document should be to be able to express the concrete authorization > problems in sufficient detail. E.g. we should be able to distinguish > between the role associated to the device reading the sensor data from the > role associated to device from which sensor data is being read. If we can > do that with this terminology, fine. If not then we should maybe select > another? What do we gain from being able to distinguish the role of the device that reads the sensor data from the role of the device that hosts the sensor data? How do the problems of the principals of these devices differ? Best regards, Steffi From nobody Thu Jan 29 01:54:28 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 C6A671A007A for ; Thu, 29 Jan 2015 01:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 c7WFyRZgdlBB for ; Thu, 29 Jan 2015 01:54:22 -0800 (PST) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id B40AA1A0126 for ; Thu, 29 Jan 2015 01:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1422525259; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=PQfdWfapEBMlC4fe7xhUKgr4+kOfYv7CXkTxzeP2TmU=; b=QoshrAtbdLb96dOAND9TGgNb4qDxPrRJ0khkfGYNkq102swGEGq7j+EKnG5zjiz2FwQ04H/LhLedDJltl+1owonhjo0pugMmriykjqW8Tcyhzz+0rkmu64neFwxZa8OpNax02xAADDF0Lg4SnzsdzMSgMcy9yupH/ub8IxJc8z0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R971e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03013; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=1; RT=1; SR=0; Received: from 10.1.149.171(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.184) by smtp.aliyun-inc.com(127.0.0.1); Thu, 29 Jan 2015 17:54:16 +0800 User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Thu, 29 Jan 2015 17:54:13 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: Arguments to publish use case document as RFC Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Ace] Arguments to publish use case document as RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 09:54:25 -0000 Hello all, Recently in SACM WG, there were a lot of discussions about whether or not to publish their use case document as RFC: http://www.ietf.org/mail-archive/web/sacm/current/msg02306.html I understand that we discussed about this before in the mailing list some time ago. I am sure that this issue will be raised again during the IESG review stage or WGLC stage. So, let=A1=AFs be prepared for it. Could you provide any arguments why you think the draft should get published as RFC if that's what you think or if you think it is fine to have this as a WG draft that remains a guiding document that does not get published. Here are a few arguments for it: 1) One obvious reason for having this as a WG draft (published or not) is that some felt their input wasn't considered when it was an individual draft. 2) Another reason is that it is nice to have it as an RFC for reference later on, but could a wiki provide a link to the expired draft just as easily?=20 3) The use cases draft helps to frame the problem(s) being addressed by ACE proposals and is important for guiding future development and recording the history of consensus about the scope of ACE work. 4) A wiki is too dynamic and can=A1=AFt be trusted. Anything else? Thanks, Kind Regards Kepeng (as co-chair) From nobody Thu Jan 29 02:41: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 4AAB01A0151 for ; Thu, 29 Jan 2015 02:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfoAFxNsdx9s for ; Thu, 29 Jan 2015 02:41:21 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD91A0143 for ; Thu, 29 Jan 2015 02:41:20 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 7EEC61682 for ; Thu, 29 Jan 2015 11:41:18 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t0TAfIfC000384 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Jan 2015 11:41:18 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 1351B1B8 for ; Thu, 29 Jan 2015 11:41:18 +0100 (CET) Message-ID: <54CA0E4D.9030606@sics.se> Date: Thu, 29 Jan 2015 11:41:17 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ace@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090103050207040102080306" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NJKFims - 01c69045f34e - 20150129 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NJKFims&m=01c69045f34e&t=20150129&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NJKFims&m=01c69045f34e&t=20150129&c=n X-Antispam-Training-Phish: https://canit.sunet.se/canit/b.php?i=09NJKFims&m=01c69045f34e&t=20150129&c=p X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NJKFims&m=01c69045f34e&t=20150129&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] Arguments to publish use case document as RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 10:41:24 -0000 This is a cryptographically signed message in MIME format. --------------ms090103050207040102080306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 01/29/2015 10:54 AM, Kepeng Li wrote: > Hello all, > > Recently in SACM WG, there were a lot of discussions about whether or n= ot > to publish their use case document as RFC: > http://www.ietf.org/mail-archive/web/sacm/current/msg02306.html > > I understand that we discussed about this before in the mailing list so= me > time ago. > > I am sure that this issue will be raised again during the IESG review > stage or WGLC stage. > > So, let=E2=80=99s be prepared for it. > > Could you provide any arguments why you think the draft should get > published as RFC if that's what you think or if you think it is fine to= > have this as > a WG draft that remains a guiding document that does not get published.= > > Here are a few arguments for it: > 1) One obvious reason for having this as a WG draft (published or not) = is > that some felt their input wasn't considered when it was an individual > draft. Another reason is that people might be more motivated to contribute to a = WG draft than to an individual draft. People will also be more motivated to contribute if the final result is=20 a published document that they can point to when someone asks them what=20 the result of their work was. > 2) Another reason is that it is nice to have it as an RFC for reference= > later on, but could a wiki provide a link to the expired draft just as > easily? In most scientific publications, referencing a weblink (like e.g. a=20 wiki) is strongly discouraged due to their ephemeral nature. Having an=20 RFC number is not only nice to have, it is quite essential if one is to=20 refer to this document in any serious article. > 3) The use cases draft helps to frame the problem(s) being addressed by= > ACE proposals and is important for guiding future development and > recording the history of consensus about the scope of ACE work. A wiki is good for some living, ongoing work. By putting the use cases=20 in a wiki, we would indicate that this work is forever ongoing and that=20 we basically haven't reached a stable consensus on what are good use=20 cases for ACE. > 4) A wiki is too dynamic and can=E2=80=99t be trusted. > See above > > Anything else? > Publishing the draft as (informational) RFC also helps to valorize the=20 work that the authors put into this document. If the draft is just published as a wiki, this sends the message to many = readers that IETF didn't consider this a worthy enough contribution for=20 a real publication. This would also discourage future contributions to=20 such documents (especially by scientists). /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 --------------ms090103050207040102080306 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 KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAxMjkxMDQxMTdaMCMGCSqGSIb3DQEJBDEW BBSxv2GnCdqvxQQsSPg4JVKlZXxq3TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAqoxL1JHjsO7Y4CvwYnfLzXPlPue8R/gQiibvSQtmINJ+1ZTAjS+84F8xV6QDQOcCXGtq izqr79KcYN/Q8ci0fUA6YnRh011MC+L8qMyhnBuT63Ig89/k4rOISOdBnfbF5FEuQ1x7NwRa 5LQrYgzUwHgY0eQCpc1pMagkXk5ZTUtZOzaMYqph6OSvyPWMSrVMJiTrPZfRXDCp9c5h3RM4 153DeO1B8BIMv4qBWqU2edq0YN5m39opRzrZNbn6DOtKfzV/3I3CKNMzCMz0hyn+vFLXMJcE go7tEA+C82H1Ngv+4wigSUElj9R/Oh3NErl0tKvY0SjM7Nbg5iIDZD9eoQAAAAAAAA== --------------ms090103050207040102080306-- From nobody Thu Jan 29 04:19:12 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369D41A035F for ; Thu, 29 Jan 2015 04:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsLV7lGgh_gv for ; Thu, 29 Jan 2015 04:19:09 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3861A01D8 for ; Thu, 29 Jan 2015 04:19:09 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id z60so27068991qgd.6 for ; Thu, 29 Jan 2015 04:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kLzppRnbDhjGglPHwla04BHfuxgqoDNDF+DWH3F0E4A=; b=Ihquc0DoCHMSj69S1cKmy1/3YsML5/sQIAI4vMt6N7f7tJmhR6KooVEtuLZvj+DCp1 L8MT6Yw9zR3g4moa+MLRVbNsz3owgcPckxx3Hd0tnwrfMDCTSeDXo260cVt1LFlBBEV+ yqTgdBbqWvFqP7agEpoWP8x7JfRbBAbaUZyCvjhdxSZ40thxkUeJbOEGP/BYCND8zSDU NXtGb8Zk1tRe21GHN9+YYQ24XY1xGUdSIojf5wC02A2HuyoGja0xV1PYnvWUVklaW1G5 8PKBJ1zTWlmWf8Hti35ZUKjfPskk3t/kFMMl2pidoTdU/H69K7ug1QQgQubZd2b1eDRD Q59g== X-Received: by 10.224.161.138 with SMTP id r10mr396142qax.21.1422533948546; Thu, 29 Jan 2015 04:19:08 -0800 (PST) Received: from [10.227.93.89] (mobile-166-171-185-041.mycingular.net. [166.171.185.41]) by mx.google.com with ESMTPSA id 107sm6838913qgf.21.2015.01.29.04.19.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 04:19:07 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Thu, 29 Jan 2015 07:19:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <659231CA-C99C-48F8-B806-0B509ADB19AB@gmail.com> References: To: Kepeng Li Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Arguments to publish use case document as RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 12:19:11 -0000 Thank you, Kepeng & Hannes. =20 Please continue the thread from the appropriate message, this is just a quic= k clarification on how/where the info you help pull together on these questi= ons will be used. Sent from my iPhone > On Jan 29, 2015, at 4:54 AM, "Kepeng Li" wrot= e: >=20 > Hello all, >=20 > Recently in SACM WG, there were a lot of discussions about whether or not > to publish their use case document as RFC: > http://www.ietf.org/mail-archive/web/sacm/current/msg02306.html >=20 > I understand that we discussed about this before in the mailing list some > time ago. >=20 > I am sure that this issue will be raised again during the IESG review > stage or WGLC stage. I'll leverage this information in a discussion with the IESG prior to the pu= blication of this use case draft and the one from SACM. My goal is to get t= his done separate from your last call process and do appreciate the chairs a= nd WG developing the business case further. Thank you, Kathleen >=20 > So, let=E2=80=99s be prepared for it. >=20 > Could you provide any arguments why you think the draft should get > published as RFC if that's what you think or if you think it is fine to > have this as > a WG draft that remains a guiding document that does not get published. >=20 > Here are a few arguments for it: > 1) One obvious reason for having this as a WG draft (published or not) is > that some felt their input wasn't considered when it was an individual > draft. > 2) Another reason is that it is nice to have it as an RFC for reference > later on, but could a wiki provide a link to the expired draft just as > easily?=20 > 3) The use cases draft helps to frame the problem(s) being addressed by > ACE proposals and is important for guiding future development and > recording the history of consensus about the scope of ACE work. > 4) A wiki is too dynamic and can=E2=80=99t be trusted. >=20 >=20 > Anything else? >=20 > Thanks, > Kind Regards > Kepeng (as co-chair) >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jan 29 08:42:28 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 69AD71A1EF6 for ; Thu, 29 Jan 2015 08:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge8AIhS8ds6r for ; Thu, 29 Jan 2015 08:42:22 -0800 (PST) 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 A20081A19FA for ; Thu, 29 Jan 2015 08:42:21 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-4d-54ca62eb2a6e Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.DF.04076.BE26AC45; Thu, 29 Jan 2015 17:42:19 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.13]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 17:42:19 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "gerdes@tzi.de" Thread-Topic: [Ace] Role terminology in use case draft (Was: Container Use Case) Thread-Index: AQHQNW8OY2BIXPo9OU6z1ZDeRGr/mZzLy0+AgAGzfACABJpLgIAAUqcAgATuewA= Date: Thu, 29 Jan 2015 16:42:18 +0000 Message-ID: References: <54BF9029.4060200@tzi.de> <54C22C2C.9050709@tzi.de> <54C64DEE.3040608@tzi.de> In-Reply-To: <54C64DEE.3040608@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <896E721A77460343BB5F302F68002D6E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM+Jvje7rpFMhBhNbJCy+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJWxcvcW1oIdFxkrVs76z97A2HGGsYuRk0NC wESiZW8HC4QtJnHh3nq2LkYuDiGBI4wSDxvaWCGcxYwSjbOvM4NUsQm4SDxoeMQEYosIKEu0 /fkMNolZQFFi96yz7CC2sECgRNOhx2wQNUES8x90M0LYfhJrz98Gq2ERUJVYvO8u2GZeAQuJ 3a3f2SGWPWOUeLpkJtgyTgE1iTPLT4E1MAKd9/3UGiaIZeISt57MZ4I4W0BiyZ7zzBC2qMTL x/9YQWxRAT2Jldeb2CDiihIfX+0DOoIDqFdTYv0ufYgx1hLzH31igbl/SvdDdoh7BCVOznzC MoFRYhaSbbMQumch6Z6FpHsWku4FjKyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQJj8eCW 31Y7GA8+dzzEKMDBqMTDa7DoZIgQa2JZcWXuIUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWl OanFhxiZODilGhjd2i5/7q5cn5b/5ee26ROFE128W0TtLViXLv8doaq88v0GNYb3Nkdau4uP XK72iP4RINNjkt7OZ+owWbz0klOAgfHfHy6qW6VrJbNiD289/80m982yPZ+unTu9RPbKWZ5u vzkFbYcqvDVXld3zmZZ9NeAz5+6f3euYRbQF/l3MVNjqLKq5/6wSS3FGoqEWc1FxIgD9spUa pgIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 16:42:26 -0000 SGkgU3RlZmZpDQoNCkluIHN1bW1hcnksIEkgdGhpbmsgaXQgaXMgYW4gaXNzdWUgdGhhdCB0aGUg YXV0aG9yaXphdGlvbiBwcm9ibGVtDQpmb3JtdWxhdGlvbnMgaW4gdGhlIHVzZSBjYXNlIGRvY3Vt ZW50IGRvZXMgbm90IHRha2UgaW50byBhY2NvdW50IHRoZSBhDQpwcmlvcmkgZGlmZmVyZW5jZSBi ZXR3ZWVuIHByb3ZpZGluZyBhY2Nlc3MgdG8gc2Vuc29yIG1lYXN1cmVtZW50cyB2cw0KYWNjZXNz aW5nIGEgc2Vuc29yIG1lYXN1cmVtZW50LiBPciBwcm92aWRpbmcgYWNjZXNzIHRvIGFuIGFjdHVh dG9yIHNlcnZpY2UNCnZzIGFjY2Vzc2luZyBhbiBhY3R1YXRvciBzZXJ2aWNlLiBGb3IgZXhhbXBs ZSwgdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbQ0Kb2Ygb3BlbmluZyBhIGxvY2sgb24gYSBzcGVj aWZpYyByZXF1ZXN0IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBwcm9ibGVtIG9mDQptYWtpbmcgc3Vy ZSB0aGF0IGl0IGlzIHRoZSByaWdodCBsb2NrIHRvIG9wZW4uIE9yIHJldmVhbGluZyB0byB0aGUg bG9jaw0KdGhhdCB5b3UgaW50ZW5kIHRvIG9wZW4gaXQuIE9yIHdoYXQgZXhhY3RseSBpcyB0aGUg cmVsZXZhbnQgcHJvYmxlbSBvbiB0aGUNCmFjY2Vzc2luZyBzaWRlPyBUaGlzIHdvdWxkIGJlIGdv b2QgdG8gY2xhcmlmeSBpbiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQuDQoNClRoZXJlIG1heSBiZSBk aWZmZXJlbnQgc29sdXRpb25zIHRvIHRoZSBwcm9ibGVtIG9mIHRoZSBwcm92aWRpbmcgc2lkZSBh bmQNCnRoZSBwcm9ibGVtIG9uIHRoZSBhY2Nlc3Npbmcgc2lkZS4gT3IgbWF5YmUgdGhlIHNhbWUg c3RhbmRhcmRpemVkIHNvbHV0aW9uDQpjYW4gYmUgYXBwbGllZCBpbiB0d28gaW5zdGFuY2VzPyBU byB1bmRlcnN0YW5kIHRoYXQgd2UgYWxzbyBuZWVkIHRvDQpmb3JtdWxhdGUgdGhlIHByb2JsZW1z Lg0KDQpGdXJ0aGVybW9yZSwgSSB0aGluayBpdCBpcyBhbiBpc3N1ZSB3aXRoIGEgdGVybWlub2xv Z3kgd2hpY2ggZG9lcyBub3QNCmFsbG93IHRoZXNlIGRpc3RpbmN0aW9ucyB0byBiZSBtYWRlIHNv IHRoYXQgdGhlIGRpZmZlcmVudCBwcm9ibGVtcyBjYW4gYmUNCmZvcm11bGF0ZWQuIEkgdGhpbmsg b25lIHBhcnQgb2YgdGhlIHRlcm1pbm9sb2d5IHByb2JsZW0gaXMgdGhhdCB0aGUgdGVybQ0K4oCc cmVzb3VyY2XigJ0gaXMgb3ZlcmxvYWRlZC4gRm9yIGV4YW1wbGUsIHJlc291cmNlIGlzIHVzZWQg KGEpIGluIHRoZQ0KUkVTVC9Db0FQIG1lYW5pbmcgd2hhdCBpcyByZXF1ZXN0ZWQgb24gdGhlIHNl cnZlciBzaWRlIGFuZCAoYikgIGFzIOKAnGl0ZW0NCm9mIGludGVyZXN04oCdLCB3aGljaCBjb3Vs ZCBiZSBhbnl0aGluZyBvbiBib3RoIHJlcXVlc3RpbmcgYW5kIHJlc3BvbmRpbmcNCnNpZGUuIFNp bmNlIHRoZSBleGlzdGluZyBhdXRob3JpemF0aW9uIGZyYW1ld29ya3Mgc3VjaCBhcyBPQXV0aCBh bmQgVU1BDQpoYXMgYSBidWlsdCBpbiBhc3ltbWV0cnkgYmV0d2VlbiBhdXRob3JpemluZyBwYXJ0 eSBhbmQgcmVxdWVzdGluZyBwYXJ0eSwNCnRoZSBidXJkZW4gb2YgcHJvb2YgZGV2aWF0aW5nIGZy b20gdGhhdCByZXN0cyB3aXRoIHRoZSBhdXRob3JzIG9mIHRoaXMNCmRyYWZ0LiBJdCBjb3VsZCBi ZSBhIGNvbmNsdXNpb24gb2YgdGhlIHVzZSBjYXNlIGRyYWZ0IHRoYXQgdGhpcyBpcyBhDQpzeW1t ZXRyaWMgcHJvYmxlbSwgYW5kIHRoYXQgdGhlIHByb2JsZW1zIG9uIGVhY2ggc2lkZSBpcyBvZiBl cXVhbA0KaW1wb3J0YW5jZS4gSXQgc2hvdWxkIG5vdCBiZSBhbiBhc3N1bXB0aW9uLg0KDQpJIHBy b3Bvc2VkIHRvIHN3aXRjaCB0ZW1wb3JhcmlseSB0byBhIGRpZmZlcmVudCB0ZXJtaW5vbG9neSBi YXNlZCBvbg0K4oCccHJvdmlkZXLigJ0gYW5kIOKAnHVzZXLigJ0gKGEgdmFyaWFudCBvZiB0aGF0 IHVzZWQgaW4gdGhlIFNFTlNFSSBwcm9qZWN0KSBqdXN0DQp0byBhdm9pZCB0aGUgcG90ZW50aWFs IHByb2JsZW0gd2l0aCBvdmVybG9hZGluZyB0aGUgdGVybSAicmVzb3VyY2XigJ0uIE1vcmUNCmNv bW1lbnRzIGlubGluZS4NCg0KDQoNCk9uIDIwMTUtMDEtMjYgMTU6MjMsICJTdGVmYW5pZSBHZXJk ZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj4NCj5PbiAwMS8y Ni8yMDE1IDA5OjI3IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBIaSBTdGVmZmksDQo+ Pg0KPj4gVGhhbmsgeW91IGZvciB5b3VyIHBhdGllbnQgZXhwbGFuYXRpb25zLiBJIGFtIGhhcHB5 IHRoYXQgd2UgYWdyZWUgdG8NCj4+bGVhdmUNCj4+IG91dCBkZXZpY2Ugb3duZXJzaGlwLg0KPj4N Cj4+IFJlZ2FyZGluZyB0aGUgcmVtYWluaW5nIGFyZ3VtZW50YXRpb24gSeKAmW0gc2FkIHRvIHNh eSB0aGF0IEnigJltIHN0aWxsIG5vdA0KPj4gY29udmluY2VkLiBJbiBzaG9ydDogSSB0aGluayB3 ZSBzaG91bGQgaGF2ZSBhIHRlcm1pbm9sb2d5IGluIHRoZSB1c2UNCj4+Y2FzZQ0KPj4gZG9jdW1l bnQgd2hpY2ggYWxsb3cgdXMgdG8gZXhwcmVzcyB0aGUgY29uY3JldGUgYXV0aG9yaXphdGlvbiBw cm9ibGVtcw0KPj5vZg0KPj4gdGhlIHVzZSBjYXNlcyBpbiB0ZXJtcyBvZiB0aGlzIHRlcm1pbm9s b2d5LiBJZiBJIHVuZGVyc3RhbmQgeW91IHJpZ2h0LA0KPj55b3UNCj4+IHNheSB0aGF0IHdlIGNh buKAmXQgZXhwcmVzcyB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBpbiB0ZXJtcyBvZg0KPj5S ZXNvdXJjZSwNCj4+IFJlc291cmNlIE93bmVyICg9IFJlc291cmNlIFByaW5jaXBhbCksIGV0Yy4g YmVjYXVzZSB3aG8gaXMgUmVzb3VyY2UNCj4+T3duZXINCj4+IG1heSBkZXBlbmQgb24gc29sdXRp b24uIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZW4gSSB0aGluayB3ZSBoYXZlIGENCj4+IHByb2Js ZW0uIEluIG15IG9waW5pb24sIGVpdGhlciB0aGUgdGVybWlub2xvZ3kgaXMgbm90IGFwcHJvcHJp YXRlLCBvcg0KPj4gdGhlcmUgaXMgc29tZSBwcm9ibGVtIHdpdGggdGhlIGFwcGxpY2F0aW9uIG9m IHRoZSB0ZXJtaW5vbG9neSB0byB0aGUgdXNlDQo+PiBjYXNlcy4NCj4+DQo+PiBUbyBlbGltaW5h dGUgdGhlIGZvcm1lciwgYWxsb3cgbWUgdG8gdGFrZSBhIHN0ZXAgYmFjayBhbmQgYXR0ZW1wdCBh DQo+PiBwcmVsaW1pbmFyeSB0ZXJtaW5vbG9neSB0byByZWFjaCBhIGNvbW1vbiBncm91bmQgb2Yg dW5kZXJzdGFuZGluZy4gTGV0DQo+Pm1lDQo+PiBrbm93IHRvIHdoYXQgZXh0ZW50IHdlIGNhbiBh Z3JlZSBvbiB0aGlzOg0KPj4NCj4+IEluIHRoZSB1c2UgY2FzZXMgd2UgZm9jdXMgb24g4oCcdGhp bmdzIiBsaWtlIHNlbnNvcnMgKHRlbXBlcmF0dXJlIHNlbnNvcnMsDQo+PiBoZWFydCByYXRlIHNl bnNvcnMgZXRjLikgYW5kIGFjdHVhdG9ycyAoZmFuIGFjdHVhdG9ycywgbG9jayBhY3R1YXRvcnMN Cj4+IGV0Yy4pOyBhbmQgcmVsYXRlZCBkYXRhIGxpa2Ugc2Vuc29yIG1lYXN1cmVtZW50cyAodGVt cGVyYXR1cmVzLCBoZWFydA0KPj4gcmF0ZXMsIGV0Yy4pIGFuZCBhY3R1YXRvciBzZXR0aW5ncyAo ZmFuIGNvbmZpZ3VyYXRpb24gc2V0dGluZ3MsIGxvY2sNCj4+IG9wZW4vY2xvc2VkLCBldGMuICku IEFsbCB0aGVzZSBhcmUgIml0ZW1zIG9mIGludGVyZXN0Iiwgb3IgImFzc2V0cyIgdGhhdA0KPj4g bmVlZHMgdG8gYmUgcHJvdGVjdGVkLCBzb21lIG9mIHdoaWNoIGlzIGluIHNjb3BlIG9mIHRoaXMg d29ya2luZyBncm91cC4NCj4+DQo+PiBJbiBvcmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRo ZSBwYXJ0eSBwcm92aWRpbmcgYSBzZW5zb3IvYWN0dWF0b3INCj4+IHNlcnZpY2UgYW5kIHRoZSBw YXJ0eSB1c2luZyB0aGUgc2VydmljZSB3ZSBjYW4gdXNlIHRoZSB0ZXJtaW5vbG9neQ0KPj4g4oCc cHJvdmlkZXLigJ0gKG9mIHNlbnNvci9hY3R1YXRvciBzZXJ2aWNlcykgYW5kIOKAnHVzZXLigJ0g KG9mIHNlbnNvci9hY3R1YXRvcg0KPj4gc2VydmljZXMpLiBPbmUgaW1wb3J0YW50IHNlY3VyaXR5 IHByb2JsZW0gaW4gc2NvcGUgb2YgdGhpcyB3b3JraW5nIGdyb3VwDQo+PiBkZWFscyB3aGljaCBk ZXZpY2VzIGFyZSBhbGxvd2VkIHRvIHJlYWQgZnJvbSBhIHNlbnNvciBvciB3cml0ZSB0byBhbg0K Pj4gYWN0dWF0b3IuIEluIGRldGFpbCB0aGlzIG1lYW5zIGZvciBleGFtcGxlIHRoYXQgYSBkZXZp Y2UgYXNzb2NpYXRlZCB0byBhDQo+PiB1c2VyIG1heSBvciBtYXkgbm90IOKAnHJlYWQiIG1lYXN1 cmVtZW50cyBmcm9tIGEgZGV2aWNlIGFzc29jaWF0ZWQgdG8gYQ0KPj4gcHJvdmlkZXIgb2Ygc2Vu c29yIHNlcnZpY2VzLiBBbmFsb2dvdXNseSBhIGRldmljZSBhc3NvY2lhdGVkIHRvIGEgdXNlcg0K Pj5tYXkNCj4+IG9yIG1heSBub3Qg4oCcd3JpdGUiIGFjdHVhdG9yIHNldHRpbmdzIHRvIGEgZGV2 aWNlIGFzc29jaWF0ZWQgd2l0aCBhDQo+PiBwcm92aWRlciBvZiBhY3R1YXRvciBzZXJ2aWNlcy4g IFRoZXJlIG1heSBiZSBvdGhlciBzZWN1cml0eSBwcm9ibGVtcyBhcw0KPj4gd2VsbCBhbmQgd2Ug c2hvdWxkIGxpc3QgdGhlbSBhbmQgZGVjaWRlIGlmIHRoZXkgYXJlIGluIHNjb3BlLg0KPj4NCj4+ IEFyZSB3ZSBPSyBvbiB0aGlzIGxldmVsPw0KPg0KPkkgZG9uJ3Qgc2VlIGhvdyB0aGlzIHRlcm1p bm9sb2d5IHdpbGwgaGVscCB1cyB3aXRoIHRoZSBhdXRob3JpemF0aW9uDQo+c29sdXRpb24uIElu IENvQVAsIHRoZSBzZXJ2ZXIgaXMgbm90IG5lY2Vzc2FyaWx5IHRoZSBzZW5zb3IvYWN0dWF0b3Iu DQo+VGhlIHByb3RlY3Rpb24gb2Ygc2Vuc29yIG9yIGFjdHVhdG9yIHZhbHVlcyBkb2VzIG5vdCBy ZWFsbHkgZml0IHRvIHRoZQ0KPnByb3RlY3Rpb24gb2YgQ29BUCByZXNvdXJjZXMgKHRoYXQgYXJl IGlkZW50aWZpZWQgYnkgYSBVUkkpLg0KPg0KPk1vcmVvdmVyLCBvbmUgb2YgdGhlIGVuZHBvaW50 cyBtYXkgYmUgYSBzZW5zb3Igd2hpbGUgdGhlIG90aGVyIG1heSBiZSBhbg0KPmFjdHVhdG9yIGFu ZCB3ZSB0aHVzIHdvdWxkIGhhdmUgdHdvIHByb3ZpZGVycy4NCg0KWWVzLCB0aGF0IGlzIGZpbmUu IFRoZXkgcHJvdmlkZSBkaWZmZXJlbnQgc2VydmljZXMuIElmIHdlIGhhdmUgYSBzb2x1dGlvbg0K dG8gdGhlICJwcm92aWRlciBhdXRob3JpemVzIHVzZXIgcHJvYmxlbSIgd2UgY2FuIGFwcGx5IGl0 IHR3aWNlLg0KDQo+DQo+SSBhZ3JlZSB0aGF0IHdlIHdhbnQgdG8gcHJvdGVjdCBpdGVtcyBvZiBp bnRlcmVzdC4gSWYgeW91IHdhbnQgdG8gY3V0DQo+ZG93biB0aGUgcHJvYmxlbSB0byAid2UgcHJv dGVjdCB0aGUgaXRlbSBvZiBpbnRlcmVzdCBieSBkZWZpbmluZyB3aG8gaXMNCj5hbGxvd2VkIHRv IHJlYWQvd3JpdGUgdGhlIGl0ZW0gb24gb25lIHNpZGUiIHlvdSBhcmUgb25seSBhZGRyZXNzaW5n IGhhbGYNCj5vZiB0aGUgcHJvYmxlbS4gV2UgZG9uJ3QgZ2V0IGFyb3VuZCB0aGUgcHJvYmxlbSB0 aGF0IHRoZXJlIG1heSBiZSB0d28NCj5wYXJ0aWVzIHdpdGggZGlmZmVyZW50IGludGVyZXN0cyBp bnZvbHZlZCBieSByZW5hbWluZyB0aGVtIG9yIGJ5IHRyeWluZw0KPnRvIGZpdCB0aGUgdXNlIGNh c2VzIHRvIGEgbW9kZWwsIHdoZXJlIGl0IGlzIGNsZWFyIHdoaWNoIHBhcnR5IHJlcXVlc3RzDQo+ YW5kIHdoaWNoIHBhcnR5IHByb3ZpZGVzIGFuIGl0ZW0gb2YgaW50ZXJlc3QuIFdlIHdpbGwgb25s eSBnYWluIGFuDQo+YXV0aG9yaXphdGlvbiBzb2x1dGlvbiB0aGF0IHJlc3RyaWN0cyB0aGUgcG9z c2liaWxpdGllcyBvZiBDb0FQLg0KPg0KPkkgZG9uJ3QgbGlrZSB0aGUgdGVybSAidXNlciIgc2lu Y2UgaXQgaW1wbGllcyB0aGUgcHJlc2VuY2Ugb2YgYSBodW1hbg0KPmJlaW5nLiBJIGRvbid0IGtu b3cgaWYgdGhhdCdzIHdoYXQgeW91IGhhdmUgaW4gbWluZD8NCg0KVGhlIHByZWxpbWluYXJ5IHRl cm1pbm9sb2d5IEkgcHJvcG9zZWQgd2FzIGEgdmFyaWFudCBvZiB0aGF0IHVzZWQgaW4gdGhlDQpT RU5TRUkgcHJvamVjdC4gSW4gdGhhdCBwcm9qZWN0IHdlIHVzZWQgdGhlIHRlcm1zIOKAnFJlc291 cmNlIFByb3ZpZGVy4oCdIGFuZA0K4oCcUmVzb3VyY2UgVXNlcuKAnSwgYnV0IEkgd2FudGVkIHRv IGF2b2lkIHRoZSBub3Rpb24gb2YgUmVzb3VyY2UgYXMgZXhwbGFpbmVkDQphYm92ZS4gSSBhZ3Jl ZSB0aGUgbm90aW9uIOKAnFVzZXLigJ0gaXMgbm90IHBlcmZlY3QuIEkgY2FsbGVkIHRoZSB0ZXJt aW5vbG9neQ0K4oCccHJlbGltaW5hcnnigJ0gYmVjYXVzZSBpdCB3YXMgaW50ZW5kZWQgYXMgYSBt ZWFucyB0byBnZXQgYXJvdW5kIHdoYXQgIHRoaW5rDQppcyBhbiBvdmVybG9hZCBvZiB0ZXJtcyBp biB5b3VyIGN1cnJlbnQgcHJvcG9zYWwuIFdlIGNvdWxkIG9mIGNvdXJzZQ0KcmVuYW1lIHRlcm1z LCBidXQgZm9yIG5vdyBpdCBpcyBqdXN0IGEgbWF0dGVyIG9mIGhhdmluZyB0ZXJtcyB0aGF0IGNs ZWFybHkNCmRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMuDQoNCjxz bmlwPg0KDQo+DQo+Pj4gTW9yZW92ZXIsIGluIGENCj4+PiBzY2VuYXJpbyB3aGVyZSB0d28gZGlm ZmVyZW50IHBhcnRpZXMgbWF5IGJlIGludm9sdmVkLCBvbmUgdGhhdCByZXF1ZXN0cw0KPj4+IGEg cmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlIGFuZCBvbmUgdGhhdCBwcm92aWRlcyB0aGUg cmVzb3VyY2UNCj4+PiByZXByZXNlbnRhdGlvbiwgdGhlc2UgdHdvIHBhcnRpZXMgbWF5IGhhdmUg ZGlmZmVyZW50IGludGVyZXN0cyBhbmQgdGh1cw0KPj4+IGhhdmUgZGlmZmVyZW50IHByb2JsZW1z IHRoYXQgbmVlZCB0byBiZSBzb2x2ZWQgYnkgYW4gYXV0aG9yaXphdGlvbg0KPj4+IHNvbHV0aW9u LiBUaHVzLCB0aGUgcmVzb3VyY2Ugb3duZXIncyBwcm9ibGVtcyBhcmUgbm90IHRoZSBvbmx5IHBy b2JsZW1zDQo+Pj4gd2UgbmVlZCB0byBjb25zaWRlci4NCj4+DQo+PiBXaGF0IHlvdSBqdXN0IHN0 YXRlZCBpcyB2ZXJ5IGNsb3NlIHRvIHRoZSBwb2ludCBJIHdhbnQgdG8gbWFrZS4gSXQgc2VlbXMN Cj4+IHdlIGFncmVlIHRoYXQgdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHBhcnR5 IHByb3ZpZGluZyBhbmQgdGhlDQo+PiBwYXJ0eSByZXF1ZXN0aW5nLiBUaGVyZWZvcmUgd2UgbmVl ZCBhIHRlcm1pbm9sb2d5IHRvIGRlc2NyaWJlIGhvdyB0aGlzDQo+PiBkaWZmZXJlbmNlIGFwcGxp ZXMgdG8gdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbXMgIChpbiB0aGUgc2VjdGlvbnMNCj4+IGVu dGl0bGVkIOKAnEF1dGhvcml6YXRpb24gUHJvYmxlbSBTdW1tYXJ54oCdIGluIHRoZSB1c2UgY2Fz ZSBkb2N1bWVudCkuDQo+DQo+SSBkb24ndCB0aGluayB0aGF0IHRoZXNlIGRpZmZlcmVuY2VzIGFw cGx5IHRvIHRoZSBzZWN1cml0eSBvYmplY3RpdmVzDQo+dGhhdCB0aGUgaW52b2x2ZWQgcGFydGll cyBtYXkgd2FudCB0byBhY2hpZXZlLiBBcyBhIHByaW5jaXBhbCwgSSBkb24ndA0KPmNhcmUgd2hl dGhlciBJIHJlcXVlc3QgYW4gaXRlbSBvciBwcm92aWRlIGFuIGl0ZW0uIFJlZ2FyZGxlc3Mgb2Yg dGhlDQo+c2V0dGluZyBJIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgbXkgc2VjdXJpdHkgb2JqZWN0 aXZlcyBhcmUgYWNoaWV2ZWQuDQoNCkkgc2VlIHR3byBxdWl0ZSBkaWZmZXJlbnQgcHJvYmxlbXM6 IEnigJltIGZpbmUgd2l0aCDigJxhdXRob3JpemF0aW9uIHRvDQpwcm92aWRlIGFuIGl0ZW3igJ0s IGkuZS4gdGhlIHByb3ZpZGVyIGF1dGhvcml6ZXMgYSB1c2VyIHdpdGggYW4gaXRlbS4gVGhpcw0K aXMgYW4gaW50ZXIgZG9tYWluIHByb2JsZW0gd2hpY2ggaXMgbmF0dXJhbGx5IG1hcHBlZCB0byBh IFJFU1RmdWwNCnJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wuIEkgaGF2ZSBhIHByb2JsZW0gd2l0 aCDigJxhdXRob3JpemF0aW9uIHRvIHJlcXVlc3QNCmFuIGl0ZW3igJ0gaS5lLiB0aGF0IHRoZSB1 c2VyIGF1dGhvcml6ZXMgaXRzZWxmIHRvIHNlbmQgYSByZXF1ZXN0IGZvciBhbg0KaXRlbS4gSSBz ZWUgdGhhdCBhcyBhIHVzZXIgZG9tYWluIGludGVybmFsIHByb2JsZW0gd2hpY2ggaXMgbm90DQpu ZWNlc3NhcmlseSBjYXN0IGluIGEgUkVTVGZ1bCByZXF1ZXN0L3Jlc3BvbnNlIG1lc3NhZ2UgZXhj aGFuZ2UuIEFuZCBpZiBpdA0KaXMsIHRoZW4gd2UgY2FuIHNvbHZlIGF1dGhvcml6YXRpb24gb2Yg UkVTVGZ1bCByZXF1ZXN0IGFuZCBhcHBseSBpdCB0d2ljZToNCk9uY2Ugb24gdGhlIGludGVyLWRv bWFpbiBwcm9ibGVtIGFuZCBvbmNlIG9uIHRoZSB1c2VyIGludGVybmFsIHVzZXIgZG9tYWluDQpw cm9ibGVtLg0KDQoNCj4NCj4+PiBGb3IgQ29BUCwgdGhlIGVudGl0eSB0aGF0IGNvbnRyb2xzIHRo ZSBhY2Nlc3MgcGVybWlzc2lvbnMgdG8gYSBDb0FQDQo+Pj4gcmVzb3VyY2Ugd2lsbCBsaWtlbHkg YmUgdGhlIHJlc291cmNlIG93bmVyLCBhbmQgdGh1cyB0aGUgb3duZXIgb2YgdGhlDQo+Pj4gZGF0 YSB0aGF0IGlzIHN0b3JlZCB0aGVyZS4gSWYgeW91IGFyZSB0cmFuc21pdHRpbmcgZGF0YSB0byB0 aGF0DQo+Pj4gcmVzb3VyY2UsIHlvdSBhcmUgdGhlIHJlc291cmNlIG93bmVyIGFzIGxvbmcgYXMg eW91IGNvbnRyb2wgdGhlIGFjY2Vzcw0KPj4+IHBlcm1pc3Npb25zIGZvciB0aGlzIHJlc291cmNl LiBJZiB5b3UgYXJlIHRyYW5zbWl0dGluZyBkYXRhIHRvIHNvbWVvbmUNCj4+PiBlbHNlJ3MgQ29B UCByZXNvdXJjZSB5b3UgYXJlIGdpdmluZyB1cCBvd25lcnNoaXAgZm9yIHRoaXMgY29weSBvZiB0 aGUNCj4+PiBkYXRhLg0KPj4gSSBhZ3JlZSB0aGF0IHNlbnNvciBhbmQgYWN0dWF0b3IgcmVsYXRl ZCBkYXRhIG5lZWRzIHRvIGJlIHNlY3VyZWQNCj4+IGVuZC10by1lbmQgYmV0d2VlbiB1c2VyIGRl dmljZSBhbmQgcHJvdmlkZXIgZGV2aWNlLCBhbmQgdGhhdCB0aGlzIGlzDQo+PnBhcnQNCj4+IG9m IHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW06IGFjY2VzcyBjb250cm9sIHRvIHNlbnNvciBkYXRh IG1heSBiZSBvZg0KPj4gbGltaXRlZCB2YWx1ZSBpZiBzZW50IGluIHBsYWluIHRleHQ7IGFjY2Vz cyBjb250cm9sIHRvIGFjdHVhdGlvbiBkYXRhDQo+PiBuZWVkcyB0byBiZSBpbnRlZ3JpdHkgcHJv dGVjdGVkLCBldGMuIEJ1dCBJ4oCZbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdA0KPj4geW91 IG1lYW4gd2l0aCAiZGF0YSBvd25lcnNoaXDigJ0uIFNlbnNvciBkYXRhIGlzIHByb3ZpZGVkIGlu IHByb3RlY3RlZA0KPj5mb3JtDQo+PiB0byBhbiBhdXRob3JpemVkIHVzZXIsIHdoYXQgdGhlIHVz ZXIgZG9lcyB3aXRoIHRoaXMgZGF0YSBpcyBiZXlvbmQgdGhlDQo+PiBzY29wZSBvZiB0aGlzIHdv cmtpbmcgZ3JvdXAsIGlzbuKAmXQgaXQ/IElzbuKAmXQgdGhhdCBtb3JlIGxpa2UgYW4gYWdyZWVt ZW50DQo+PiBiZXR3ZWVuIHRoZSBwYXJ0aWVzPyBJIGFzc3VtZSB5b3UgYXJlIG5vdCB0aGlua2lu ZyBvZiBkaWdpdGFsIHJpZ2h0cw0KPj4gbWFuYWdlbWVudC4NCj4NCj5JIGRvbid0IHRoaW5rIHRo ZSB0ZXJtICJ1c2VyIiBpcyBoZWxwZnVsIGhlcmUuIFRoZXJlIG1heSBiZSB0d28gZGV2aWNlcw0K PmNvbW11bmljYXRpbmcgd2l0aG91dCBhbnkgdXNlciBpbnRlcmFjdGlvbi4NCj4NCj5JIGFtIGp1 c3QgdHJ5aW5nIHRvIGV4cGxhaW4gdGhhdCB0aGVyZSBhcmUgdHdvIHBhcnRpZXMgaW52b2x2ZWQg aW4NCj5leGNoYW5naW5nIGFuIGl0ZW0gb2YgaW50ZXJlc3QuIEVhY2ggb25lIG9mIHRoZXNlIHBh cnRpZXMgbWF5IGhhdmUgdGhlaXINCj5vd24gc2VjdXJpdHkgb2JqZWN0aXZlcy4gVGhlIHNlbmRl ciB3aWxsIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlDQo+cmVjZWl2ZXIgaXMgYXV0aG9yaXpl ZCB0byBnZXQgdGhlIGRhdGEsIHRoZSByZWNlaXZlciB3aWxsIHdhbnQgdG8gbWFrZQ0KPnN1cmUg dGhhdCB0aGUgc2VuZGVyIGlzIGF1dGhvcml6ZWQgdG8gc2VuZCB0aGUgZGF0YS4NCj4NCj5JbiBh IGNvbmNyZXRlIHVzZSBjYXNlLCBJIHNlZSBubyBldmlkZW5jZSB3aG8gdGhlIHNlbmRlciBhbmQg d2hvIHRoZQ0KPnJlY2VpdmVyIHdpbGwgYmUuDQoNCk1heWJlIHRoaXMgaXMgYSByZWFzb24gd2h5 IHRoZSB0ZXJtaW5vbG9neSBpcyBub3Qgc3VpdGFibGU/IFRoZXJlIGlzIGENCmRpZmZlcmVuY2Ug YmV0d2VlbiB3aG8gaXMgcHJvdmlkaW5nIGEgc2Vuc29yL2FjdHVhdG9yIHNlcnZpY2UgYW5kIHdo byBpcw0KdXNpbmcgaXQuIEFuZCBleHByZXNzaW5nIHRoYXQgZGlmZmVyZW5jZSBhbGxvd3MgdXMg dG8gZWxhYm9yYXRlIG9uIHRoZQ0Kcm9sZXMgaW4gdGhlIHVzZSBjYXNlcy4NCg0KPg0KPj4NCj4+ PiBJZiB5b3Ugd2FudCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgb3duZXIgb2YgdGhlIGRhdGEgbmV2 ZXIgY2hhbmdlcyB5b3UNCj4+PiB3aWxsIGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlc291 cmNlIG93bmVyIGNhbiBjb250cm9sIHRoZSBhY2Nlc3MNCj4+PiBwZXJtaXNzaW9ucyBmb3IgdGhp cyBkYXRhIG9uIGFsbCBkZXZpY2VzIHdoZXJlIHRoZSBkYXRhIGlzIHRyYW5zbWl0dGVkDQo+Pj4g dG8uIEV2ZW4gaWYgZGF0YSBpcyB0cmFuc21pdHRlZCB0byBhIHJlcXVlc3RpbmcgY2xpZW50IHlv dSBhcmUgZ2l2aW5nDQo+Pj51cA0KPj4+IG93bmVyc2hpcCBmb3IgdGhlIGNvcHkgb2YgdGhlIGRh dGEgdGhhdCB5b3UgYXJlIHRyYW5zbWl0dGluZywgdW5sZXNzDQo+Pj55b3UNCj4+PiBjYW4gY29u dHJvbCBhY2Nlc3MgcG9saWNpZXMgZm9yIHRoZSBkYXRhIG9uIHRoZSBjbGllbnQuIFlvdSBtYXkg Y29udHJvbA0KPj4+IHlvdXIgb3duIGNvcHkgb2YgdGhlIGRhdGEsIGJ1dCBub3QgdGhlIGNsaWVu dCdzIGNvcHkuDQo+Pj4NCj4+PiBJIGRvbid0IHRoaW5rIGl0J3Mgc28gY2xlYXIgdGhhdCB0aGUg cGF0aWVudCBpcyBhbHdheXMgdGhlIHJlc291cmNlDQo+Pj4gb3duZXIgaW4gYSBoZWFsdGhjYXJl IHNjZW5hcmlvLg0KPj4gWWVzLCBhcyBJIG1lbnRpb25lZCBpbiBteSBwcmV2aW91cyBtYWlsIOKA nEluIFN3ZWRlbiwgdGhlIGNhcmVnaXZlciB3aWxsDQo+PnNldA0KPj4gYWNjZXNzIHBvbGljaWVz IOKAnC4gSXMgdGhlcmUgc29tZSBjb25mdXNpb24gYWJvdXQgdGhlIHRlcm0g4oCcY2FyZWdpdmVy 4oCdPyBJDQo+PiBtZWFudCB0aGUgYWRtaW5pc3RyYXRpdmUgcmVwcmVzZW50YXRpdmUgb2YgdGhl IGRvY3RvciBldGMuIC0gcm91Z2hseSB0aGUNCj4+IHNhbWUgYXMgeW91ciB0ZXJtIOKAnHByYWN0 aXRpb25lcuKAnS4NCj4NCj5JdCBzZWVtZWQgdG8gbWUgdGhhdCB5b3Ugd2FudGVkIHRvIHN1Z2dl c3QgdGhhdCB3ZSB1c2UgdGhlIHRlcm1pbm9sb2d5DQo+ZnJvbSBVTUEgd2hlcmUgaW4gb25lIHVz ZSBjYXNlIHRoZSBwYXRpZW50IGlzIHRoZSByZXNvdXJjZSBvd25lci4gSW4NCj50aGlzIGNhc2Ug dGhlIHBhdGllbnQgd291bGQgYmUgdGhlIG9uZSB0aGF0IGlzIGluIGNvbnRyb2wgb2YgdGhlIGFj Y2Vzcw0KPnBvbGljaWVzLg0KPg0KPlNvIHdlIGFncmVlIHRoYXQgaXQncyBub3QgY2xlYXIgd2hl dGhlciB0aGUgcGF0aWVudCBvciB0aGUNCj5jYXJlZ2l2ZXIvcHJhY3RpdGlvbmVyIGlzIHRoZSBy ZXNvdXJjZSBvd25lcj8NCg0KVGhlcmUgYXJlIGRpZmZlcmVuY2VzIGluIGxlZ2lzbGF0aW9uIGlu IGRpZmZlcmVudCBjb3VudHJpZXMgYW5kIHlvdSBtYXkNCmhhdmUgZGlmZmVyZW50IGFncmVlbWVu dHMgYmV0d2VlbiBwYXRpZW50IGFuZCBjYXJlZ2l2ZXIgZXRjLiBIb3dldmVyLCB3aXRoDQphIGdp dmVuIGxlZ2lzbGF0aW9uIGFuZCBhZ3JlZW1lbnQsIGl0IGlzIGNsZWFyIHdobyBpcyBwcm92aWRl ci4NCg0KPg0KPj4+IExldCdzIGFzc3VtZSB0aGF0IGluIHRoZSBwZXJzb25hbCBoZWFsdGgNCj4+ PiBtb25pdG9yaW5nIGNhc2UsIGEgcHJhY3RpdGlvbmVyIHJlY2VpdmVzIGRhdGEgZnJvbSBKb2hu J3MgaGVhcnQgcmF0ZQ0KPj4+IG1vbml0b3Igd2l0aCBoZXIgc21hcnRwaG9uZS4gSm9obiBpcyB0 aGUgb3duZXIgb2YgdGhlIGhlYXJ0IHJhdGUNCj4+PiBpbmZvcm1hdGlvbiB3aGlsZSBpdCBpcyBv biB0aGUgaGVhcnQgcmF0ZSBtb25pdG9yLiBIZSB3YW50cyB0byBjb250cm9sDQo+Pj4gd2hvIGlz IGFibGUgdG8gYWNjZXNzIHRoaXMgZGF0YS4gQnV0IEkgdGhpbmsgaXQgaXMgdW5saWtlbHkgdGhh dCB0aGUNCj4+PiBwcmFjdGl0aW9uZXIgd2lsbCBsZXQgSm9obiBjb25maWd1cmUgYWNjZXNzIHBv bGljaWVzIGZvciBkYXRhIG9uIGhlcg0KPj4+IGRldmljZS4gU2hlIGdhaW5zIG93bmVyc2hpcCBm b3IgaGVyIGNvcHkgb2YgSm9obidzIGRhdGEgc2luY2Ugc2hlIGlzDQo+Pj50aGUNCj4+PiBvbmUg dGhhdCBjb250cm9scyB0aGUgYWNjZXNzIHBvbGljaWVzLg0KPj4gSSBzZWUgdHdvIChvciBvbmUt YW5kLWEtaGFsZikgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBoZXJlLiBUaGUgZmlyc3QNCj4+IGF1 dGhvcml6YXRpb24gcHJvYmxlbSBpcyB3aXRoIEpvaG4gYXMg4oCccHJvdmlkZXLigJ0gb2Ygc2Vu c29yIG1lYXN1cm1lbnRzDQo+PmFuZA0KPj4gdGhlIHByYWN0aXRpb25lciBhcyDigJx1c2Vy4oCd LiAgVGhlIHNlY29uZCBwcm9ibGVtIGlzIHdpdGggdGhlIHByYWN0aXRpb25lcg0KPj4gYXMgcHJv dmlkZXIgKHRydXN0ZWQgcHJveHkpLCBidXQgaG93IHRoYXQgZGF0YSBpcyB1c2VkIGlzIG5vdCBk ZXNjcmliZWQNCj4+ICh0aGlzIGlzIHdoYXQgSSBtZWFudCBieSDigJxhbmQtYS1oYWxm4oCdKS4N Cj4+DQo+PiBJZiB3ZSBjYW4gaGF2ZSBhIHNvbHV0aW9uIHRvIGhvdyBhIHByb3ZpZGVyIGNhbiBz ZXQgcG9saWNpZXMgZm9yIGFjY2Vzcw0KPj50bw0KPj4gZGF0YSBhbmQgb25seSBncmFudCBhY2Nl c3MgdG8gYXV0aG9yaXplZCB1c2VycywgdGhlbiB3ZSBjb3VsZCBhcHBseSB0aGlzDQo+PiBzb2x1 dGlvbiB0d2ljZTogZmlyc3Qgd2l0aCBKb2huIGFzIHByb3ZpZGVyLCB0aGVuIHdpdGggdGhlIHBy YWN0aXRpb25lcg0KPj5hcw0KPj4gcHJvdmlkZXIuIE9mIGNvdXJzZSwgdGhlcmUgbXVzdCBiZSBh biBhZ3JlZW1lbnQgYmV0d2VlbiBKb2huIGFuZCB0aGUNCj4+IHByYWN0aXRpb25lciBhYm91dCB0 aGUgcHJhY3RpdGlvbmVyIGFjdGluZyBwcm92aWRlciBmb3IgdGhpcyBkYXRhLCBidXQgSQ0KPj4g ZG9u4oCZdCB0aGluayB0aGF0IGlzIGluIHNjb3BlIG9mIHRoaXMgd29ya2luZyBncm91cC4NCj4N Cj5Pa2F5LCBzbyB3ZSBhZ3JlZSB0aGF0IHdlIG5lZWQgYSBzb2x1dGlvbiB0aGF0IGFkZHJlc3Nl cyB0aGUNCj5hdXRob3JpemF0aW9uIHByb2JsZW1zIG9mIGJvdGggZW5kcG9pbnRzIGluIGEgY29u dmVyc2F0aW9uPw0KDQpBcyBtZW50aW9uZWQsIEkgc2VlIGluIHlvdXIgZXhhbXBsZSBhIHNlcXVl bmNlIG9mIHR3byBhdXRob3JpemF0aW9uDQpwcm9ibGVtcy4NCg0KTGV0IG1lIGFkZCB0aGF0IEkg ZmluZCB0aGUgZXhhbXBsZSBhIGJpdCAibWFkZSB1cCIuIFdoYXQgSeKAmW0gZmFtaWxpYXIgd2l0 aA0KZnJvbSBFcmljc3NvbiBNb2JpbGUgSGVhbHRoIGlzIHRoZSBjYXNlIHdoZW4gdGhlIGNhcmVn aXZlciBwcm92aWRlcyB0aGUNCmhlYWx0aCBtb25pdG9yIHNlbnNvciB0byB0aGUgcGF0aWVudCAo aW4gcHJhY3RpY2UgdGhlIHBhdGllbnQgZ2V0cyBhDQpicmllZmNhc2Ugd2l0aCBvbmUgb3IgbW9y ZSBzZW5zb3JzIGFuZCBhIGNlbGx1bGFyIGNvbW11bmljYXRpb24gbW9kdWxlKS4NClRoaXMgaXMg YSBtb3JlIG5hdHVyYWwgc2l0dWF0aW9uLCBiZWNhdXNlIHRoZW4gdGhlIGNhcmVnaXZlciBjYW4g YXNzdW1lIGENCmxhcmdlIHJlc3BvbnNpYmlsaXR5IGZvciB0aGUgbWVhc3VyZW1lbnQgaW5jbHVk aW5nIGVxdWlwbWVudCBtYWludGVuYW5jZQ0KYW5kIGluc3RydWN0aW5nIHRoZSBwYXRpZW50IGhv dyB0byBtYWtlIHRoZSBtZWFzdXJlbWVudCBpbiBhIGNvcnJlY3Qgd2F5DQpnaXZlbiB0aGUgZXF1 aXBtZW50IHVzZWQgZXRjLiBUaGlzIHNpdHVhdGlvbiBoYXMgbW9yZSBpbiBjb21tb24gd2l0aCB0 aGUNCnRyYWRpdGlvbmFsIHNldHVwIGJldHdlZW4gcGF0aWVudCBhbmQgY2FyZWdpdmVyLCBhbHRo b3VnaCB0aGUgcGF0aWVudCBpcw0KcmVxdWVzdGVkIHRvIHBlcmZvcm0gc2ltcGxlIHRhc2tzIHJl cGxhY2luZyBhIG51cnNlLiBIZW5jZSBhIHNpbWlsYXINCmFncmVlbWVudCBiZXR3ZWVuIHBhdGll bnQgYW5kIGNhcmVnaXZlciBpbiB0aGUgY291bnRyeSBpbiBxdWVzdGlvbiBjYW4gYmUNCmFwcGxp ZWQsIGluY2x1ZGluZyB3aG8gaGFzIHRoZSByaWdodHMgdG8gc2V0IGFjY2VzcyBjb250cm9sIHBv bGljaWVzLiBUaGUNCmV4YW1wbGUgeW91IHByb3ZpZGUgd2hlcmUgdGhlIHBhdGllbnQgb3ducyB0 aGUgaGVhcnQgcmF0ZSBtb25pdG9yIGFuZA0KdHJhbnNmZXJzIHJpZ2h0cyB0byB0aGUgc2V0IGFj Y2VzcyBwb2xpY2llcyB0byB0aGUgY2FyZWdpdmVyIHdvdWxkIGJlIGENCnF1aXRlIGRpZmZlcmVu dCBhZ3JlZW1lbnQuDQoNCg0KPg0KPj4+IFlvdSBtYXkgc2F5IHRoYXQgeW91IG9ubHkgd2FudCB0 byBzb2x2ZSBKb2huJ3MgcHJvYmxlbSwgaS5lLiBwcm90ZWN0aW5nDQo+Pj4gaGlzIG1lZGljYWwg ZGF0YS4gQnV0IHRoZW4geW91IGFyZSBub3QgY29uc2lkZXJpbmcgdGhlIHByYWN0aXRpb25lcidz DQo+Pj4gaW50ZXJlc3QuIFNoZSB3aWxsIHdhbnQgdG8gYmUgc3VyZSB0aGF0IG9ubHkgYXV0aG9y aXplZCBkYXRhIGlzDQo+Pj4gdHJhbnNtaXR0ZWQgdG8gaGVyIHNtYXJ0cGhvbmUuDQo+Pg0KPj4g V2hhdCBkb2VzICJhdXRob3JpemVkIGRhdGHigJ0gbWVhbj8gV2l0aCB0aGUgYXBwcm9wcmlhdGUg c2VjdXJpdHkgc2V0dXAsDQo+PnRoZQ0KPj4gc21hcnRwaG9uZSAodXNlciBkZXZpY2UpIGNvdWxk IGF1dGhlbnRpY2F0ZSB0aGUgaGVhcnQgcmF0ZSBtb25pdG9yDQo+PiAocHJvdmlkZXIgZGV2aWNl KSwgdmVyaWZ5IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGRhdGEsIHZlcmlmeSB0aGF0IGl0IGlzDQo+ Pm5vdA0KPj4gYSByZXBsYXkgb2YgYW4gb2xkIGNvbW11bmljYXRpb24sIHZlcmlmeSDigJxmcmVz aG5lc3MiIG9mIHRoZQ0KPj5jb21tdW5pY2F0aW9uDQo+PiBldGMuIEJ1dCBJIGd1ZXNzIHlvdSBt ZWFuIHNvbWV0aGluZyBlbHNlPw0KPg0KPkkgbWVhbnQgdGhhdCBwcmFjdGl0aW9uZXIgd2lsbCB3 YW50IHRvIGJlIHN1cmUgdGhhdCB0aGUgZGF0YSB0cmFuc21pdHRlZA0KPnRvIHRoZSBwcmFjdGl0 aW9uZXIncyBzbWFydHBob25lIHN0ZW1zIGZyb20gYW4gYXV0aG9yaXplZCBzb3VyY2UuDQoNCkl0 IGlzIHN0aWxsIG5vdCBjbGVhciB0byBtZSB3aGF0IGlzIGFuIOKAnGF1dGhvcml6ZWQgc291cmNl 4oCdIG1lYW5zLiBJDQppbWFnaW5lIHRoZSBwcm9jZXNzIG9mIGRldGVybWluaW5nIHdoYXQgaXMg YW4gImF1dGhvcml6ZWQgc291cmNl4oCdIGNvdWxkIGJlDQpxdWl0ZSBkaWZmZXJlbnQgZnJvbSBh dXRob3JpemluZyB0aGUgcHJhY3RpdGlvbmVyIHRvIGFjY2VzcyBwYXRpZW50IGRhdGE6DQpUaGUg cHJhY3RpdGlvbmVyIGRlY2lkZXMgd2hlbiB0byByZXF1ZXN0IGRhdGEgZnJvbSB0aGUgcGF0aWVu dHMgZGV2aWNlLCBpdA0KY291bGQgYmUgcGFydCBvZiB0aGF0IHByb2Nlc3MgdG8gc2VsZWN0IHdo aWNoIGRldmljZSB0byBhY2Nlc3MsIHRodXMNCuKAnGF1dGhvcml6aW5nIHRoZSBzb3VyY2XigJ0/ DQoNCj4NCj4+DQo+Pj4gSWYgeW91IHdhbnQgdG8gdXNlIENvQVAgZm9yIHRoZSB0cmFuc21pc3Np b24gb2YgdGhlIGRhdGEsIGl0IGlzIG5vdA0KPj4+ZXZlbg0KPj4+IGNsZWFyIHdoaWNoIGRldmlj ZSB3aWxsIGJlIHRoZSBjbGllbnQgYW5kIHdoaWNoIHdpbGwgYmUgdGhlIHNlcnZlci4gSXQNCj4+ PiBtaWdodCBiZSB1c2VmdWwgaWYgdGhlIGhlYXJ0IHJhdGUgbW9uaXRvciBpcyB0aGUgc2VydmVy IGFuZCB0aGUNCj4+PiBzbWFydHBob25lIGlzIHRoZSBjbGllbnQgdGhhdCByZXF1ZXN0cyBkYXRh LiBCdXQgaXQgbWlnaHQgYWxzbyBiZQ0KPj4+dXNlZnVsDQo+Pj4gaWYgdGhlIGhlYXJ0IHJhdGUg bW9uaXRvciBpcyB0aGUgY2xpZW50LiBJIGRvbid0IHNlZSBhIGdvb2QgcmVhc29uIHRvDQo+Pj4g cnVsZSBvdXQgb25lIG9mIHRoZXNlIHNldHRpbmdzLg0KPj4gTGV04oCZcyB0cnkgdGhlIHRlcm1p bm9sb2d5IGFib3ZlOiB0aGUgaGVhcnQgcmF0ZSBzZW5zb3IgaXMgYSAicHJvdmlkZXIgb2YNCj4+ IHNlbnNvciBkYXRhIiBhbmQgdGhlIHNtYXJ0cGhvbmUgaXMgYSAidXNlciBvZiBzZW5zb3IgZGF0 YSIuIERvZXMgdGhhdA0KPj5tYWtlDQo+PiBtb3JlIHNlbnNlPw0KPg0KPkhtLCBJIGRvbid0IHNl ZSBob3cgdGhpcyBoZWxwcyB1cy4gSWYgeW91IHdhbnQgdG8gYmUgYWJsZSB0byBkaXN0aW5ndWlz aA0KPnRoZSBwcmFjdGl0aW9uZXIncyBzZWN1cml0eSBvYmplY3RpdmVzIGZyb20gSm9obidzIHNl Y3VyaXR5IG9iamVjdGl2ZXMsDQo+d2UgY291bGQgc3RhdGUgdGhhdCBleHBsaWNpdGVseSBpbiB0 aGUgcHJvYmxlbSBzdW1tYXJ5Lg0KDQpJIHRoaW5rIHRoYXQgd291bGQgYmUgaGVscGZ1bC4NCg0K Pg0KPj4+IEkgZ3Vlc3MgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHJlZHVjZSBhbGwgYXV0aG9yaXph dGlvbiBwcm9ibGVtcyBpbiB0aGUNCj4+PiB1c2UgY2FzZXMgdG8gdGhlIHByb3RlY3Rpb24gb2Yg cmVzb3VyY2VzICh1bmxlc3Mgd2Ugc2F5IHRoYXQgd2UgaGF2ZQ0KPj4+IHJlc291cmNlcyBvbiBi b3RoIHNpZGVzIHdoaWNoIHdpbGwgcmVzdWx0IGluIGhhdmluZyB0d28gcmVzb3VyY2UNCj4+PiBv d25lcnMpLiBUaHVzIGl0IGlzIG5vdCBzdWZmaWNpZW50IHRvIG9ubHkgbGlzdCB0aGUgcmVzb3Vy Y2Ugb3duZXIncw0KPj4+IHByb2JsZW1zLiBUaGUgdXNlIGNhc2VzIG11c3QgYWxzbyByZWZsZWN0 IHRoZSBwcm9ibGVtcyBvZiB0aGUgb3RoZXINCj4+PiBpbnZvbHZlZCBwYXJ0eSwgcmVnYXJkbGVz cyBvZiBob3cgeW91IG5hbWUgdGhpcyBvbmUgKEkgdGhpbmsgeW91cg0KPj4+IHN1Z2dlc3Rpb24g d2FzIGNsaWVudCBvd25lcikuDQo+PiBJZiB0aGVyZSBpcyBhIHByb2JsZW0gd2l0aCB0aGUgd29y ZCDigJxyZXNvdXJjZeKAnSwgbWF5YmUgd2UgY291bGQgdGhpbmsgaW4NCj4+IHRlcm1zIG9mIOKA nGFzc2V0c+KAnS/igJxpdGVtcyBvZiBpbnRlcmVzdOKAnSAoZS5nLiB0aGluZ3MgYW5kIHJlbGF0 ZWQgZGF0YSkgb24NCj4+IHRoZSBwcm92aWRlciBzaWRlIGFuZCB1c2VyIHNpZGUgYW5kIGZvcm11 bGF0ZSB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcw0KPj4gaW4gdGVybXMgb2YgdGhlc2U/DQo+ DQo+QXQgc29tZSBwb2ludCB3ZSB3aWxsIGhhdmUgdG8gbWFwIGl0IHRvIENvQVAsIHNvIEkgZG9u J3QgdW5kZXJzdGFuZCBob3cNCj50aGlzIGV4ZXJjaXNlIHdvdWxkIGJlIHVzZWZ1bC4NCg0KQW4g YXR0ZW1wdCB0byB3b3JrIGFyb3VuZCB0aGUgY3VycmVudCBpc3N1ZSB3aXRoIHRoZSB0ZXJtaW5v bG9neS4NCg0KPj4+IFNpbmNlIHdlIGRvbid0IGtub3cgeWV0IHdoaWNoIHNvbHV0aW9uIHdlIHdp bGwgdXNlLCBpdCBtaWdodCBiZSBtb3JlDQo+Pj4gdXNlZnVsIHRvIG9ubHkgdXNlIENvQVAgdGVy bWlub2xvZ3k6DQo+Pj4NCj4+PiAqIEVuZHBvaW50OiBBbiBlbnRpdHkgcGFydGljaXBhdGluZyBp biB0aGUgQ29BUCBwcm90b2NvbC4gQ29sbG9xdWlhbGx5LA0KPj4+IGFuIGVuZHBvaW50IGxpdmVz IG9uIGEgIk5vZGUiLCBhbHRob3VnaCAiSG9zdCIgd291bGQgYmUgbW9yZSBjb25zaXN0ZW50DQo+ Pj4gd2l0aCBJbnRlcm5ldCBzdGFuZGFyZHMgdXNhZ2UsIGFuZCBpcyBmdXJ0aGVyIGlkZW50aWZp ZWQgYnkNCj4+PiB0cmFuc3BvcnQtbGF5ZXIgbXVsdGlwbGV4aW5nIGluZm9ybWF0aW9uIHRoYXQg Y2FuIGluY2x1ZGUgYSBVRFAgcG9ydA0KPj4+IG51bWJlciBhbmQgYSBzZWN1cml0eSBhc3NvY2lh dGlvbg0KPj4+DQo+Pj4gKiBDbGllbnQ6IFRoZSBvcmlnaW5hdGluZyBlbmRwb2ludCBvZiBhIHJl cXVlc3Q7IHRoZSBkZXN0aW5hdGlvbg0KPj4+IGVuZHBvaW50IG9mIGEgcmVzcG9uc2UuDQo+Pj4N Cj4+PiAqIFNlcnZlcjogVGhlIGRlc3RpbmF0aW9uIGVuZHBvaW50IG9mIGEgcmVxdWVzdDsgdGhl IG9yaWdpbmF0aW5nDQo+Pj4gZW5kcG9pbnQgb2YgYSByZXNwb25zZQ0KPj4+DQo+Pj4gQW5kIGlu IGFkZGl0aW9uICh0byBiZSBhYmxlIHRvIGFkZHJlc3MgdGhlIG93bmVyJ3MgaW50ZXJlc3QpOg0K Pj4+DQo+Pj4gKiBSZXNvdXJjZSBQcmluY2lwYWw6IFRoZSBzdWJqZWN0IHRoYXQgY29udHJvbHMg dGhlIGFjY2VzcyBwZXJtaXNzaW9ucw0KPj4+IGZvciBhIHJlc291cmNlLg0KPj4+IChzZXZlcmFs IHBlb3BsZSByZW1hcmtlZCB0aGF0IHRoZSB0ZXJtICJvd25lciIgaXMgbWlzbGVhZGluZykNCj4+ Pg0KPj4+ICogQ2xpZW50IFByaW5jaXBhbDogVGhlIHN1YmplY3QgdGhhdCBjb250cm9scyB0aGUg YWNjZXNzIHBlcm1pc3Npb25zDQo+Pj5mb3INCj4+PiBhIGNsaWVudC4NCj4+Pg0KPj4+ICogUHJp bmNpcGFsOiBBIHN1YmplY3QgdGhhdCBpcyBlaXRoZXIgYSByZXNvdXJjZSBvd25lciBvciBhIGNs aWVudA0KPj4+b3duZXINCj4+PiBvciBib3RoLg0KPj4+DQo+Pj4gSXQgbWlnaHQgYWxzbyBiZSBo ZWxwZnVsIHRvIGFkZCB0aGlzIHRvIHRoZSB0ZXJtaW5vbG9neToNCj4+Pg0KPj4+ICogUmVzb3Vy Y2U6IEFuIGl0ZW0gb2YgaW50ZXJlc3QNCj4+Pg0KPj4NCj4+IEFzIGEgc3VtbWFyeSwgSSB0aGlu ayB0aGUgbWFpbiBwdXJwb3NlIG9mIHRoZSB0ZXJtaW5vbG9neSBpbiB0aGUgdXNlDQo+PmNhc2UN Cj4+IGRvY3VtZW50IHNob3VsZCBiZSB0byBiZSBhYmxlIHRvIGV4cHJlc3MgdGhlIGNvbmNyZXRl IGF1dGhvcml6YXRpb24NCj4+IHByb2JsZW1zIGluIHN1ZmZpY2llbnQgZGV0YWlsLiBFLmcuIHdl IHNob3VsZCBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoDQo+PiBiZXR3ZWVuIHRoZSByb2xlIGFzc29j aWF0ZWQgdG8gdGhlIGRldmljZSByZWFkaW5nIHRoZSBzZW5zb3IgZGF0YSBmcm9tDQo+PnRoZQ0K Pj4gcm9sZSBhc3NvY2lhdGVkIHRvIGRldmljZSBmcm9tIHdoaWNoIHNlbnNvciBkYXRhIGlzIGJl aW5nIHJlYWQuIElmIHdlDQo+PmNhbg0KPj4gZG8gdGhhdCB3aXRoIHRoaXMgdGVybWlub2xvZ3ks IGZpbmUuIElmIG5vdCB0aGVuIHdlIHNob3VsZCBtYXliZSBzZWxlY3QNCj4+IGFub3RoZXI/DQo+ DQo+V2hhdCBkbyB3ZSBnYWluIGZyb20gYmVpbmcgYWJsZSB0byBkaXN0aW5ndWlzaCB0aGUgcm9s ZSBvZiB0aGUgZGV2aWNlDQo+dGhhdCByZWFkcyB0aGUgc2Vuc29yIGRhdGEgZnJvbSB0aGUgcm9s ZSBvZiB0aGUgZGV2aWNlIHRoYXQgaG9zdHMgdGhlDQo+c2Vuc29yIGRhdGE/IEhvdyBkbyB0aGUg cHJvYmxlbXMgb2YgdGhlIHByaW5jaXBhbHMgb2YgdGhlc2UgZGV2aWNlcw0KPmRpZmZlcj8NCg0K QXMgbWVudGlvbmVkIHRoZXkgYXJlIGEgcHJpb3JpIGRpZmZlcmVudCByb2xlcyB3aXRoIGRpZmZl cmVudA0KcmVzcG9uc2liaWxpdGllcy4gVGhlIG1vc3QgbmF0dXJhbCBjYW5kaWRhdGUgYXV0aG9y aXphdGlvbiBmcmFtZXdvcmtzIGRvDQpub3QgYXNzdW1lIHRoaXMgc3ltbWV0cnkuIFRoZSBidXJk ZW4gb2YgcHJvdmluZyBzeW1tZXRyeSByZXN0cyB3aXRoIHRoZQ0Kb25lIHRoYXQgY2xhaW1zIGl0 LiBBZGRpdGlvbmFsbHksIEkgdGhpbmsgdGhhdCBpdCBzaG91bGQgYmUgZGVtb25zdHJhdGVkDQpo b3cgYSBwb3RlbnRpYWwgc3ltbWV0cnkgaXMgdXNlZnVsIGluIHByYWN0aWNlIGFuZCBub3QganVz dCBhcyBhDQp0aGVvcmV0aWNhbCBjb25zdHJ1Y3Rpb24uDQoNCkJlc3QgcmVnYXJkcywNCkfDtnJh bg0KDQo+DQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0KDQo= From nobody Thu Jan 29 10:14:04 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 76BD21A1B5D for ; Thu, 29 Jan 2015 10:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 ul-Xh2e3xHF1 for ; Thu, 29 Jan 2015 10:13:55 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.82.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F0F1A1A1B for ; Thu, 29 Jan 2015 10:13:55 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 47973C0EA753B; Thu, 29 Jan 2015 12:13:54 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 2F59FC0EA7453 for ; Thu, 29 Jan 2015 12:13:54 -0600 (CST) Received: from [96.231.226.60] (port=50010 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YGtbF-0004Lq-GF; Thu, 29 Jan 2015 12:13:53 -0600 Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Thu, 29 Jan 2015 13:13:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <37F0744B-E6B9-4BEC-935F-091BBA0940CE@ieca.com> References: To: Kepeng Li X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.60 X-Exim-ID: 1YGtbF-0004Lq-GF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.2) [96.231.226.60]:50010 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Arguments to publish use case document as RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 18:13:56 -0000 On Jan 29, 2015, at 04:54, Kepeng Li wrote: > Hello all, >=20 > Recently in SACM WG, there were a lot of discussions about whether or = not > to publish their use case document as RFC: > http://www.ietf.org/mail-archive/web/sacm/current/msg02306.html >=20 > I understand that we discussed about this before in the mailing list = some > time ago. >=20 > I am sure that this issue will be raised again during the IESG review > stage or WGLC stage. >=20 > So, let=A1=AFs be prepared for it. >=20 > Could you provide any arguments why you think the draft should get > published as RFC if that's what you think or if you think it is fine = to > have this as > a WG draft that remains a guiding document that does not get = published. >=20 > Here are a few arguments for it: > 1) One obvious reason for having this as a WG draft (published or not) = is > that some felt their input wasn't considered when it was an individual > draft. > 2) Another reason is that it is nice to have it as an RFC for = reference > later on, but could a wiki provide a link to the expired draft just as > easily?=20 > 3) The use cases draft helps to frame the problem(s) being addressed = by > ACE proposals and is important for guiding future development and > recording the history of consensus about the scope of ACE work. > 4) A wiki is too dynamic and can=A1=AFt be trusted. I think this is a simple case of the WG deciding whether to push the use = case/requirements (uc/req) draft forward (after somebody asks for it to = be published, the chairs review it and agree it=A1=AFs ready, and it = successfully passes WGLC). If the WG wants it published I think it = ought to be darn well be published. There=A1=AFs no prohibition against = uc/req drafts that I=A1=AFm aware of *AND* it=A1=AFs an Informational = RFC after all it=A1=AFs *NOT* a standards track RFC. There ought to be = a lower bar for informational vs standards track and if there isn=A1=AFt = one then that=A1=AFs really the IESG=A1=AFs fault. To me the real question after deciding to publish is when to publish: = way before we get done with the protocol(s) or right before/same time as = the protocol(s). If we do it way before 1) we might end up needing to = change something in the uc/req based on something we discover later, 2) = we will need to reacquaint the IESG with the uc/req draft when pushing = the protocol through, 3) we might get a different set of IESGers for the = uc/req and protocol drafts that have differing =A1=B0issues=A1=B1 = causing all kinds of delays while we either get re-educated or = re-educate. If we publish at the same time, we run the risk of gotchas = later in the process and maybe some complaints if we drop like 8 drafts = at once on the IESG. I=A1=AFve seen it go both ways so we just need to = pick our poison and move out. Put me in the camp that thinks this uc/req draft should be published = now. For me, it really helped focus the WG=A1=AFs vision of what it = wanted and got folks talking - that=A1=AFs all good in my book; we=A1=AFll= get cross-area and IESG review earlier in the process to avoid gotchas = later (one can never completely avoid these but we might get the low = hanging fruit). To avoid a lot of the later uc/req draft woes maybe we = could do put some kind of disclaimer in the draft that says: 1) we = developed as an initial step in the WG, 2) it might be revised later = based on design discussions, and 3) we pushed it before the protocol = drafts for reasons x/y/z. Actually, I=A1=AFm not sure we need to put = this in the draft, but if it=A1=AFs in the Shepherd=A1=AFs write-up the = IESG and IETF LC reviewers ought to at least keep that in mind when = reviewing it later. spt > Anything else? >=20 > Thanks, > Kind Regards > Kepeng (as co-chair) >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jan 29 10:35: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 D10941A1BCC for ; Thu, 29 Jan 2015 10:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GJJZjmVwJJG for ; Thu, 29 Jan 2015 10:35:46 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180D91A1AC2 for ; Thu, 29 Jan 2015 10:35:46 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id z107so32169315qgd.10 for ; Thu, 29 Jan 2015 10:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; bh=AZwonfFOXdVeKahoUlKaABOVXmAufm2WW4JGePJXayw=; b=YWsA361AsoCKQQ/041PTqlT7Uw5hRqQmHna0AIPsDyqrZoVovKyFcK/w3cFPKdlbtF 5CoewX7Onc/pNj7D7gyPjcies+V6jjKWk/cTcS5SO9GuYsLueHJ6byxrSEo9AyDj00Im mqRcSvVcNcdDgzKOOQqbxnrmfGp6ts/PRpOBXaPzU0yOO4PEqoW3fYhz16vCs+zYKWoI 6DOJ/9GujlUtiXwEGT57xFrRNyhcA3E2qP6nrS2cJ4heYVWGp9C1bllz2koU3B3I8V4/ NZaGp9ZerJBqXbGzrEpEGnOdlhtouXLuDdTsB30WiLoWjbbwkxCl692PxWfvst10a7id rZnQ== X-Received: by 10.140.38.114 with SMTP id s105mr3711265qgs.106.1422556545110; Thu, 29 Jan 2015 10:35:45 -0800 (PST) Received: from [10.221.46.46] (mobile-166-172-056-038.mycingular.net. [166.172.56.38]) by mx.google.com with ESMTPSA id q8sm7753440qam.1.2015.01.29.10.35.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 10:35:43 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-30E8F3D3-004B-45E6-B3C4-9B8CED5D4011 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <72F7F5E3-5AFD-449D-9B91-53B5D2002306@gmail.com> Date: Thu, 29 Jan 2015 13:35:42 -0500 To: Sean Turner X-Mailer: iPhone Mail (11D257) Archived-At: Cc: Kepeng Li , "Ace@ietf.org" Subject: Re: [Ace] Arguments to publish use case document as RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 18:35:48 -0000 --Apple-Mail-30E8F3D3-004B-45E6-B3C4-9B8CED5D4011 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I read Sean's message in the archive (phone sync issues). The IESG has been= discussing whether or not use case drafts are necessary to publish. As suc= h, I'll argue for whatever the WG decides and your input, including argument= s are appreciated. Sean raised some good points on timelines of publication that I hope the WG c= onsiders. Thanks, Kathleen=20 Sent from my iPhone > On Jan 29, 2015, at 1:13 PM, Sean Turner wrote: >=20 > This message has no content. --Apple-Mail-30E8F3D3-004B-45E6-B3C4-9B8CED5D4011 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I read Sean's message in the archive (phone sync issues).  The IESG has been discussing whether or not use case drafts are necessary to publish.  As such, I'll argue for whatever the WG decides and your input, including arguments are appreciated.

Sean raised some good points on timelines of publication that I hope the WG considers.

Thanks,
Kathleen 

Sent from my iPhone

On Jan 29, 2015, at 1:13 PM, Sean Turner <turners@ieca.com> wrote:

This message has no content.
--Apple-Mail-30E8F3D3-004B-45E6-B3C4-9B8CED5D4011--