User:Infinity Linden/OGP Trust Phase 0

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.

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

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.
• the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate

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.

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).

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*/contrib/junkCA

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 13