[Opensim-dev] Interop

[Meadhbh Hamrick]

On Wed, Sep 1, 2010 at 9:47 PM,  <diva at metaverseink.com> wrote:
> Nice, Meadhbh, thank you for all the pointers!
> It seems like the work in VWRAP is pretty much in sync with the work
> OpenSim, configurations and all.
> Indeed, the only case that HG1.5 does not support is the federated trust
> model (c). (d) is in the realm of the client-driven HG2.0, which I doubt
> we'll ever get into because it needs serious client redesign -- but if we're
> ok with wrapping LL clients in proxies, like grider, then it's actually
> pretty easy because it's just a matter of using dlls from OpenSim in the
> client itself.

hmm... hmm... a lot to think about here. first off, lack of support
for model C is a deal killer for some people. one of the things i
wanted to do with OpenSim was pitch MSR on the idea of writing an
opensim extension that integrates it with Active Directory for
corporate trust goodness. but that work isn't funded yet; i want to
make sure i can participate in OpenSim before proposing that to MSR.

fwiw... morgaine dinova has been the most vocal proponent of the
"tourist model." but as far as i can tell, she's not an implementer,
so i don't know if it will ever see code. i'm trying to (at least)
document the use case and requirements for the client-mediated trust
model. they'll always be there for you to reference when the team gets
around to doing 2.0. heck, by that time we might have completed the
threeway dance between me, linden and opensim's legal peeps.

