User:Infinity Linden/OGP Trust Model

Computers should do exactly what you tell them, and no more.

—John Steven (noted internet security expert)

Introduction

The term "trust" in the domain of information systems is a collection of related concepts, many of which do not yield gracefully to analysis. Without delving into the depths of academic descriptions of "trusted systems" or "verifiable security," we can describe trust as a system "doing what it's supposed to do" while not "increasing the opportunity for exploitation by bad actors." This "trust model" is an initial effort to enumerate stake-holders in the system and describe their security objectives. "Trust," in this since is simply the expectation that the system will "do the right thing" and how we plan to verify remote system are behaving in a manner we expect.

We start with the User Stories section, introducing narratives describing situations legitimate system users may find themselves in and what the system should do to maintain "high confidence" that bad actors are not able to erode trust the system will either deny illicit manipulation or detect and allow recovery from it.

We continue by enumerating stake-holders in the system and briefly noting their requirements. We've listed End Users, Content Creators, Corporate IT, Agent and Region Domain Operators as major stake-holders. These are the people who have an interest in maintaining "trust".

Next we look at "security objectives." These are high level descriptions of behaviors we wish the system to express.

The Common Threats section attempts to catalog "bad behaviors" that should be identified and defended against.

Finally, the Implementation Notes section provides guidance on converting information in this document into practical, deployable systems.

User Stories

Specific use cases here - https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model_UseCases

Stakeholders and their Interests

End User

This is the traditional user of the system. They may be a casual user of Second Life or a corporate user, come to the grid to collaborate on "work" projects. In either case, their interests include:

• credential integrity - "bad guys" shouldn't be able to steal their online identity
• inventory integrity - the system should protect against inventory theft, loss, or usability problems
• specie integrity - the system should protect against loss of Linden Dollars
• privacy integrity - the system should allow user control of their presence and range of visibility of their personal data
• responsibility integrity - the system should recognize certain individuals as being responsible for others.

Content Creator

These are users who derive an income stream from Second Life. In addition to interests of traditional End Users, Content Creators also have these interests:

• content integrity - content creators want to know that content they create cannot be illicitly duplicated, lost or stolen

Corporate IT and ISP Operations

These are the people who maintain networks connecting the client's machine to the network, and in the case of corporate IT operations. they likely manage the user's systems as well.

• 'network security - no system component (client software, agent domain software, region domain software, third party web service) should decrease the general availability, reliability or security of the network
• peer system security - no system component (client software, agent domain software, region domain software, third party web service) should increase the risk of successful attack versus other systems in the network on which they operate

Client Software

This is the actual software running on the client machine; usually a viewer, but could be a web application using standard published APIs into the Agent or Region domains.

• system security - use of the Second Life viewer or other client software should not place the user's system at greater risk of successful attack
• flexible peer authentication - the system should be flexible enough to support multiple legacy peer authentication schemes

Agent Domain Administrator or Region Domain Administrator

This is the organization that operates an agent and/or region domain.

• peer authentication - the system should support strong authentication techniques to ensure the identity of peer systems
• flexible agent authentication - the system should be flexible enough to support domain-specific user authentication
• forward security - for the purpose of third party the system interoperability, the system should provide authentication tokens usable ONLY for the explicit purpose described

Agent Domain Software / Systems or Region Domain Software / Systems

This is the software that implements agent and/or region domain services.

• flexible peer authentication - the system should be flexible enough to support multiple legacy peer authentication schemes

Third Party Web Service Operators

These are systems operated by third parties for the benefit of Second Life users, Agent or Region Domain operators.

• limitation of sensitive data - the system should not REQUIRE third parties to handle sensitive information

Implementation Notes

System Layer Trust Between Systems in Different Administrative Domains

One of the most common situations in terms of trust will be two systems from different "administrative domains." The Open Grid Protocol assumes a world where actors from independent administrative domains establish "relationships" based on a general use agreement (such as a Terms of Service agreement.) Fundamental to such interactions and relationships is the concept of positive identity or at the very least pseudonymity. One actor (like a resident running a viewer) must have faith that their remote peer (like an administrative domain) is really the peer they think it is (positive identity) or at the very least, it's the same peer they talked to last week (pseudonymity). Such network layer trust is a necessary enabler for "higher level" trust objectives such as inventory integrity, fraud detection, etc.

Transport Layer Security

It is impractical to recommend Virtual Private Networks for such systems. The administrative problems of adding arbitrary users to a managed VPN are great, especially considering the purpose of a VPN is to create a "private network" for members of a single administrative domain (or related administrative domains.)

Instead, technologies like Transport Layer Security (the successor to SSL or Secure Sockets Layer) provide a good solution. The focus of TLS is to a) ensure the identity of the peer system and b) maintain the confidentiality of information moving between systems.

In TLS (and the related Datagram Transport Layer Security or DTLS,) identity of a server is established via presentation of an X.509 certificate. This certificate is used in a "chain of trust" that leads from the server to a well known and "trusted" third party (such as Verisign, Thawte, etc.) Certificates for these third parties are widely distributed and "easy" to verify.

X.509 certificates may also be used by clients to identify themselves to servers. Known as "client side certificates," this use of X.509 has seen relatively little use outside some high-security (and high administrative cost) applications. Instead, using a pass-phrase in conjunction with TLS to authenticate the client to the server after the server has been authenticated by the client is a viable (and considerably less expensive) alternative.

Therefore, in situations where two systems from two different administrative domains where the requirement is to positively identify a peer, the use of TLS for server authentication and password authentication for individual users is recommended.