Higher Ed Security Scenario
Last updated at 12:40 pm UTC on 17 January 2006
A college may well be a locality in the Croquet universe for which authentication "at the border" is required, as Lex Spoon suggested. For the sake of the following discussion, let us assume a nightmare situation with all the usability issues that plague traditional security strategies. Then when we get together, we can talk about ways in which your needs are hopefully not this nightmarish, that allow us to regain some of the usability that we lose in the nightmare.
One of the key points to discuss will be the university's threat model. A curious but crucial aspect of the university threat model is identifying the aspects that cannot be achieved. In these cases, the goal is to become aware of the hopelessness so that you can focus your energy on solvable problems. The threat that comes to mind that a university will surely desire to prevent, but cannot, is allowing the student to forward his final exam to a separate exam-taker. If someone believes this can be prevented, we will have a very interesting discussion indeed :-)
So here's the nightmare scenario:
- Assume that, as a university, you are under legal strictures to attempt to prohibit what can not be prevented. You must try to tie the computer entity back to a true name, regardless of cost, usability, or functionality impairment.
- Assume that you have no physical way of engaging with students and teachers. Putting people into a room together, even just once, trumps some problems with pure cyberspace systems.
The general strategy described below is based on the idea, "go ahead and authenticate...but once you've tied authorities to the ID, do not use authentication for access control". See if the below fits your goals:
- Require every student and every teacher to get a Verisign certificate. This becomes the basis for true name mapping.
- Now, for every course, the teacher receives, via mail encrypted to his Verisign account, an email signed by the University verisign certificate, which contains the public keys and email addresses for the Verisign certificates for all the students.
- The teacher sends an individual email, signed with his verisign certificate, encrypted to each individual student's Verisign certificate. This email contains documents, each document embodying a single Croquet authority associated with the course (in the systems I have been involved with building, such an authority-bearing document contains about 100 characters, quite unreadable to the human being. We can discuss its format when we get together if you desire). Example documents might include a "badge", discussed briefly on the SWiki, that lets you get into course events. There may be a "classroom key", which would be take the student to the place where everyone in the course goes to for lectures. The classroom key for each individual student may be unique, and the act of creating each classroom key also creates a "revoker" that the teacher keeps, so that if a particular student is evicted, the teacher presses the revoker and the ex-student can no longer find the classroom, much less enter it (the teacher might send the revoker to the university in case the university decides to expel the student, as well). Perhaps most interesting, the teacher may send a unique "unsealer" to each student, and a unique "sealer" to each student, that allows the teacher and the student, inside the world of Croquet, to send each other secure authentic messages:
- the teacher can seal additional data/authority for the student to open with the unique unsealer. The teach can know that only the student can read the message, and the student can know that the teacher sent it.
- the student can seal data/authority for the teacher and know that only the teacher can read it, and the teacher can know that this particular student sent it.
Sealers and unsealers are authority-based, not identification-based, means of exchanging authorities and data inside the context of a Croquet-like universe. They follow a pattern of implementation we refer to as "bundling authority with designation", which makes it straightforward to build friendly (and password free) user interfaces. By exchanging a pair of sealer/unsealers, the teacher and student open up an unbound collection of future authority exchanges in which each person knows where it came from and who it is going to.
Note that in the scenario I described above, all the usage of Verisign certificates is "out of band", i.e., it is not a part of the Croquet universe. Rather it is used outside the Croquet universe to establish initial Croquet relationships. Once those relationships are established, the certificates fade into the background.
Note also that, if you substitute for "Verisign certificate" the phrase, "a pattern of interaction that establishes identity to an extent adequate to meet your functionality requirements inside your threat model", there are solutions as diverse as the problems people face. My wife is a faculty member for a community college, her speciality is online courses. Inside the context of her college, instead of using Verisign certificates, they just use email addresses unencrypted: the student shows up physically at the college once, the college gives the person an email address, and emails that address to the professor. Once you get inside the Croquet world, her authorization mechanisms would be identical to the authorization mechanisms used in the nightmare scenario. The only difference is the initial setup, with a gentler threat model and physical interaction.
(–marcs)
