1. P-Messaging: Functional Components
2. Circle of Trust in P-Messaging
2.1 Addition of P-Server to the CoT.
2.2 Revocation of P-Server from the CoT.
2.3 Advantages of CoT.
3. P-Messaging: Architecture
3.1 Sender Architecture.
3.2 Receiver Architecture.
3.3 Recursive Privilege.
3.4 P-Messaging Classes.
4. Privilege Tag
4.1 Extensible P-Tag.
4.2 P-Tag Creation and Maintenance.
4.3 User Privilege List Maintenance.
P-Messaging Design and Properties
P-Messaging stipulates that the verification of the privileges held by the email will determine its authenticity and relevance to a particular user. Each email ID can be assigned multiple privileges: for instance, each email ID would be associated with various groups, such as one for each department in a graduate school, one for each project team in a development environment. The granularity of a group can be defined by the users. Using P-Messaging, an email ID, based on the privileges held, can communicate with users who authorize content through the privilege. As each privilege has a PKI key pair, digital signatures are used to verify the privileges associated with the emails.Capable of supporting different Message Transfer Agents (MTA), P-Messaging provides both better security and improved QoS over the present email infrastructure. The MTAs provide the essential services of relaying, spooling, queuing and sending emails; hence, P-Messaging is a gradual process of introducing the authorization feature. To support such deployment, P-Messaging framework along with the MTAs provides trust based communications.
In most cases, unsolicited email arises from mail servers that are either (i) Zombie or (ii) Temporarily set up unauthorized servers. Towards controlling the unwanted traffic from them, creation and maintenance of a Circle of Trust (CoT) among P-Server is essential. A CoT is a trust relationship formed between a sender and a receiver due to the trust placed on them by a common third party entity, such as a Certificate Authority (CA). Using CoT, qualified trust can be placed by a receiver on a sender since the CA is responsible for maintaining the trust among the entities.
With the help of the CoT, any email received that is not trusted is placed in an no-privilege class, which forms the lowest available privilege class. P-Messaging classifies emails for the receivers into multiple classes where only mails from the members of the CoT would be classified into privileged classes. Each server in the CoT continually strives to remain a part of the CoT. Any attempt to create unsolicited content will result in the trust being revoked. Members of the CoT are capable of informing the admin of a particular system about possible spam arising from it. Thus, the CoT creates trust among P-Messaging Providers. The trust maintainence among the members will be discussed in Section 1.2.
The following sections discuss the functional components of P-Messaging, architecture for CoT, followed by the architectures of P-Messaging and finally management of the P-Messaging providers.
1 P-Messaging: Functional Components
This subsection discusses the functional components of P-Messaging. These components consist of the:P-Messaging Server
P-Messaging Privilege Verifier
P-Messaging Manager
P-Messaging Trust Authority
P-Messaging Server
P-Messaging Server
Architecturally, P-Messaging Server (P-Server) is a sandbox before the MTA. The users interact with the P-Server, which in turn interacts with the MTA. The user sending a message received by P-Server is validated and appropriate credentials (i.e. privileges) are attached to the message. Finally, the message with the attached credentials is then transmitted to the receiver through the MTA.The P-Server provides different services: (i) User Authentication Service, (ii) Privilege Lookup Service, (iii) Message Signing Service and (iv) Privilege Admin Service. The User Authentication Service provides a mechanism to authenticate a user to the P-Server. This Authentication Service can be password-based authentication schemes. Privilege Lookup Service, based on a rule-based engine, allows senders to look up their privileges. Once the privilege is selected, the Message Signing Service signs the email based on the privilege and then with the P-Server’s key. The Privilege Admin Service, on the other hand, provides an administrative interface to add and revoke users and privileges.
P-Messaging Privilege Verifier
P-Messaging Privilege Verifier (P-Verifier) provides Privilege Verification and email classification services. Upon receiving a privilege signed email, "P-Verifier" verifies and based on the authorization presented, classifies the emailThe P-Verifier provides two services: (i) Message Authorization Service and (ii) User Privilege Maintenance. The Message Authorization Service verifies the validity of emails and based on the privileges accepted by a user, classifies the mails into different privilege classes. The User Privilege Maintenance service maintains the list of all the privileges accepted by a particular user.
P-Messaging Manager
The P-Messaging Manager is a component that connects to the Privilege Admin service of the P-Server and provides an interface to add and remove both users and privileges. As discussed above, each P-Server has an administrator who has the capability to maintain the privileges. The administrator has the ability to add and remove privileges. While creating a privilege, the administrator nominates a privilege-owner. The privilege-owner is responsible for maintenance of the users of the privilege. The privilege-owner has the capability to add and delete users from the privilege.P-Messaging Trust Authority
The P-Messaging Trust Authority is the entity that creates a CoT among P-Servers by providing a certificate to each P-Server. With the help of a digital signature-based mechanism, the trust on the senders’ P-Server can be verified by the receivers.2 Circle of Trust in P-Messaging
P-Messaging provides the capability of verifying a sender P-Server by other peer P-Servers before placing any trust on them. The CoT among the P-Servers is formed with the help of the PKI infrastructure. Honoring the privileges held by a P-Server across domains is dependent upon the maintenance of the trust placed upon it by the P-Messaging Trust Authority. If a P-Server sends an unsolicited email, the trust placed on it by the Trust Authority can be revoked. To be able to send authorized emails to other P-Servers that are a part of the CoT, a P-Server would strive to be a part of the CoT.With the help of privilege verification, a recipient can first authorize and then classify the incoming emails into privilege classes. If an email, whose privilege is not honored, is received, it is placed into an underprivileged class. However, if a sender’s P-Server is not in the CoT, the message is placed into the unsigned class.
The following subsection describes the various methods in which a CoT is created and maintained in order to support Privilege Messaging.
2.1 Addition of a P-Server to the CoT
Figure 1 describes the hierarchical structure of P-Messaging, where the P-Messaging Trust Authority forms an entity that functions as a CA. We make the assumption that the P-Messaging Trust Authority is trusted by all the P-Server. Each P-Server must receive a certificate from the P-Messaging Trust Authority, and verify the P-Server. Each P-Server in turn maintains or moderates multiple privileges. Each of the privileges has its own PKI key pair capable of signing the emails.
Creation of the CoT requires each P-Server to store the keys in a secure manner. The key store that holds the private key of the privileges should be maintained securely; i.e., in case of an unauthorized access, the keys must be destroyed. In case of the unauthorized access of the private key of the privilege, the administrator can easily revoke the privilege and create a new PKI key pair for the privilege. We discuss revocation policy adopted a CoT in the next section.
2.2 Revocation of a P-Server from the CoT
The P-Messaging Trust Authority has the authority to revoke a P-Server based on an issuing agreement of the certificate. One of the attributes of the issuing agreement could be the number of instances an unsolicited mail is reported by users before revoking a P-Server. Once revoked, the P-Server can request a new certificate from the P-Messaging Trust Authority. The P-Messaging Trust Authority can place additional constraints on the P-Server before issuing a new certificate. This paper discusses the methodologies involved to revoke a client; the pre-stipulated grounds for revocation of a P-Server are beyond the scope of this paper.
Upon compromise of a privilege, the P-Server administrator is responsible for revoking a privilege. If the privilege is not revoked, the P-Server itself will be revoked from the CoT, thereby invalidating all the privileges held by it. Hence, it is contingent upon the P-Server administrators to maintain the trust placed upon it. A P-Server is responsible for maintaining the legitimate users for each privilege maintained by the P-Server and is delegated to the privilege-owner.
To reiterate, the negative characteristics of a privilege-user will flow upward to their privilege, where if the user is not revoked by the privilege, the privilege is revoked by the P-Server. If the P-Server would not revoke the privilege, the P-Messaging Trust Authority will revoke the P-Server.
2.3 Advantages of CoT
With the help of CoT, a P-Server can be verified by other P-Servers in the CoT. In other words, as shown in Figure 1, each P-Server acts as a CA for the multiple privileges maintained by it. With the help of CoT, each P-Server independent possess the capability to create and maintain the privileges that are associated with it. Privilege honoring can be performed due to the trust placed on the P-Server by the P-Messaging Trust Authority. This provides for a method of distributed authorization among P-Servers where each P-Server is capable of creating its own privileges. To reiterate, with the help of CoT, a scalable architecture with fine-granular email authorization can be provided.3 P-Messaging Architecture
As discussed in earlier sections, P-Messaging provides message verification, thereby, classification based on the privileges held by an email. With the help of P-Messaging as shown in Figure 3, legitimate messages can be honored across domains where each domain is managing multiple P-Servers.
Privilege Messaging allows users to send and receive the messages. In the sender architecture, the P-Server attaches privileges on behalf of the user. In the receiver architecture, these privileges are verified before being delivered to the receiver. The following sections discuss the two architectures in further detail.
3.1 Sender Architecture
As shown in Figure 2, when sending an email, the P-Server first verifies the sender, for instance, Bob. After verification of the user, the P-Server signs the mail with the privileges requested by Bob. The selection of the privilege can be performed by Bob, or the P-Server can select a privilege with the help of a simple rule based engine. The privilege is selected from the Member List maintained at the P-Server. This list is maintained on the P-Server for each user. Once the message is signed with the privilege, the message is then signed by the P-Server itself, before relaying it through the MTA to the users who accept the said privilege.
P-Server signature on the email ultimately allows other P-Servers to verify the mail. For example, when a P-Server is installed for a university, the P-Messaging Trust Authority creates the key pair for the P-Server. The university P-Server can then create multiple privileges, for example, faculty, and student privileges.
For a receiver to accept a message, the receiver should honor the sender’s privilege. Without this, the message that is sent cannot be classified into privilege classes but is classified into an underprivileged class. These classes are described in later sections.
3.2 Receiver Architecture
Figure 3 shows the receiver architecture in detail. On the receiver’s domain, the MTA, upon receiving the email, verifies the privileges with the help of the P-Messaging Privilege Verifier. For verifying a mail, the P-Messaging Privilege Verifier first verifies the P-Server signature, thereby, checking the authenticity of the P-Server in the CoT. Once the sender’s P-Server is verified, the privilege’s public key is retrieved from the P-Server and the email is verified.
Once the mail is verified, the next step is to classify the mail into classes. This is performed by checking the user’s Privilege List, which contains all the privileges that are accepted by a user. If the receiver honors a privilege, the mail is classified into the privilege class. The classification of the mail is performed by adding header information to the mail representing the classification information of the email. If the mail is not honored by the user, the mail is classified into an underprivileged class. If, however, the message is not verified or not signed, the message is classified into the unsigned class. We further discuss the privilege classes in the sections below.
To retrieve the message, as shown in Figure 3, the client, for instance Alice, connects to the mail server to retrieve the messages. Using the additional header information, any email client can display the information in any desired format. The mail clients can show the different ‘inboxes’, where each inbox caters to a different class. In this way, the classification of the email into different classes provides users with the ability to view the messages according to the privileges accepted by them. This allows a faster lookup for the emails by classifying the emails at one location thereby, providing QoS for the users.
3.3 Recursive Privilege
Another benefit of P-Messaging would be to request a privilege from another P-Server on the basis of a privilege that is held by the email. For example, as shown in Figure 4, a user in the UNCC domain requires the USENIX privilege to send an email. The UNCC privilege would not be accepted by the authors of LISA. However, on the basis of the privilege of Bob’s Privilege, the LISA privilege can be obtained. The LISA privilege can be used to communicate with other users of the Privilege LISA. Figure 4 shows the Sender architecture for Recursive Privilege mechanism. The advantage of such a technique is that users can sign using their privileges across another administrative domain before sending the email. Another example would be a user using a free email ID to sign the mail using the class privilege to send the mail to the faculty who teaches the course. A single mail can thus have multiple privileges, demonstrating to the receiver the sender’s multiple credentials.
Recursive Privilege requires the member list for a user be maintained across domains. The member list contains the list of members who are authorized to send an email using the privilege. A privilege can be created for each user for enabling cross domain privileges. This enables users to attach a privilege as a single user rather than the complete group. While requesting an email, the P-Server sends the privilege tag information of the first privilege. Instead of transmitting the complete message to the secondary P-Server, only the privilege information can be sent. This requires that only a small amount of information be transmitted over the wire to receive additional privileges. After verification of the privilege, the peer P-Server verifies the privileges and attaches its own privilege. Moreover the verification of the privileges will be based on recursive verification of each privilege’s information, allowing users to trace the order of privilege selection.
3.4 P-Messaging Classes
P-Messaging defines multiple Privilege Classes for the emails classified for the receivers. These classes take into consideration the credentials presented by the email as well as the receivers preferences. The user preferences indicate the list of the privileges that are further honored after the email has been verified. As described earlier, P-Messaging provides QoS with the help of this classification. We define the Privilege Classes into three categories:
Privileged Classes
Privileged Classes are the classes into which the emails that have been successfully verified and are honored by the receiver are placed. The emails can be further classified based on the privileges that it is associated with it.
Underprivileged class
Underprivileged classes are those where the emails are verified, but the associated privileges are not honored by the receiver. If the privilege presented by an email is deemed important, the receiver may subscribe to the privilege.
No-privilege Class
The no-privilege classes form the lowest class among the privilege classes, where unsigned or emails whose authenticity cannot be ascertained are placed. As P-Messaging becomes widely accepted, the number of mails in the no-privilege class would be reduced to a minimum.
4 Privilege Tag
Each email possesses credentials that allow the email to be classified into different classes. These credentials, referred to as Privilege Tag (P-Tag), provide the users with the information about the sender with the help of a digital signature. The digital signature demonstrates the authenticity of the origin of the email.
In this section, we describe the format of the P-Tag and the various interfaces that are required to maintain the privilege.
4.1 Extensible P-Tag
As described above, the P-Tag information contains the privilege’s digital signature. P-Messaging Tag management is extensible, so that each P-Server creates its own privileges, allowing true extensibility. Each P-Server maintains privileges’ public keys for other P-Servers to verify the email. Thus, each P-Server acts a CA for the privileges held by it. The format of the P-Tag is as follows:
[P-Server]:[Privilege]The P-Tag information is appended as a part of the email header. Conceptually, the following is the structure of a Privileged message:
{[Tagged Email] Privilege Signature}: {[Privilege Signature] P-Server signature}The privilege signature is created on the email. The P-Server signs the Privilege Signature. Hence, to verify a privileged email, first the P-Server signature is verified. Once the P-Server signature is verified, the Privilege Signature needs to be verified.
In the case of Recursive Privilege, the P-Tag information is shown below:
{[Tagged Email] Privilege Signature}: {P-Tag 1}: ({P-Tag1 }:P-Tag 2) …
Where P-Tag n is {[Privilege Signature] P-Server signature}
As discussed in sections above, in the recursive privilege tag assignment, multiple privileges are attached to the signature based on the privileges already presented by it. The complete message need not be transmitted to the second P-Server, but only the P-tag information is needed to verify the sender of the privilege to identify and attach a new privilege to it. The next few sections describe the method for creating and maintaining the P-Tag information.
4.2 P-Tag Creation and Maintenance
As part of Privilege Management, apart from creation and maintenance of the privileges as described in section 1.2, a privilege-owner performs the tasks of adding and deleting/revocation of users. The privilege-owner is also responsible for:
1. Adding a Privilege to a user.
2. Deletion or Revocation of a user’s Privilege.
Addition and revocation of privileges deal with modifying the Member List for a user. The Member List, as discussed in the section 1.3.1, contains the privileges a user is authorized to send with. A user can be added or revoked to the Member List only by the privilege-owner. If a user wishes to be added or deleted, a request should be sent to the privilege-owner. If the privilege-owner considers the request, the Member List will be updated at the P-Server; otherwise, the request is rejected.
However, if a user abuses the privilege, the privilege-owner should revoke the user. The revocation of the user will be performed by removing the user from the Member List. As the private key of the privilege is not revealed to the user, the privilege-owner need not create another PKI key pair for the privilege.
4.3 User Privilege List Maintenance
Each user maintains the Privilege List at the P-Verifier. This information needs to be updated by the user to classify the emails based on the privileges listed in the Privilege List. If a user wishes to honor a privilege, the user updates the privilege list with the P-Verifier. Adding a privilege to the privilege list is similar to maintaining white-lists albeit at the server side.
To assist users with initial list of privileges, a default list of privileges can be assigned to users by the mail service provider. This allows a default privileges associated with a user during the setup phase. In the absence of a user’s input, which we believe quite common, the service provider’s default list will be used. Some user-profiling and personalization techniques may be useful in determining the list on behalf of the user.