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/ * [email protected]
On Wed, Sep 1, 2010 at 6:48 PM, <[email protected]> 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
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
