[Auth]Draft Spec: Implementation of Gelernter Cyberbodies

[Carsten Kuckuk]

Dear List,

It might be a bit premature, but I wrote up a document detailing my
ideas. It does not really deal with authentication in the sense of one
server handing a client over to another server which would most likely
require PKI, but it fakes it by storing the necessary authentication
information in the cyberbody. This draft solves the problem of
distributed storage, untrustworthy registrar servers, and access from
everywhere. Instead of Java client you can also think Browser plug-in or
Explorer-extension or mail program extension or whatever. 

What do you think?

Carsten Kuckuk

============================================================================================


Implementation of Gelernter Cyberbodies
----------------------------------------
The purpose of this document is to provide a first quick and dirty
specification and implementation of cyberbodies with their distributed
storage. The code is proof-of-concept only, and the whole purpose of
this specification is to clarify goals.

(c) July 17, 2001 by Carsten Kuckuk, Ludwigsburg, Germany, E-Mail:
address@hidden, permission is granted to modify and distribute this
document in its entirety in the spirit of the GPL license .

Overview:
There is a need for a combined single sign-on system that allows
Internet users to approach any computer that is available, log on on
this computer and have a familiar environment with all their personal
information and services at their disposal. 
In the context of this document, "having information and services
available" can be interpreted as "knowing the Internet address of a
computer that contains it, and knowing how to access this computer and
which username/password combination to use". The collection of this
critical information is called a cyberbody.
Login on to a computer is interpreted as retrieving the cyberbody from
servers on the Internet. 
Making use of the cyberbody is interepreted as running a Java
application that displays the list of all services contained in the
cyberbody to the enduser, have him select a service, and start a helper
application that accesses the service.
In order to store a cyberbody, the cyberbody is transformed into two
binary strings that look like random numbers. These two strings are
stored on different computers on the Internet using a simple username /
password protection scheme. 
In order to access a cyberbody from anywhere in the world, the end-user
has to memorize the locations and username / password combination of
these two computers where the cyberbody is stored on. 

The remainder of this document consists of the following parts:
Part 1: Specification of a cyberbody explains the exact composition of a 
cyberbody.
Part 2: Storage form of a cyberbody describes how the cleartext
information of a cyberbody is transformed into two strings that expose
the statistical properties of random numbers. This form is the storage
form of a cyberbody. 
Part 3: Access and Update Protocol for stored cyberbodies describes how
the two parts of a cyberbody can be retrieved from the Internet, and how
modified versions can be stored. At the heart of it there is a
comit/rollback mechanism combined with username / password authentification.
Part 4: A sample client using cyberbodies implemented in Java is a
simple Java application that retrieves cyberbodies, allows the client to
access the services stored in it, allows the client to modify
cyberbodies and store them.
Part 5: A sample server storing cyberbodies implemented in PHP gives the
necessary scripts for implementing a cyberbody storage on a LAMP server.
Part 6: Future improvements describes what has to be done in the future
to make this system more practical.

Glossary:
Cyberbody: Collection of personal authentication data that is needed to
access web services
Web Service: Simple things like e-mail, file storage/ftp, bulletin
boards, calender, link collection, address books


PART I: SPECIFICATION OF A CYBERBODY

A cyberbody is a list of lines each describing one service. A service
consists of a service description (protocol part of the URL), a web
address, a username, a password and a comment that is displayed to the end-user.

Cyberbody := "<body>" <lf> {WebServiceAccessInfo} "</body>" <lf>
WebServiceAccessInfo := URL " " Username " " Password " " Comment<lf>

Example:
<body>
http://www.kuckuk.com/ - - My favourite web site
pop3://www.kuckuk.com/ ck nuknuk My POP3 account
ram://www.wdr3.de/ - - My favourinte radio station
ftp://ftp.kuckuk.com/ ck nuknuk My file storage
app://www.kuckuk.com/apps/JWord.jar ck nuknuk My favourite Word editor
</body> 

PART II: STORAGE FORM OF A CYBERBODY
In order to store a cyberbody, the cleartext form of the cyberbody is
transformed into a storage form that consists of two strings of bytes of
the exact same length. Due to the way these strings are generated, they
both look like strings of random numbers.

Let c_i, i=0..n be the binary representation of the cyberbody.
Let r_i, i=0..n be a random bytes.
Let s_i := c_i XOR r_i, i=0..n
The storage form of the cyberbody consists of the byte sequence r_i and
the byte sequence s_i.

Given the storage form of a cyberbody as two byte sequences r_i and s_i,
the cleartext form of the cyberbody can be calculated as c_i:=r_i XOR s_i.

The desired property of this storage form is, that both sequences expose
the statistical properties of random numbers. Both sequences are needed
to restore the cleartext form. So if each sequence is stored on its own
computer, and the computers are sufficiently far away from each other,
and the owners of the computers don't know about each other, then the
stored data can not be retrieved at all by any one of the two server
owners. Trusting the operators of the servers that store the cyberbodies
is not necessary at all. 

PART III: ACCESS/UPDATE-PROTOCOL FOR STORED CYBERBODIES
In order to access or modify a stored cyberbody sequence, the requester
must present a valid username and password to the computer. In order to
allow for recovery from incomplete modifications or a single lost update
due to a server crash, two versions of the storage form of a cyberbody
are stored on each server together with a version number. The accessing
client gets both sequences and uses the newest version that both servers
have stored. Let C be the client computer and S be the server computer
that has stored the cyberbodies. I don't know the details by heart, but
the parameters are passed as if this were an HTML form submission with a
GET action.  

Retrieving a Cyberbody:
c->s: GET HTTP://www.server.com/dotnet/cyberbody/get.php?u=username&p=password
s->c: OK<lf>Content-Length: 
xxx<lf><lf>33:lenbytes:XXXXXXXXX<lf>34:lenbytes:YYYYYYYYY<lf>
(Like a form with parameters "u" and "p")
If the user is known and the password is correct, the server returns the
current and the next-to-current cyberbody. It is the Java client's task
to determine which version to use. In the case of an authentication
error only an error message is returned.

Storing a modified Cyberbody:
c->s: GET 
HTTP://www.server.com/dotnet/czberbody/put.php?u=username&p=password&v=35&body=XXXXXXX
s->c: OK
(Like a form with parameters "u", "p", "v" and "body")
If the user is known and the password is correct, and the version number
is higher or equal to the highest version number stored in the database,
the new version is stored in the database, and the oldest version is
deleted from the database.


PART IV: A SAMPLE CLIENT USING CYBERBODIES IMPLEMENTED IN JAVA
<To be done>
- Ask user for server1, username 1, password 1
- Ask user for server2, username 2, password 2
- Contact servers, retrieve storage sequences with version numbers
- Select a complete pair of sequences with the highest possble version
number. Memorize version number.
- Calculate the cleartext of the cybebody from the storage form.
Loop:
 - Display Services from Cyberbody
 - Display possible commands: (1) Use Service n, (2) Add a service, (3)
Delete a service, (4) Update profile
- Wait for a command
Command 1: Use Service n: Determine n, determine cyberbody[n], invoke service
Command 2: cyberbody[max+1]=input line
Command 3: delete entry cyberbody[n]
Command 4: version++; create sequences r and s;
server1->Put(user,pwd,version,r); server2->Put(user,pwd,version,s); 
End Loop

PART V: A SAMPLE SERVER STORING CYBERBODIES IMPLEMENTED IN PHP
<To be done>

Part VI: FUTURE IMPROVEMENTS
- Use digest authentication for the access protocol
- Use PUT for the access protocol
- Define gobs of services for the URL