Difference between revisions of "User:Infinity Linden/OGP Trust Phase 0"

From Second Life Wiki
Jump to navigation Jump to search
(Replacing page with 'this proposal has been deprecated')
Line 1: Line 1:
deprecated
this proposal has been deprecated
 
=Introduction=
 
This page describes "near term" trust mechanisms for OGP protocol participants. The objective is not to define the ultimate trust or security system, or even to try to enumerate all trust issues; for that, please visit the [[User:Infinity_Linden/OGP_Trust_Model|OGP Trust Model Page]]. This page is intended to describe "near term" trust issues and how participants in the OGP Beta program may use features that currently exist to establish "trust" between region and agent domains. So.. the [[User:Infinity_Linden/OGP_Trust_Model|OGP Trust Model Page]] is where you will find information regarding Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc. This page is where you'll find discussions regarding how client applications, agent domains and region domains establish a base level of trust through the use of X.509 certificates used in conjunction with TLS / HTTPS.
 
'''todo:''' continue fleshing out this section. maybe add links to "howtos" when we've reached agreement between LL, OpenSim, PyOGP
 
=How We Authenticate Protocol Actors=
[[Image:Sl2008 simplified trust 01.jpg|thumb|300px|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.
 
==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 [[OGP_Authentication_Draft_3|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_Public_Beta/Open_Grid_Beta_Viewers|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 <code>--loginuri</code> 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==
 
Region domain servers SHOULD NOT make "sensitive" services available to unauthenticated clients.
 
Client Applications use the possession of a capability by the client as proof of authorization to perform a particular operation.
 
Ergo, if you operate a Region Domain, do not issue sensitive caps to a client directly. Give the sensitive cap to an agent domain and let it give the cap to the client.
 
==Authenticating Agent Domain Servers to Client Applications==
 
Hosts implementing the agent domain portion of OGP SHOULD make services available via HTTPS / TLS. As mentioned above, Linden Lab servers will reject some protocol interactions if they do not take place over HTTPS (or some other secure transport).
 
Before trusting an Agent Domain server, Client Applications SHOULD check the following to ensure that the server being communicated with is actually the Agent Domain server that it claims to be:
 
* if the server's server certificate uses an IP address as part of the X.509 Subject Name, is this the same IP address the peer is using? (i.e. - does the IP address of the server match the IP address in the X.509 Subject Name?)
* if the server's server certificate uses a DNS Fully Qualified Domain Name (FQDN) as part of the X.509 Subject Name, does the IP address of the peer match the A record retrieved when doing a reverse DNS lookup?
* is the server's server certificate valid? (i.e. - is the current date between the validFrom and validTo dates in the server's certificate and every certificate in the chain up to a trusted certificate.
* is the server's server certificate explicitly trusted for authentication? (i.e. - is the server's certificate or a certificate in the server's certificate's chain explicitly trusted for authentication?)
 
It should be noted that these are all common options with most (if not all) TLS implementations, including OpenSSL.
 
It also implies that:
 
* the Client Application SHOULD  maintain a list of "authentication trust-points" or certificates identifying organizations explicitly trusted by the Client Application for the purpose of authentication.
* <strike>the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate</strike>
 
==Authenticating Agent Domain Servers and Region Domain Servers to Each Other==
 
Sensitive communications between agent domain hosts and region domain hosts MUST be over a secure transport like TLS / HTTPS.
 
When an agent domain host initiates communication with a region domain host, it must verify the identity of the region domain via the region domain host's server certificate. The process listed in the Client Application to Agent Domain section above should be followed for agent to region communications.
 
<strike>To authenticate the agent domain to the region, the agent domain should provide its client certificate to the region domain host. The region domain may then authenticate the agent domain using the same process as above.
 
When a region domain host initiates communication with an agent domain host, the process is reversed. The Agent Domain's server certificate is validated first (by the region domain host), then the region domain's client certificate is validated (by the agent domain host).</strike>
 
Agent Domains should access sensitive resources ONLY via capabilities issued by the region domain.
 
Clever readers will note that this implies:
 
* the ability for both the agent domain and the region domain to generate server certificates for their systems.
* (and) the ability for both agent and region domains to manage a list of "authentication trust points" in a certificate chain.
 
Fortunately, this is a relatively well known process (though, administratively, it can be "less than easy" with existing open source tools.)
 
=Specific Issues With Linden Lab Software=
 
'''note:''' this section introduces ideas for discussion. no decision has yet been made to implement this proposal. no decision to do so is likely without community discussion.
 
==Linden Lab Self Signed Certificate For Agent and Region Domain Authentication==
 
Blergh. Okay, you caught us. We're using self-signed certificates.
 
In an environment where we were the only ones offering region hosting, agent hosting and making viewer software, this was not an unreasonable choice. But now we have to open this process up to allow interoperability with trusted agent and region domains.
 
In terms of the OGP Beta, this is likely not too onerous an administrative task. ['''note:''' the person who just wrote that is not, in fact, the person who would be fulfilling service requests, so your mileage may vary.] In the OGP Beta, we are not (yet) attempting to transer potentially sensitive assets and there are a relatively small number of region and agent domain operators.
 
So... the proposal is we (the community in general) move beyond Self-Signed Certs except for testing purposes.
 
The simplest way to meet the "move beyond self-signed certificates" requirement is for Linden Lab to operate a registration authority for the purpose of beginning the certification process for external agent and region domain operators.
 
Or we could use some set of common well-known CAs, like Verisign or somebody.  Although they like charge money.
 
'''todo:''' fill out this section a touch more, maybe describing the process of registering a peer agent or region domain.
 
=Specific Issues With OpenSim Software=
'''note:''' Terevus, Zha, et al. do you want to add a few notes here?
 
'''Teravus:''' One thing to note here, however..  is you'll need to add your '''CA''' to the client's '''app_settings/CA.pem''' until the Linden/Verisign/Other CA process is worked out sufficiently.  The directions for setting it up are in *svn*/share/junkCA
 
Certain things don't work in SSL mode now.  For example: teleporting from Vaak to a SSL enabled OpenSimulator region fails because Vaak rejects self signed certificates and upon reading the response, it terminates the connection.  (So in OpenSimulator, you'll see Vaak invoke the cap, but it'll still fail because vaak doesn't read the response)
 
==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
**Sepember [[User:Infinity_Linden/Gridnauts_2080913|13]]
 
 
[[Category:AW Groupies]]
[[Category:Grid Interoperability]]
[[Category:AW Groupies User Pages]]

Revision as of 13:24, 21 October 2008

this proposal has been deprecated

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Infinity_Linden/OGP_Trust_Phase_0&oldid=106912"