Function Modules and Architecture

Though security agent could potentially provide many services, such as retrieve, transfer, exchange credentials among different hierarchy systems, introduce one agent to another, or delegate one agent to act on another's behalf, etc, the basic operations are more or less the same. Here, we sketch the structure of security agent based on these basic operations: issue/apply a certificate, update/revoke a certificate. We describe the components (modules) of security agents by their functionality.
The modules in the current implementation of the security agent are as follows:

1. Communicator: It deals with communications with other agents. In fact, what the communicator module does is to accept and parse messages (KQML packages) from outside agents, or to pack outgoing messages into KQML packages and send them out to intended agents.
   The parser must recognize if a message is encrypted, put it into a task object and send it to the planner. In some circumstances, this procedure may be repeated several times, if the original KQML message includes recursive KQML messages.
2. Task Planner: The message from outside, represented as a task object, is passed to the task planner. Upon receiving a task object, the planner initializes a process with the received data as the input according to a specific protocol extracted from PDB (Protocol Database, see below). The protocol steps are passed to the scheduler.

3. Task Scheduler: This module schedules the protocol steps to be executed. Since its services are used by many other agents, the security agent needs to arrange the priority and schedule the requests for security it receives from many different agents. After the protocol steps have been scheduled, they are passed to the execution module.

4. Execution Module: This module executes the process initiated by the task scheduler step by step. The basic security operations executed by the execution module are: encrypt/decrypt, sign/verify a message.

5. Human-Agent Interface: Human/agent interface is designed as an interface for user to set up and customize the system. More precisely, through the interface users can:
   1. can define or choose a format of certificate they want, name space length of their public key and algorithms of cryptography, as well as a name of certificate.

   2. apply/issue some kind of public key certificates - During the application procedure, the applicants need to interact with their agents. When applicants receive their certificates, they also need to confirm that the information included in the certificate is correct and the signature is signed correctly by the intended security agent.

   3. Input the sets of security protocols for various certificate management strategies and policies of authentication service system.

6. PDB (Protocol Database): Every security agent should store all sets of security protocols needed in its PDB for various managements tasks (routines) required in all of the authentication service systems across it. The basic protocols are certificate update protocols, certificate revocation protocols, certificate application/issuing protocols, etc. Given a task object by the parser, the planner looks up the PDB, then starts a process according to the matched protocol from PDB. Subsequently, the execution module executes the protocol automatically.

7. CDB (Certificate Database): When the agent applies for a certificate from a security agent, it will be given not a single certificate but a chain of certificates. This chain of certificates consists of the certificates of all the security agents along the path from the root security agent through the parent security agent, from which it applies its certificate, in the authentication hierarchy. Each security agent stores its chain of certificates in its CDB. Later on, when the security agent wants to communicate with another security agent, it does not necessarily contact other higher level security agents to retrieve the participant's public key certificate(s). The agents can exchange their certificate chains (or part of their chains) to prove their authenticity according to their positions in the name space. By caching some most frequently used certificates, the communication costs will be cut down dramatically.

Figure 2.3 shows the relationships and data flow among the security agent's functional modules.

Suppose, a message from another agent comes to the communications module. After the message is received, it is parsed by the parser. In the simplest situation, the message is a kind of datum that represents a request from another agent. It is processed by the parser, which outputs it as a task object and passes it as an objective to the agent's planner. After the planner has planned for this objective, the plan actions are passed to the task scheduler module to be scheduled. Subsequently, the scheduled actions are executed by the execution module. Results are sent back to the agent who originated the message through the communicator.