Re: [ogpx] Protocol for permitting policy decisions

Morgaine <morgaine.dinova@googlemail.com> Fri, 09 October 2009 04:41 UTC

Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EAF3A6403 for <ogpx@core3.amsl.com>; Thu, 8 Oct 2009 21:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.582
X-Spam-Level:
X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBu7CXRXBZA7 for <ogpx@core3.amsl.com>; Thu, 8 Oct 2009 21:41:19 -0700 (PDT)
Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id DADFD3A635F for <ogpx@ietf.org>; Thu, 8 Oct 2009 21:41:18 -0700 (PDT)
Received: by ewy4 with SMTP id 4so301911ewy.37 for <ogpx@ietf.org>; Thu, 08 Oct 2009 21:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Fa4/w0ZfE0p37fKpNQDhozabGTmVrV636lVPeuoF5rk=; b=SrFf+1Gizjs1E0QNGkJOyKqbUUd44Qmr84GuGe7XyjU8VKXITtaf7Y/LN8DIFc37Ja AxX21hZE2zlW1x0JthxwVCdwjMAKCecfNxW1bdOeuE/HaMpH5w7cf7Ge6DPm+CqMoSJM ubiEY3kX0NFzX7gV3hacNiQkVr6aRe/Oaudgs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iS4rL8L6/EzBnB0R4Cl8LiiPqg/BQudYoGwzcsiTZaDgwFDQ+zcTxq2avYp8Ma3Ftq pply8xFUeH+l/JFxqKWmHpXCINSW6giCl23UQnyzv7tc9tv/pOz1iZNo705rmdVrFn+z x9rku4Hdy9TAZVNJ1nU7ckAara2Vrg9FU/h3U=
MIME-Version: 1.0
Received: by 10.210.2.19 with SMTP id 19mr2555365ebb.94.1255063380323; Thu, 08 Oct 2009 21:43:00 -0700 (PDT)
In-Reply-To: <OFAF7E773D.828624D6-ON8525764A.001736F4-8525764A.0017813A@us.ibm.com>
References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <e0b04bba0910080241x548b6ff9tbc558aaa069b15be@mail.gmail.com> <20091008235638.GE13882@alinoe.com> <e0b04bba0910082110r120148e7ua6975a110890651a@mail.gmail.com> <OFAF7E773D.828624D6-ON8525764A.001736F4-8525764A.0017813A@us.ibm.com>
Date: Fri, 9 Oct 2009 05:43:00 +0100
Message-ID: <e0b04bba0910082143o4bc0a47ckdaa39f3cbe00ece7@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: David W Levine <dwl@us.ibm.com>
Content-Type: multipart/alternative; boundary=000e0cdff6f6f46d49047579368f
Cc: "ogpx@ietf.org" <ogpx@ietf.org>
Subject: Re: [ogpx] Protocol for permitting policy decisions
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2009 04:41:21 -0000

A big +1, David!

And yet, despite knowing that non-local policy enforcement is a fiction
because it's *services* that express policy, I still see people attached to
the delusion that a safe, protected environment will be achieved through
some kind of transitive or viral contagion of local policy to create a
widespread non-local policy, as if domains spread policy by contact.

The implication permeates this thread, and we're going to have to examine it
in detail to see who is right.


Morgaine.




=====================================

On Fri, Oct 9, 2009 at 5:16 AM, David W Levine <dwl@us.ibm.com> wrote:

>
> I actually kind of defy anyone to impose a policy on a separately hosted
> remote service. Policy is enforced locally, Attempting to make other
> software components obey a
> policy you have is pretty much a non starter. You can request they do
> things, and you can insist they exhibit certain properties when choosing to
> interact with them, but
> you get no say in their workings.  (Yes, there are systems with remote
> policy execution engines and such, but they still don't impose the policies
> on the services which use
> them, the services chose to invoke them)
>
> - David
> ~ Zha
>
>
>
>
>
>  *Morgaine <morgaine.dinova@googlemail.com>*
> Sent by: ogpx-bounces@ietf.org
>
> 10/09/2009 12:10 AM
>   To
> "ogpx@ietf.org" <ogpx@ietf.org>
>  cc
>   Subject
> Re: [ogpx] Protocol for permitting policy decisions
>
>
>
>
> On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*<carlo@alinoe.com>>
> wrote:
>
> Morgaine,
>
> I'm pretty sure nobody on this list wants AD2 to be involved in anyway.
>
>
> Yes, I think that everybody agrees with this, which is why I'm making sure
> that the implications are understood.
>
> I am highlighting this point of logic very strongly so that it is clear to
> everyone that *if we don't want AD2 to be consulted, then AD1 cannot be
> allowed to express region policy*.  *AT ALL.  EVER.*  UNDER ANY
> CIRCUMSTANCES.
>
> Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be
> consulted, :-)
>
> I hope we can end this here with total agreement. :-)
>
> I will however be referring back to this point if someone tries to give AD1
> the power to set region policy over RD2.  If that happens, then we're back
> to consulting AD2, no alternative, because W2 is not in any way inferior to
> W1.
>
> It's a crucial point, because it establishes *a limit to the power of an
> AD*.  Think of it as a mini Constitution. ;-)
>
>
> Morgaine.
>
>
>
>
>
>
>
>
> ===================================
>
>
> On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*<carlo@alinoe.com>>
> wrote:
> On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote:
> > Magnus,
> >
> > If ADs are involved in region policy, then in the multi-world deployment
> > pattern, AD2 will have to be consulted when agent A1 teleports from RD1
> to RD2,
> > because AD2 will be involved in region policy too.  It's symmetric with
> AD1.
>
> Morgaine,
>
> I'm pretty sure nobody on this list wants AD2 to be involved in anyway.
> I'm also convinced that there is some misunderstanding involved here,
> and it would be good to correct that...
>
> The following isn't consensus yet, but I feel it's basically the truth,
> and written down here as such because at least it is simple:
>
> In the end there are only services. Services can be grouped as 'domain'
> to make clear they are run by the same authority and therefore likely
> will have use the same policies, but for the sake of the protocol you
> can ignore that.
>
> There are several types of services, so far we only concentrated on two
> types:
>
> 1) A region (R1, R2, ...)
> 2) An authentication service (A1, A2, ...)
>
> in principle, every service can be run by a different authority and thus
> have different policies.
>
> One user only uses a single authentication service at a time, every other
> authentication service is not relevant (for that user).
>
> If a user wants to teleport from R1 to R2, while using A3, only A3 and R2
> have a say in this.
>
> The only say that A3 has is true or false: yes or no allow the user to go
> to R2. Once the user gets into R2, no policy of A3 matters anymore.
>
> It makes no sense whatsoever to group A's with R's for the sake of
> understanding
> or designing the protocol.
>
> For a teleport decision (or initial connect) only ONE Agent service and ONE
> region are involved.
>
> Almost every policy (of both parties) can be negotiated out of band,
> yet some of us (including me) are arguing that we need to keep the
> possibility
> open for a region to change some abstract policies (based on trusted
> information
> from the agent service) more real-time. Here trust is needed in both
> directions:
> the region must trust the agent service to answer it's questions correctly
> and the agent service must trust the region not to fool it into allowing
> users in that the agent service based on it's own policy doesn't want to
> allow in.
>
> --
> Carlo Wood <*carlo@alinoe.com* <carlo@alinoe.com>>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>