Re: Programming languages for remote agents

Daniel W. Connolly (connolly@hal.com)
Fri, 12 Aug 1994 21:10:42 +0200

In message <94Aug12.111423pdt.2761@golden.parc.xerox.com>, Larry Masinter write
s:
>What I would look for in a programming language for remote 'agents' to
>be sent in mail, executed locally, etc.
>
>What I'm looking for is a language that includes, in the language, a
>security model, with a full notion of an `agent' that operates on the
>behalf of a `user', `group', or `service', where procedures are
>exported, can examine the identity of the user on whose behalf they
>were called, can dynamically or statically declare which operations
>are available to which classes of users, or operate conditionally
>depending on whose behalf they were called, and where there is no way
>to cheat, since the agent is signed by the user securely. I don't see
>this in Safe-TCL. The language doesn't have any simple way to
>determine whose authority a procedure executes with. Maybe Safe-TCL is
>a useful platform on top of which one could build this kind of
>security model, but it isn't there, and it isn't obvious that Safe-TCL
>actually provides 'an open framework on which you can build' such
>applications.

Cool idea... here are some relevant technologies:

>From "Obliq Quick Start"
http://www.research.digital.com/SRC/Obliq/Obliq.html

----
Obliq is a lexically-scoped untyped interpreted language that supports
distributed object-oriented computation.

An Obliq computation may involve multiple threads of control within an
address space, multiple address spaces on a machine, heterogeneous
machines over a local network, and multiple networks over the
Internet.

Obliq objects have state and are local to a site. Obliq computations
can roam over the network, while maintaining network connections.
----

In oblique, all filesystem operations take a filesystem object
as a parameter. There are read-only filesystem objects, and read-write
objects.

A computation on host A might have a local variable fs that is a filesystem
object on host A. The computation could migrate to host B, but

f = open(fs, "/etc/passwd")

still accesses A's filesystem. In order to get access to a filesystem
on host B, the computation might do something like (syntax is python,
but you get the idea):

def challenge(num):
return RSAdecrypt(num, my_secret_key)

fsB = B.askForFS(my_identity, challenge)
f = open(fsB, "/some/file")

i.e. the client identifies itself, and asks for a filesystem object.
The askForFS methon on B calls the challenge callback with a random
number, encrypted with my_identity's public key. The agent knows
my_secret_key, and is able to meet the challenge. Hence the agent
is authenticated. (Note that the challenge() computation can take
place on host A, so the secret key never goes over the wire).
If the authenticated principal is authorized, B will return it's
filesystem object, hence making it available in the agent computation's
lexical scope.

Alternatively, you could use safe-tcl, and have the client RSA sign
the tcl-code. All requests from a run of that tcl code would then
be authenticated as the signing client principal.

You might look at the Scheme Underground and scheme48 projects too:

http://www.ai.mit.edu/projects/su/su.html

There are some interesting papers on the subject too:

<dl>

<dt>Cliff Neuman
<dd> <a href="ftp://prospero.isi.edu/pub/aac/pbaa.ps.Z">Proxy Based Authorization and Accounting for Distributed Systems</a>

<p>Mr. Neuman describes an extremely interesting model for distributed
authorization and accounting. Looks fairly practical.

<DT>Digital Equipment Corp, Sys Res Ctr <A
HREF="ftp://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-039-appendix.ps.Z">SRC-039-appendix.ps.Z</A>(42K)
<A
HREF="ftp://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-039.ps.Z">SRC-039.ps.Z</A>(127K)<DD>
SRC Research Report #39 Date: February 28, 1989 <P> "A
<STRONG>Logic</STRONG> of <STRONG>Authentication</STRONG>." Michael
Burrows, Martin Abadi, and Roger Needham. 48 pages. <P>

<p>This is an oft-cited work on the formal properties of authentication
protocols.

</dl>