about LL and proxies... @cala and i were trying to come up with a term
to describe what linden thought was acceptable for proxies. we came up
with something like "client operated proxies" or something like that.
after a lot of back and forth with joe miller, we got him to mostly
agree that the feature that linden doesn't like about proxies is that
they may have access to other people's passwords. so the current
linden word is.. if the proxy is operated by the user, it's okay. i
think sai was doing some work on this with a croquet/cobalt to SL
gateway thing. but if the proxy is owned by someone else (like
ajaxlife or gareth nelson's opensim extensions) and it takes a user's
credentials and logs in as you, that's verboten.

i would hate to have to add mono support for the client; it's not like
it doesn't have enough dependencies already. but yeah, that might be
the way to move the proxy into each user's administrative control (and
thus avoid the wrath of LL's TPVP.)

-cheers
-meadhbh

>
> What I don't see below is the mechanism for actually making these trust
> models exist. Perhaps that is still being worked on in the "auth spec". Can
> you tell us what you have in mind, or point to a document that describes it?
> I would like to see how that is different/similar to the authentication
> mechanism that we have in HG1.5.
>
> Now we're talking!!!
> :-)
>
> Meadhbh Hamrick wrote:
>>
>> hi christa
>>
>> since you're new to the VWRAP list, you're probably unfamiliar with
>> the work on security models we've done over the last year.
>>
>> david lavine worked out a list of "deployment use cases" in
>> http://tools.ietf.org/html/draft-levine-vwrap-deploy-01 .
>>
>> that draft just expired, so we moved some of the salient points into
>> the most recent intro draft:
>> https://datatracker.ietf.org/doc/draft-ietf-vwrap-intro/ .
>>
>> other points are to be addressed in the upcoming draft of the "auth
>> spec" due out this month.
>>
>> you are welcome, at any point, to participate in this discussion on
>> the mailing list and at in-person events held at various IETF
>> meetings.
>>
>> if you have specific issues with the deployment or trust model for
>> VWRAP, you are encouraged to start a detailed technical discussion on
>> the VWRAP mailing list. or, if you don't have time, you can explain
>> your issues to john or daliah who i've seen participate on the list.
>>
>> if you wish to propose hypergrid's model as a trust option for VWRAP,
>> you should write a proposal and send it to the vwrap mailing list. or,
>> open a text editor and write an internet draft. it's actually not that
>> hard. john, david or myself can possibly tutor you through the
>> process.
>>
>> keep in mind that like many IETF standards, VWRAP defines mechanism,
>> and not policy. so when we describe an authentication technique, we're
>> not saying that that is the ONLY technique that a vwrap implementation
>> can support. ditto for trust models. but because we define mechanism,
>> we DO say the equivalent of "if you claim to be VWRAP compliant, and
>> you claim to support *such-and-such* trust model and auth scheme, you
>> have to do it like this..." (and then you reference the section of the
>> spec.)
>>
>> but like i said, we're supporting multiple "trust models" and
>> "deployment patterns" in VWRAP. you can find a synthesis of the three
>> distinct views that have come to light in the article by Bell, Levine
>> and Dinova @
>> http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf
>> (warning, PDF).
>>
>> (as a note... yes, we started with the concept of an agent domain, and
>> i think some people besides linden liked the idea, but as time went on
>> we got little agreement over which services should be in an agent
>> domain and which in a region. david / zha pointed out that at the end
>> of the day, you don't really need the domains if you have a
>> sufficiently robust trust model, and they were getting in the way of
>> consensus. so, we dropped them.)
>>
>> to recap, we're supporting the following use cases for server-to-server
>> trust:
>>
>> a. stand-alone : all services provided by a single organization that
>> trusts itself. in this use case, deployed services use minimal
>> authentication of peers within their own trust domain. the idea here
>> is that if all your services are hosted by machines that YOU operate,
>> you can simply give a list of IP addresses you're hosting services on.
>> or you could have an admin LAN that's trusted while the public
>> interface to client's required client auth, etc. note that in this use
>> case, services may be DEPLOYED on multiple hosts; but it's the "trust"
>> that's stand-alone
>>
>> b. the direct trust use case : in this use case, trust relationships
>> are explicitly enumerated. that is, a service is being operated on
>> host A in trust domain 1, and host B is being operated in trust domain
>> 2. trust domains 1 and 2 explicitly agree that A and B should trust
>> each other. you can ramp this up to include more than 2 hosts in more
>> than 2 trust domains, but the key here is that each service operator
>> has a list of other hosts it explicitly trusts. this may be
>> implemented in many ways: an IPSec VPN or by using client certs with
>> HTTP(S). but the key here is that each host has a list of other hosts
>> it trusts.
>>
>> c. the federated trust use case : in this use case, you have a central
>> trusted party that other parties explicitly trust and trust to make
>> good decisions about who else is trustworthy. this is akin to the
>> trust model behind X.509 PKIs with transitive trust. we think this is
>> the kind of trust model we would encounter in corporate or educational
>> environments. we assume it would leverage existing PKI systems like MS
>> Active Directory, etc.
>>
>> d. client-mediated trust use case (aka the tourist model) : the three
>> use cases above, it's the network services themselves who decide who
>> they trust. and these trust relationships are considered to be "long
>> lived." in other words, we think they'll last longer than a single
>> user session. but there's another option where the client establishes
>> trust relationships with each service provider, then tells them each
>> about each other. so you might have a simulation service in one trust
>> domain that doesn't know anything about a particular asset service in
>> another. but if the client establishes a trust relationship with both
>> of them, and at login-time contacts each of them, telling them to
>> trust each other on the client's behalf, then you've got the core of
>> the tourist model down. there's also been some talk about the
>> "semi-tourist" model where some services are client-mediated and
>> others are federated or direct or what have you.
>>
>> e. nil trust : welcome to the intarwebs! in the nil trust model, all
>> security is by obscurity. if a user agent or a peer service can get to
>> you, you trust it. not recommended for public use unless you want to
>> turn your virtual world into the equivalent of a spam laden wiki. but
>> for people who want to operate a virtual world inside a corporate
>> network, they may be okay with trading trust for ease of use. ymmv.
>>
>> anyway, so these are the five basic use cases. the upcoming draft maps
>> each one to a collection of mechanisms for carrying information about
>> trust.
>>
>> with help from john hurliman, david levine and dahlia tremble, we were
>> able to extract a number of salient points re HG trust. one critique
>> of the HG security model is that it seemed to support no option for
>> federated trust. this was a bit of a deal killer for some
>> participants; but perfectly acceptable to others.
>>
>> it would have been nice if there were multiple trust model options in
>> OpenSim, but hey, you boil the ocean one thimble at a time. i
>> encourage you to look at the upcoming auth & trust model draft ( i
>> think it's due out on the 17th of september or the 1st of october. )
>> we're documenting trust models that may not have been early
>> requirements for OpenSIm or HyperGrid. they're being documented for
>> the purpose of being referenced by other people.
>>
>> also, the next document we draft need not be the last. if there are
>> glaring omissions or if we document some bit of the trust model in a
>> way that makes it difficult or impossible for HyperGrid to be
>> represented with it, PLEASE let us know.
>>
>> but, we're behind schedule on a lot of the drafts, and we simply ask
>> that you participate on the mailing list with clear comments sooner
>> rather than later.
>>
>> -cheers
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh at gmail.com
>>
>>
>>
>> On Wed, Sep 1, 2010 at 6:48 PM,  <diva at metaverseink.com> wrote:
>>>
>>> [Changing the subject; long email full of technical and historical
>>> details;
>>> should perhaps cross-list to vwrap, but the chair there doesn't like
>>> cross-postings, understandably; I don't know how to solve that, so goes
>>> here
>>> only for now...]
>>>
>>> OGP was a nice demo, and certainly had a lot of impact because it pointed
>>> towards what people wanted. It was incomplete, and the agent domain part
>>> was
>>> never made available for people to use on their own grids. But those
>>> weren't
>>> the only problems, they weren't even the major problems... The only
>>> reason
>>> why that demo worked at all was because OpenSim, at the time, was a
>>> _complete_security_hole_! :D
>>>
>>> Basically, if you had a modified client that would make a certain remote
>>> call into any OpenSim out there, it would create an agent on the sim,
>>> without asking any questions. In other words, you could enter any grid
>>> bypassing credential checks altogether. That's how logins and TPs worked
>>> when I started playing with OpenSim. A couple of people noticed this at
>>> some
>>> point or another, and sent us private bug reports. I'm saying this now,
>>> because this affects very old versions of OpenSim that probably no one is
>>> running anymore -- I hope!
>>>
>>> The very first version of HG1.0 exploited the same vulnerability. Later,
>>> I
>>> added a session check across the board, which would at least verify that
>>> there was some sort of authority on the sending side, and that such
>>> authority would confirm the existence of that session. I'm not sure
>>> people
>>> were still using OGP at this point, but OGP would have stopped working
>>> with
>>> this session check, because I didn't have access to the agent domain code
>>> in
>>> order to add this check to it.
>>>
>>> The Hypergrid progressed empirically by me identifying all these security
>>> holes and, basically, fix them. The holes were the path to the solutions
>>> --
>>> I didn't have to make anything up!
>>>
>>> I think the people who did OGP had conscience of how broken that
>>> SL/OpenSim
>>> demo was, and knew it needed a whole lot more. Documents out there
>>> explain
>>> what they were thinking about (e.g.
>>> http://wiki.secondlife.com/wiki/Structural_Design).
>>>
>>> There are many similarities between what they were thinking and HG1.5.
>>> What
>>> that extended protocol is missing is the authentication between the
>>> multiple
>>> parties involved: what they call the Region domain (similar to the
>>> Gatekeeper), what they call the Agent domain (similar to the user agent
>>> service), the region itself, and the viewer. *And authentication is the
>>> critical piece for making this secure.*
>>>
>>> Since they didn't seem to have any solution for the multi-party
>>> authentication problem, that led to the initial idea that interop could
>>> never be true S4S, but would have to have some sort of real-world
>>> authority
>>> that would establish and enforce the rules of engagement in a federation
>>> of
>>> VWs -- that would make the nasty problem of authentication go away with
>>> the
>>> addition of lawyers!
>>>
>>> Melanie and I figured out how to make the multi-party authentication
>>> work.
>>> It's basically a series of data flows and verifications that rely 100% on
>>> the basic Internet architecture -- DNS and TCP/IP addresses -- and on the
>>> social organization that we can expect on top of this architecture.
>>> Nothing
>>> fancy, really, just back to the basics. And it works. This is not the
>>> only
>>> way to solve the multi-party authentication problem, but it's probably
>>> the
>>> simplest.
>>>
>>> HG1.5 is fairly secure, there's only a couple of obscure corner cases.
>>> It's
>>> more complicated and unsafe than it needs to be, if we had a client that
>>> would cooperate and do the right things. The LL client is a major
>>> fixed-point in this, it restricts a lot what we can do.
>>>
>>> But I've started to like the LL client like it is. Call it Stockholm
>>> syndrome! :D
>>> There's an interesting thing about the LL architecture: the client talks
>>> only to the server(s) that it connects to, and not to the resource
>>> servers
>>> directly. We hate this, of course. But this is how web browsers work too
>>> --
>>> or at least how they are forced to work by web servers. When you get a
>>> page
>>> from a site, the resources you are allowed to get via the dynamic
>>> connections are only from that site, and not others (the origin
>>> restriction). So if someone would ever do a Web-browser-based rendering
>>> engine (something I would love to see!) we would be dealing with
>>> essentially
>>> the same situation that we are dealing now. Think about it!
>>>
>>>
>>> Justin Clark-Casey wrote:
>>>>
>>>> On 01/09/10 14:56, Mike Dickson wrote:
>>>>>
>>>>> More on OGP below.
>>>>>>
>>>>>> Like Diva, I also think that good standards very often only come out
>>>>>> of working implementations. Hence, though I've
>>>>>> been following the VWRAP lists (and OGP before that) I haven't been
>>>>>> participating since there's been a lot of
>>>>>> hard-to-follow discussion without much real-world consequence. And as
>>>>>> a working developer I don't have the luxury of
>>>>>> sitting on my tush and contemplating the Platonic world of future
>>>>>> standards all day ;) (joking).
>>>>>
>>>>> This is really the issue that has always bothered me. There's been an
>>>>> assertion that working code was more important than "standards". Truth
>>>>> is, standards are hard work, its more fun to hack code. And there *was*
>>>>> an existing implementation. LL and IBM demonstrated some limited cross
>>>>> grid functionality (hence the OGP work). And asserting politics was an
>>>>> issue is just lame. Linden Labs put forward a *working* system as a
>>>>> starting point along with some jointly developed code demonstrating
>>>>> limited interoperability. The code was even available to the OpenSim
>>>>> team. So if there was a "political agenda" it was on both sides. LL
>>>>> wanting to preserve some compatibility with their existing system (but
>>>>> willing to consider changes) and on the HyperGrid side a desire to
>>>>> explore and research ideas.
>>>>>
>>>>> What still remains is the hard work of creating a standard that defines
>>>>> interoperability. It would be great to see that progress, along with
>>>>> the
>>>>> code.
>>>>
>>>> I certainly agree that standards are hard work, which is why creating
>>>> them
>>>> without reference to any working examples seems an almost impossible
>>>> task to
>>>> me.  But that's just my own opinion which is not burdened by decades of
>>>> experience :)
>>>>
>>>> I also have to echo what Dahlia said earlier.  OGP was extremely
>>>> limited,
>>>> afaik being nothing beyond transporting an avatar name to a 'default'
>>>> avatar
>>>> on another grid.  There was no other identity or appearance
>>>> preservation,
>>>> let alone access to inventory - all extremely tough problems to address
>>>> in
>>>> any scalable or secure manner.
>>>>
>>>> Dahlia's phrase "OpenSim community" rather than "OpenSim team"
>>>> illuminates
>>>> very well the structures in play here.  In terms of the core group, I
>>>> wouldn't say that we were a team as such but more a community of people
>>>> with
>>>> a reasonably common set of interests who agree to abide by certain norms
>>>> and
>>>> a few rules.  There was never really an "OpenSim team" to respond to OGP
>>>> proposals.  Rather, some people were interested in it and implemented
>>>> the
>>>> required bits and pieces and other people were ambivalent or more
>>>> interested
>>>> in alternative architectures.
>>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>