Croquet Security Requirements Suggestions
Last updated at 12:39 pm UTC on 17 January 2006
(initial draft by Marc Stiegler)
David Reed's observation that "I'd like people to understand that we don't know what the word security means for Croquet" has left me aware that, in the absence of a little more shared perspective on security requirements, the upcoming presentation by Mark Miller and myself about security will take place in a vacuum where the quality of our suggestions cannot be assessed.
Below is a draft list of security requirements that seem reasonable to me for Croquet. This is not a proper requirements document. It drills down into architecture from time to time, where the requirements make certain architectural choices likely. It also wanders into philosophies of security. The goal is not a pure requirements document. Rather, the goal is to establish some basis of mutual understanding, or perhaps to establish the areas of clear disageement.
Some of requirements are also "anti-security" requirements. I.e., these are requirements imposed by Croquet usability goals (and other goals). The anti-security requirements allow us, I believe, to quickly reject many traditional security mechanisms.
Security Requirements Suggestions
- Security needs to be largely invisible. The Diablo trading system, referred to in earlier email, points the way (as do a couple of the demos we will present). Humanity has had to tolerate obtuse in-your-face security far too long already.
- Passwords should be excoriated. This is a straightforward derivative requirement of invisible security. Human beings have terrible trouble with passwords. The usability goals of Croquet would seem to demand their elimination. The security toolset should make it easier to implement password-free security, than to implement passwords.
- Authorization, not Authentication. An architectural choice that is hard to avoid, given these requirements, is to eschew ID authentication-based security in favor of authorization-based security. Ask not, "who are you?" Ask rather, "Are you allowed?" This is comparable to transitioning from using a driver's license to using a car key. Imagine a world in which the car demands your driver's license to match the car's certificate of title, and you have a world sadly similar to the one we have today on our computers. Fortunately, in the physical world cars do not care who you are, they only care that you have the authorization. A poignant demonstration of the risks of ID-based security can be found today by entering any airport. My own sense is that individuals often seem to prefer authorization based security. Centralized organizations often seem to prefer ID-based security. Which brings us to the next point:
- Centralized management systems are unacceptable. Croquet should not depend on Verisign certificates. There should not be a (shudder) Croquet Central Certificate Authority.
- A related point is, there should be no global namespaces. The current dispute over ownership of the ".iq" domain space should be enough said. Croquet should strongly minimize its dependence on the DNS global namespace system, though this is so ubiquitous, it may not be possible or desireable to escape from it entirely. You can read about an alternative, Pet Names, at http://www.erights.org/elib/capability/pnml.html for a simple, general-purpose approach to naming. We will demo such pet names at the meeting. I have now implemented pet name systems with diverse technologies, even ACLs, so I do not believe it is prejudicial to suggest this as a good idea no matter what other security technologies Croquet elects for deployment.
- Security must impose minimal overhead on performance, above and beyond the performance penalty for choosing an object-oriented language with such practical features as garbage collection.
- Implementation note: since the performance penalty for OO has already been accepted by the Croquet team, you're already almost there. The main additional thing that needs to be done is to avoid screwing up the security inherent in object-oriented systems. One needs to eschew non-OO touches like global variables and ambient authorities. Ambient authorities may seem convenient...until you have to deal with either security or reliability, both of which are placed at risk).
- Another observation: People are often afraid of encryption, believing it will significantly degrade performance, with a worried eye to the passing of massive multimedia data which is already expensive. While initial negotiation of a secure connection can be expensive, benchmarks at Electric Communities suggested that the single-key encryption associated with bulk data transport imposes negligible overhead compared to the costs when packing and unpacking highly compressed data streams. Nonetheless, I can sympathize with anyone who remains worried. I would suggest going with a system that always encrypts automatically to see how you like it. Even if you decide to build in a way to circumvent encryption from the first day, I would urge, on my knees, that sending data unencrypted require an explicit and highly visible coding change such that the default, easiest path to communication is indeed encrypted, and both original programmers and later reviewers can immediately spot digressions from the secure communications. I have a number of tragi-comic stories about people who knew they were using strong encryption ... except they were actually sending cleartext. Perhaps the requirement should be, do not add to the collection of funny stories :-)
- The security toolkit should be well integrated with the gui toolkit: the gui toolkit should encourage good security implementation, and the security toolkit should encourage good user interface implementation.
- As a part of this, the gui toolkit should easily enable securing the widgets. So, for example, conveying authority to edit a single window pane should not by default be a conveyance of the authority to edit the entire window frame, much less the entire display screen and the file system. This is a simple application of the Principle of Least Authority (POLA). This may seem a trivial detail to present as an example, but it has interesting implications. This little bit of "polarization" is central to enabling the construction of objects that have all the power and utility of ActiveX controls without the egregious security side effects so common in Internet Explorer.
- Let us go in the other direction, making the security tools support user interface. We have a growing body of strong demonstrations for a key architectural concept for usable security: combine the authority to operate on an object with the designation of that object. This philosophy is demonstrated quite nicely by the Diablo escrow agent (and our CapDesk demo). Consequently, a good candidate feature of the security system is that it bundle authority with designation, since having this principle directly embedded in the security system aids the gui writer to easily create user interfaces wherein the security disappears from view.
- Do not prohibit what you cannot prevent. This is not exactly a requirement. Rather, this a heuristic I would propose for the Croquet team. We have found it to be a useful tool for thought. Attempts to prohibit what you cannot prevent often leave the user confused about his real risks when making trust decisions. We often find it clarifying to take this to the extreme, to "embrace what you cannot prevent". This extreme form ensures that the true risks are exposed while enabling any positive functionality that prohibition might constrain. An amusing example of this principle is the periodic re-emergence of the concept "security by obfuscation": make it so hard to understand the code that no one can figure out how to crack it. Open source is a good example of embracing what you cannot prevent: if your system gets popular enough, someone will reverse engineer it anyway, you might as well give the good guys an equal opportunity to crack it as the bad guys.
- Croquet should embrace delegation. Traditional security thinking often attacks delegation as an easy target for prohibition. However, people have been doing delegation for millennia. You can't prevent it, it is crucial to our normal interactions, and we are actually quite good at it (though both news media and famous literature focus on situations where people make catastrophic delegation decisions – it makes a better story). Sit back, relax, and enjoy the ride. (note: pure simple delegation is not always appropriate in a corporate setting. However, in communities of individuals like Croquet, I do not see a reason for complicating this perspective).
- Croquet should support, easily and naturally, "polarized chain delegation". One of the reasons people sometimes fear delegation is that, on computers, delegation too often means conveying whopping big authories (like giving someone your password). To be effective, it must be easy for each successive act of delegation to also be a further act of authority minimization. So Alice gives Bob a panel of her window, Bob gives Carol a subpanel of his panel, and Carol gives Ted just the authority to attach an observer to one widget in her subpanel.
- Defense in depth rather than perimeter security. I like to refer to traditional "perimeter security" with the rather more pejorative term (which I also think is more correct) "eggshell security": stick a tiny pinhole in the shell and you can suck out the entire yolk. "Defense in depth" is of course a "motherhood and apple pie" concept. The heart of the issue is making it natural and easy. We have found that, using the right security paradigm, defense in depth is often an emergent property of clean OO design. In this way, the security can, at many times and in many places, disappear into the background not only for the end user but also for the programmer. This seems an attractive approach.
- The security toolkit must operate seamlessly with both local and remote objects. If a security policy requires different implementations for local versus remote objects, it will fail in the face of mobile objects.
- The elements of the security toolkit must be composable and extensible , as noted in earlier email. This may sound like motherhood and apple pie, but surprisingly few traditional security approaches meet this constraint. An example is the failure of Unix and Windows ACL systems to allow one to deny network access to a specific user account. On the one hand, this is a fairly surprising bit of missing mechanism. But the really big problem is that you cannot extend the ACL system to encompass control of network access without modifying the kernel. There is little room there to invent new security policies beyond those imagined by the system architects on the first day.
- No grants of authority that deprive the user of the ability to revoke authority. This suggested requirement needs elaboration. At the end of the day, the user owns his machine, he can give away such authority that the recipient of the authority achieves a level of control that prevents revocation, i.e., puts the recipient into the TCB. However,
- Such a grant should be so visible that the user cannot make such a grant by accident. This is no different from the Microsoft dialog box, "Do you want to grant full control of your computer, yes or no?"
- Such a grant should be so rarely appropriate or necessary that a request for such authority immediately sets off alarms in the user's head. This is quite different from the Microsoft dialog box, which appears so often the user must stop paying attention if he/she is to get anything done. It would be heartbreaking if, as Croquet adds its millionth user, a user-level security policy were to come into play akin to the advice now given in all new-user Web-surfing classes: "do not ever launch an email attachment." Patterns of cooperation that assume large amounts of trust, while they work for small groups, do not scale.
- Auditability. The security toolkit must enable construction of auditing systems to support diverse goals. Examples:
- Auditing to identify the locally-responsible entity. To use the analogy in the comments, with a clonable carkey where every clone is separately loggable and revokable, if Alice gives a clonekey to an entity for whom her pet name is Bob, the system should be able to log that Bob's key was in use when the car crashed, allowing Alice to assign local responsibility to Bob. Bob could similarly make a clonekey of his key for Carol, and assign local responsibility to Carol. This "local responsibility" model does not necessarily allow Bob to show Alice that it was really Carol; Alice still holds Bob responsible.
- Auditing to identify a chain of responsible entities. Create a chain of clonekeys such that it can be demonstrated to Alice's satisfaction that Carol was responsible. I believe that, for Croquet, it would be OK for such a demonstration to depend on a trusted third party. There are fancy solutions to this using clever crypto instead of TTP, but my first thought is to say this is not required.
- Logging to enable deterministic replay. Which further requires that it be possible to isolate an object so that it has no access to nondeterminism.
Some Scenarios
It may help the discussions to have some example scenarios specific to Croquet. Here are a few that seem both relevant and have impact on how security is achieved.
- Plaground: Alice writes a playground room that anyone may play in, but where no one can ruin the experience of others. Equivalently (I think), Alan writes an active essay on the biological metaphor for computing, complete with embedded interactive goodies, that anyone can read and play with, that no user can ruin for the other users, and that only Alan may edit.
- Conference: Andreas creates a Central Planning Room for World Domination, and only he and his Croquet Cronies may directly enter the room. (up to the point of proxying; Cronies can proxy in other people, but it should require a deliberate act.) Equivalently to planning World Domination, it might be a meeting of the marketing VIP's at a large corporation.
- Classroom: Alex and Alicia want to teach fractions, and have put together a kindergarten-like classroom with lots of toys. They are able to observe everything the students do with the toys. Ideally, they should have some measure of control over what toys are available in the room; they and they alone should be able to both add and remove toys to the room as the lesson progresses.
- MUD: Ashron writes a massively multiplayer wumpus-hunting dungeon. Users can embody themselves into an avatar under the dungeon's (and ultimately Ashron's) control, e.g. if a wumpus eats you you are DEAD. The experience should be relatively transparent, the Wumpus-Land should not gain any privilages of the user, and the user should have clear and reliable indication of whether they are or are not embodying a wumpus-land avatar.
Comments
The efforts to eradicate authentication in the course of normal activity seems good (the car key analogy is excellent!), but also note that it is very valuable if a Croquet user can determine that they are talking to the person they think they are talking to. For example, it would be desirable if Croquet allows people to schedule a private business meeting to take place in a Croquet room. A conclusion is that trustworthy identification would be valuable to support at the borders of the system. -Lex
Perhaps authentication at the borders is appropriate. Keep in mind the following factors before drawing that conclusion, however:
- "At the border" is a hard location to pin down, even in the current Internet. I would expect Croquet, with its enhancements to fluid operations, to have even more trouble with a meaningful definition of "the border". I predict that efforts to drive down this path will find themselves on a slippery slope into the current Internet quagmire, where every offerer of a service considers his little domain to be a realm with a border where ID should be required. Unless, of course, you opt for a Croquet Central Certificate Authority, along with the associated global namespace and the system management opportunities it entails (who gets the cert for "Mark Miller"? Which HP employee?).
- Delegation, even of identity, cannot be prevented. Indeed, on Ultima (I think it is Ultima), characters are sold for real-world cash, making the delegation of identity not a problem to prohibit, but a feature to enable. Before embracing authentication, consider the loss of understanding of the real trust and risk issues the user may experience if he is given the illusion of "true identity".
- If you accept that even ID delegation cannot be prevented, I can describe for you authorization-based mechanisms that get you pretty much the same indication of who it is at the other end as authentication systems can give you. The minChat app in E in a Walnut crudely demonstrates this. The basic idea, in E terminology, would be to hand a unique facet to each individual: manipulation via that facet is a pretty clear indication of who is the manipulator. A weak analogy with the car key is this: suppose you could easily hand someone a distinctive near-clone of your key. It would be separately revocable and separately trackable: Mileage while the cloned key was in use could be separately logged, etc. You would have an authorization system that gave strong indications of who was driving the car, and an absolute indicator of who you should hold responsible if the car crashed.
Remind me in the meeting to discuss this, if it remains an issue.
(–marcs)
A concept that I'd like to make sure is present is the idea of auditability or history-keeping. - dpr
Separating access control from identity doesn't prevent using identity in an audit trail. – Alan Karp
Lex is almost right. I want to make sure I'm conducting business with someone authorized by the other company. That's more important that knowing the identity of the person. (Are you sure he wasn't just fired?)
When you want to talk to a specific person, you use a series of questions. (Who was our second grade teacher? Where did you live when we met?) Of course, if this conversation is ongoing, you can share a secret. You can still fall back on questions if you think the secret was stolen or given away.
Alan Karp
Think pet names with authority rather than identity, and I still believe you have a simpler system. Pet names with authorities and more traditional identities can both meet the new Auditing requirement, see above. This new requirement includes deterministic replay, which feels excessive for Croquet's requirements, but I have a dim memory of having read (in one of the TeaTime docs?) a statement suggesting this is a requirement. Is it? On the flip side, is full-up nonrepudiability, which I do not propose, a requirement?
(–marcs)
I think the Cronies scenario, just added, is a little more concrete. An acceptible solution, for example, would be if I hand Andreas a key in person that he then uses to get access to my room. That works well if we have set up themeeting in advance, or if we have set up a general-purpose Cronies-only room (and key) in advance. However, it is no good if it is a surprise meeting. In such a case, it would be nice to appeal, not necessarily to the Croquet Central User Database, but perhaps to the HP Employee Database. That in fact may be a pet names solution, but since this is all starting to hurt my head I will stop now!
Oh, just one more comment: it is perfectly fine to redefine identity, meetings, authentication, and so on for an online context, but it needs to be done in a way that average joe's can use the concepts automatically. Members-only meetings just seem like something that Joe's will frequently want to do. (Lex Spoon)
One approach to the "members only" goal is to use brands. Brands could be represented in Croquet visually and conceptually as badges (for example). If you go to a conference or an sf convention, you get a badge; it does not have your ID on it necessarily, but having the badge proves your right to enter the convention rooms. In cyberspace, we can make those badges truly unforgeable and unspoofable (not the visual representation, of course, just the underlying brand...actually, I think we can make the visual representation unforgeable too, but that is really funky, using a "pet pattern" for the badge). So there could be an HP badge or a Croquet Cronies World Domination badge. We use brands in DonutLab, specifically the mints have brands so you can tell which kind of money you're getting paid. Ask and I shall show you how it's done.
(–marcs)