1.1. Sender Configuration
1.2. Receiver Configuration
2. Test Setup
3. Adding and Revoking a P-Server to the CoT
4. Maintenance of the Privilege
5. User Privilege List Maintenance
6. Sending a Privileged Email
7. Classification of the email by P-Verifier
8. Retrieval of email by an email client
P-Messaging has been implemented using Java 1.4. The P-Messaging Trust Authority uses Remote Method Invocation (RMI) to generate the PKI key pair for the privileges as well as for the P-Server. For transmitting the mail from the client to the P-Server, the RMI architecture is used. The P-Server uses Java Mail API to transmit the mail to the MTA. The MTA is Sendmail. Sendmail has been chosen as it allows an external entity, a Milter, to classify the messages. A java implementation of Milter is provided using Jilter API . The systems running the mail servers also provide IMAP services using the Cyrus IMAP server. This module essentially functions as the P-Verifier that provides digital signature verification.
1. Sender and Receiver Configurations
Privilege Messaging allows two different changes to the configurations to the sender and requires a single configuration to the receiver side. The support for legacy email servers and clients are required to allow the list of privileges when sending an email and for retrieval of the emails. The retrieved emails need to be classified based on the associated P-Tag.
1.1. Sender Configuration
As described above, the sender side configuration can be created by two different methods. The first method requires changes to the email client so that the user privileges can be retrieved from the P-Server. With the change in the email client, the email can be sent with the user being able to select the privilege. The second configuration requires the privilege selection with the help of a simple rule based privilege selection engine where a privilege is selected while sending an email to a specific user/ group of users.
1.2. Receiver Configuration
As discussed, the receiver side configuration is minimal. The receiver side installation is a one time installation of P-Verifier for Sendmail. The P-Verifier, which is a Jilter, needs to be added to the Sendmail configuration file. The following is the configuration lines:
O InputMailFilters = Jilter Name
X Jilter Name, S=inet:port @ IP address
The configuration needs to be added to the /etc/mail/sendmail.cf (Fedora Core) configuration file. Figure 1 shows the configuration for Sendmail.
2. Test Setup
All of the experiments have been performed using the following devices and networks with the specified configurations The client and the P-Messaging Trust Authority runs on Intel Pentium 4 CPU 3.20 GHz with 1.5 GB RAM running Microsoft Windows XP Professional version 2002.
The two mail servers run Sendmail 8.12.10. The first system is: Intel Pentium 4 CPU 2.5 GHz with 512 MB RAM running Linux 2.6.14 Kernel: this system accepts mails. The second system is an Intel Celeron 2.5 GHz with 1 GB RAM running Linux 2.6.12.6. This system serves as the primary P-Server, the sender domain. The Local Area Network bandwidth was about 100Mbps with a delay of about 0.1 – 0.2 milliseconds.
3. Adding and Revoking a P-Server to the CoT
Maintenance of the CoT is important for a P-Server to place trust on any other entity. Figure 2 shows the process of adding a P-Server to the CoT. The process of adding the P-Server to the CoT involves creation of a PKI key pair. When installing a P-Server, the P-Server asks the necessary questions to create a PKI key pair. Once the information is gathered, this information is sent to the P-Messaging Trust Authority over RMI which creates the key pair.
Figure 2:Registration of Privilege Server with P-Messaging Trust Authority
Another important aspect of maintaining the CoT is the revocation of a P-Server. The process of revocation, however, is carried out at the P-Messaging Trust Authority. The revocation of the client is performed by removing the P-Server from the trusted list. Figure 3 shows the revocation process of the P-Server. The present prototype implementation of Privilege Messaging does not cache the public keys of the peer P-Server, but the verification is done by looking up the P-Messaging Trust Authority. Thus, the present version of P-Messaging does not use Certificate Revocation List (CRL), to remove the defaulting P-Server.
Figure 3: Revocation of Privilege Server at P-Messaging Trust Authority. The Public key cannot be retrieved by peer Privilege Servers after revocation.
4. Maintenance of the Privilege
Each privilege is created by the P-Server administrator and is managed by a privilege-owner. The privilege-owner is capable of creating and deleting a privilege. Once the privilege modifier is started, a user can create a privilege and assign a privilege-owner. Privilege creation involves the creation of a PKI key pair with the predefined site information. A privilege is created; users can be added to the privilege. Once the privilege is added to the group, the user is added to the member list. Figure 4 shows the privilege management.
Figure 4: Privilege Server Manager Interface that connects to P-Server Admin service to create and delete a privilege
Apart from privilege creation, the P-Server administrator should be able to revoke a privilege from the list. Revocation of a privilege involves removing the users from the privilege and modifying the Member-list. The PKI key pair is invalidated so that the users can no longer use the privilege.
5. User Privilege List Maintenance
Apart from maintaining the Member-list, a user needs to maintain the Privilege List. The Privilege List is a list maintained at the P-Verifier by each user. The list contains all the privileges that are accepted by the user. Figure 5 shows the interface where a user can honor or dishonor a privilege from the privilege list. The privilege list maintenance is implemented using RMI. The privilege list is maintained at the P-Verifier of each of the domains.
Figure 5:Client Interface that connects to Privilege Server to honor or dishonor a privilege for a user. To honor or dishonor a privilege at client, the information about the Privilege Server that handles the privilege is required. The example above shows a professor managing two different privileges: class1141 and class6102
6. Sending a Privileged Email
Figure 6 shows the method in which a mail is sent by a user using our initial prototype. Once the user elects to send an email from the client interface, the interface shows all the privileges that can be used to send an email with. Once the privilege is selected and the message is sent, the message is sent to the P-Server. The P-Server adds the privilege signature to the email and sends the email out.
Figure 6:Client interface to connect to a Privilege Server to send an email. The client required to select a privilege to send an email
7. Classification of the email by P-Verifier
Figure 7 shows the classification of the email by P-Verifier. As described in previous sections, P-Verifier is a Jilter interface that verifies the emails based on the privilege information provided by the email.
P-Verifier classifies the mail, as shown in the Figure 7; the Jilter accepts the emails on a specified IP address and the port. The Output is shown in the following format:
[Receiver] [Sender] [Subject] [Privilege Verification Status]
8. Retrieval of email by an email client
Figure 8 shows the mechanism used to retrieve the mail. As discussed in the section 5.2, the email client is a prototype model that demonstrates the classified mails that are classified. Once the emails are retrieved, the messages are classified based on the attached P-Tag. An email client that creates multiple ‘inboxes’ for each privilege for a user, would enable access to the emails in one location. Such a service would provide QoS for the users who would like to access all their emails at one location.
