User:Infinity Linden/OGP Trust Phase 0

From Second Life Wiki
Jump to navigation Jump to search

Important Note

  • This page describes the near term "trust objectives". In this context, "Near Term" means issues relating to features that already existed in Second Life in September 2008, and how they will be implemented to support non-Linden Agent and Region domains. Discussions regarding the future of Trust in OGP (including, but not limited to: Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc.) should be directed towards the OGP Trust Model page.

Introduction

todo: add introduction here. best done after the content is produced.

How We Authenticate Protocol Actors

simplified trust model

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

note: this diagram needs a bit of an update. it does a poor job describing how capabilities are trusted and it doesn't describe how client applications trust the region domain servers.

Authenticating Client Application Users to Agent Domain Servers

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the authentication section of the OGP specification. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the Open Grid Beta Viewers page.

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the --loginuri option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

Authenticating Client Applications to Region Domain Servers

Authenticating Agent Domain Servers to Region Domain Servers

Authenticating Region Domain Servers to the Agent Domain

Specific Issues With Linden Lab Software

Linden Lab Self Signed Certificate For Agent and Region Domain Authentication

Specific Issues With OpenSim Software

Self Signed Certificates for Agent and Region Domain Authentication

Proposed Registration Authority for OpenSim Operators

Specific Issues With PyOGP Software

Note: Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it

Discussions

