1 Introduction
This document should serve as a tutorial and reference for the use of
security features of PLAN 3.2. More detail on the individual services may
be found in the PLAN Programmer's Guide [2]. Details about the
technical rationale and the design of the security system may be found
in [7]; this paper should be read first, as its knowledge will
be assumed herein. Note that the per-packet CPU and memory restrictions
described in [1] are not implemented in the present version of
PLAN1.
PLAN was designed to be expression-limited with the idea that `pure' PLAN
programs could run without the need for heavyweight security mechanisms
while PLAN service routines, which are written in more general-purpose
languages, may require additional restrictions. To make service calls safe,
we have provided a system of trust management. Each node administrator
creates a policy which restricts the use of certain `unsafe' services to
select parties. A series of routines are provided in this release to
formulate such a policy and enforce it at runtime.
Service call restriction occurs through a process of authorization.
This implies that a user must authenticate himself with the node, and
then be checked with the node's security policy. Authentication must be
secure so that no spoofing (pretending to be someone you're not) is
possible. We ensure this by using cryptography. Even though many PLAN
programs should be able to avoid accessing restricted services, we would
still like authentication and authorization to be as lightweight as
possible.