Gridnauts IRC 12 Sept 2008

  • [11:28am] infinity__ joined the chat room.
  • [11:29am] Ter_AFK: hi infinity__
  • [11:29am] infinity__: hola amigos
  • [11:29am] infinity__: y amigas
  • [11:29am] infinity__: so whump was telling me there was a discussion about certs going on
  • [11:29am] infinity__: and though i usually don't like to admit it
  • [11:30am] infinity__: i was Bell Canada's rep to the X.509 committee for a while
  • [11:30am] infinity__: so i'm partially responsible
  • [11:30am] Saijanai: j'accuse
  • [11:30am] Ter_AFK: yes.    Essentially, the client uses libcurl which imports ./app_settings/CA.pem to validate the SSL cert
  • [11:31am] infinity__: cool. okay. that should be pretty easy to fix
  • [11:31am] infinity__: so when the client talks to the AD or the Region
  • [11:31am] infinity__: it doesn't use client side certs
  • [11:32am] infinity__: so you shouldn't have to have the big list of "approved roots"
  • [11:32am] infinity__: (to serve requests)
  • [11:32am] infinity__: but if you're making a request
  • [11:33am] infinity__: yeah... libcurl will freak if it finds an untrusted cert (or unless you turn cert checking off)
  • [11:33am] Ter_AFK: I was able to add my own CA to the end of CA.pem and get the client to talk with my self signed https server, however..    that's not scalable
  • [11:33am] infinity__: why not?
  • [11:34am] Ter_AFK: Lets say someone else wants to connect to my server..    they'll need it added to theirs as well
  • [11:34am] infinity__: hmm
  • [11:34am] infinity__: oh oh
  • [11:34am] infinity__: yeah the clients have cert checking turned on
  • [11:34am] infinity__: well
  • [11:34am] infinity__: nothing you can do about that
  • [11:34am] Ter_AFK: ..  so..    a list of trusted CA's would be good..  or potentially a LL CA signing service.
  • [11:34am] infinity__: it might be worth it to spin a root CA for the OpenSim community
  • [11:35am] infinity__: include that cert in the distro
  • [11:35am] infinity__: and have a process by which OpenSim operators can request a server cert
  • [11:35am] infinity__: or.. hmm... i wonder if freessl is still operating...
  • [11:36am] infinity__: in theory... you shouldn't need a new self-signed cert
  • [11:37am] infinity__: you need either a self-signed or a derived cert who's root is in the list of "trusted certs"
  • [11:37am] Ter_AFK: right.
  • [11:37am] infinity__: it's the same problem of getting the upsetting "i don't trust this web site's cert" dialog when doing https in yer favorite browser
  • [11:38am] Ter_AFK: I wouldn't object to running a CA signing service assuming that my CA ended up in the client's list of roots.  Yep.  It's the same issue.
  • [11:38am] infinity__: lemme check if "meave's cert shack and internet bait shop" is still in the list of trusted roots for Firefox
  • [11:39am] Ter_AFK: heh
  • [11:39am] infinity__: yeah.. so in a sense... you're running into the "problem as defined"
  • [11:39am] infinity__: X.509 was introduced to separate trust of your software provider from trust of the network operators
  • [11:40am] infinity__: so yeah... it's a touch of a pain...
  • [11:40am] infinity__: do you know about OpenCA?
  • [11:40am]•Ter_AFK goes to look
  • [11:41am] infinity__: it was a touch confusing to use, but slightly less confusing than OpenSSL command line options
  • [11:41am] infinity__: well.. actually very less confusing than OpenSSL... but don't tell Ben Laurie i said that
  • [11:42am]•Ter_AFK didn't find the OpenSSL command line options that confusing.. but used various tutorials and peicemeal web pages to figure it out
  • [11:42am] infinity__: and i'm gonna see if i can dig up some cert references from cryptonomicon.net
  • [11:43am] infinity__: yeah... look at recent examples... not the docs. i've found the docs are out of sync with the code, but recent examples tend to work well
  • [11:44am] Ter_AFK: ultimately, we must do one of three things here though..  locate a suitable signing CA (that the client accepts), start our own(and insert that into app_settings/CA.pem) and sign people's certs ourself, use a Linden CA
  • [11:45am] infinity__: well... of course.. if we were going to launch a Linden CA
  • [11:45am] infinity__: i wouldn't be able to mention it
  • [11:45am]•Ter_AFK nods
  • [11:46am] infinity__: but if we did... one might assume we would have a peering agreement requirement and acceptance of a cert policy and a certification practice statement
  • [11:46am] infinity__: so for some folk, such a CA would work
  • [11:46am] infinity__: but it would be nice to find a solution for peeps who just wanna put up a couple sims to do some testing
  • [11:46am]•Ter_AFK nods again
  • [11:47am] infinity__: or are philosophically unaligned with the Linden IPR stance
  • [11:47am] infinity__: we could just write up a statement about the problem, put it on the wiki, and wait for Gareth and Tao to deploy a solution
  • [11:47am] Ter_AFK: ZhaEwry any comments?
  • [11:48am] Ter_AFK: hehe
  • [11:49am] infinity__: okay... looks like Chris over at MozFound noticed the joke of a cert i put in their standard distro
  • [11:50am] infinity__: which is good 'cause it means they're taking this stuff much more serious than the old days
  • [11:50am] Ter_AFK: [11:50am] infinity__: and Ter_AFK... you're just using "stock" libcurl, right?
  • [11:51am] Ter_AFK: the client is using libcurl..    but I can't really dig into it to find out what it's using
  • [11:51am] infinity__: i'm starting to get curious if the old DoD certs are still distributed with it
  • [11:52am] infinity__: and
  • [11:52am] Ter_AFK: in .NET, I have cert validation turned off, but it doesn't resolve issues with the client doing things in SSL on OpenSimulator..  because the client has cert checking on...  and..  I have no idea where to go for a signing that would work with it.
  • [11:52am] infinity__: you saw this reference, right? http://curl.haxx.se/docs/sslcerts.html
  • [11:53am] infinity__: wait... our client has cert checking turned on? ++Leyla
  • [11:54am] infinity__: yeah... we need a "real" solution to this... not just the idea that we're going to turn cert checking off
  • [11:54am] Ter_AFK: routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed  on the debug console.
  • [11:54am] infinity__: yup
  • [11:54am] infinity__: that's OpenSSL getting angry
  • [11:54am]•Ter_AFK nods. A real solution would be needed. yep.
  • [11:54am] infinity__: hmm
  • [11:55am] infinity__: also
  • [11:55am] infinity__: we shouldn't be using SSL3, this is a new application of certiness... we should be using TLS with "real" ciphers
  • [11:55am] infinity__: and PFS turned on by default
  • [11:58am] infinity__: my recommendation is to build different profiles... one that has no cert checking between ad and region.. on that has it turned on and uses the official Linden root... another that references whatever cert is appropriate for a group of public AD/RD operators
  • [11:58am] infinity__: oh oh.. just dawned on me... maybe this is the kind of service we should be expecting the RD to provide
  • [12:00pm] infinity__: i'll pitch the powers that be here on a plan that has LL operating as an RA for an "official LL Partners that agree to honour permissions metadata" tree and a "recognized OpenSim operators" tree
  • [12:01pm] Ter_AFK: thanks.  If that means that we have to run a signing service..  then ok..  I'll pitch it to the devs also
  • [12:01pm] infinity__: that way we could delegate issuance of RD certs for folk like osgrid.net et al. to osgrid.net
  • [12:02pm] whump_: interop island is back up
  • [12:02pm] infinity__: then if people didn't like our process, they're more than happy to build a version of the OS viewer that has their root certs
  • [12:02pm] infinity__: same story as Firefox
  • [12:04pm] infinity__: cause the last thing i want is for people to think that the "proper" thing to do is to turn cert checking off
  • [12:04pm] infinity__: that's bad mojo
  • [12:04pm] Ter_AFK: heh
  • [12:04pm]•Ter_AFK  turned cert checking off in OpenSimulator to allow derez_avatar with vaak
  • [12:06pm] infinity__: yeah.. that's what i'm talking about... i totally understand why you did it, but it's bad long-term practice and all of us LL, OpenSim devs, Tao, Gareth, osgrid.net, etc. have to make it easy for folk to "do the right thing"
  • [12:29pm] Saijanai: infinity__: , BlueWall , Ter_AFK ,  would you like me to post this discussion in the OGP beta page?
  • [12:30pm] BlueWall: ++
  • [12:30pm] Ter_AFK: I'm ok with it..  but make sure infinity__ is before you do.
  • [12:30pm] Saijanai: KK
  • [12:30pm] infinity__: sure... i'm acually working on https://wiki.secondlife.com/w/index.php?title=User:Infinity_Linden/OGP_Trust_Phase_0 right now
  • [12:30pm] infinity__: i'm thinking it's for ONLY stuff that's gonna happen real soon
  • [12:30pm] infinity__: no discussion about MPEG.21, new permissions models, etc.
  • [12:31pm] infinity__: (i.e. we have those discussions elsewhere, this is for things we all pretty much agree on in the near term)
  • [12:31pm] Saijanai: well, for me, the best next step would be to port group IM into the AD
  • [12:31pm] infinity__: cool. good to know that kinda stuff
  • [12:32pm] Saijanai: with everyone realizing that it almost certainly won't survive but we need to get a handle on how it behaves
  • [12:32pm] infinity__: hey Sai... gimme about an hour to hack on the Phase 0 page
  • [12:32pm] infinity__: then post the discussion to the bottom of it
  • [12:33pm] Saijanai: KK
  • [1:01pm] infinity__: it was designed to support just that
  • [1:19pm] leyla: are we still looking at certs infinity?
  • [1:19pm] leyla: i think the viewer always checks
  • [1:28pm] infinity__: cool. that's what we're supposed to do
  • [1:29pm] infinity__: (check the cert for trust and validity)
  • [1:53pm] whump_: Ter_AFK: did you get your questions about Certs answered, or a least pointed towards a plan of action?
  • [1:54pm] Ter_AFK: Yes.  I pitched the action to the devs.
  • [1:55pm] whump_: cool
  • [1:55pm] Ter_AFK: thanks.  It gives me a track to run on.
  • [2:15pm] infinity__: hey Sai... i put the outline for "near term trust" up at https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Phase_0
  • [2:15pm] infinity__: if you wanna add the previous discussion to the discussion section at the bottom
  • [2:15pm] infinity__: i think you can edit that major section
  • [2:16pm] infinity__: while i edit the other major sections
  • [2:16pm] infinity__: just hit the edit links near the section titles
  • [2:16pm] infinity__: and not the one at the top of the page