Rutger S.J.A. van de Gevel
rutger@kub.nl
The recent promotion of the Multi-purpose Internet Mail Extensions (MIME) specification [1] to Internet standard has opened a whole new dimension of applications for electronic mail. MIME enables users not only to send (passive) multimedia data like video, audio, images and spreadsheets but interactive programs as electronic messages as well. These new possibilities can be characterised by the term Enabled Mail. According to N. Borenstein [2], enabled mail encompasses several technologies that share the common goal of significantly increasing the power and utility of electronic mail systems by introducing computational power at several key points in the electronic mail process. Ultimately enabled mail may be used to overcome some of the incompatibilities between Unix and non-Unix operating systems, notably mechanisms for distributed applications that support asynchronous co- operative work.
Working in a group means that group members have to communicate, collaborate and coordinate to perform certain tasks. Communication is necessary to exchange information between members. Collaboration means acting collectively towards a common goal. Coordination is needed to synchronise all group activities. Planning, control and integration will improve the overall effectiveness of the collaboration. The term groupware originates from the scientific research area of Computer Supported Co-operative Work (CSCW). M. Fridael [3] defines CSCW as follows:
CSCW (groupware) is the melting of communications and computing technology to support work in groups, varying in time, space and control that serve organisational goals: being interdisciplinary and involving computing, management, engineering, behavioural and social disciplines.
This definition is a starting point to build a possible classification of CSCW- systems. The classification dimensions come from the above definition: time, space and control.
These criteria form a three-dimensional framework that can be used to classify the following CSCW systems:
Figure 1: 3D Classification of Mail Systems
Since mail systems are the primary interest of this paper I will not mention the other CSCW classes here. I refer to [3] for a thorough discussion of the classification model. Figure 1 shows that mail systems support asynchronous communication and that people are working at remote locations. Traditional electronic mail systems use messages that have no special structure and usually contain plain text. This kind of mail systems may be classified as non-procedure based systems. Enabled mail systems are classified as procedure based systems, since message structures conform to the MIME specifications. Moreover enabled mail messages may contain customized instructions that may be executed by someone or by yet another program. Figure 1 shows that traditional mail systems are located in cube A; enabled mail systems are located in cube B at the top.
One way to solve incompatibilities between operating systems is to find a common denominator and to build a system on top of this denominator. Electronic mail is available on almost every system, including (MS-)DOS, OS/2, VAX/VMS, Unix, Apple, etc. Furthermore email is independent of user interfaces: it can be used in a text-only environment as well as in a sophisticated windows system and it is standardised on the Internet network where it has a large user base. In combination with a news distribution system like Usenet-news it can form a powerful mechanism that supports distributed asynchronous applications. One should keep in mind that electronic mail has its limitations. It is not designed to be used in situations that require real-time-based interactions. Anyway, email is still a passive medium: people can only read messages: the message itself cannot ask the recipient questions nor can it process the answers. Traditional email does not support user interaction by means of executing a program that is embedded in a message. The basic idea of enabled mail is simple: add computational power to traditional email systems at several key points in the electronic mail process. Perhaps the most crucial implication of computational power is the shift of control. In traditional email systems control was in the safe hands of the recipient: he/she had the power to decide what was to be done next. Now in enabled mail systems the recipient looses control in favour of the originator. The originator can define procedures that are executed when the recipient receives the message. Even an innocent looking "automatic message read notification" can be a privacy threat to an employee, as his superior is able to keep track of the actions of the employee.
Figure 2: Standard Message Handling Model
Figure 2 shows the key components of the message handling process and their relations. Users send messages via the user agent (for example /usr/bin/mail) to other users. The user agent sends the message to a message transfer agent (MTA). The transfer agents keep on relaying the message to other MTAs until the message can be delivered at the recipients mailbox. The collection of several message transfer agents is called the message transfer system (MTS). Normally the message transfer system has no knowledge about the message structure, but user agents should be able to identify and process the headers and body of a message. Therefore there are two locations in the message handling process where computational power can be useful: during the posting process (UA -> MTA) and the delivery process (MTA -> UA). N. Borenstein and M. Rose [4] have enhanced the standard model for message handling by viewing the delivery process as consisting of three distinct phases:
The problem with the current electronic mail system is that the computational power is not always present at all phases of the delivery and posting process, nor has the implementation been standardised. Some user agents support automatic delivery confirmation: others do not support this feature of computational power at all. Even if two different user agents both support delivery confirmation it may not work, because each user agent can have a different implementation that is incompatible with other the user agents. What is needed is a language that can be used to implement the computational power for all these phases of the message handling process. However, before this problem can be solved, it is necessary that the message structure is modified to accommodate the demands that enabled mail makes on messages.
The standards that form the basis for Internet electronic mail have been specified in 1982 in a number of documents, called Requests For Comments (RFCs). RFC 821 specifies the Simple Mail Transfer Protocol (SMTP), whereas RFC 822 specifies the format for Internet text messages. Although at that time RFC 822 was state of the art, it does not meet the needs of the present and the future. Limitations of the RFC 822 standard are:
In order to overcome these limitations a new standard has been developed and is specified in RFC 1521: "Multi-purpose Internet Mail Extensions: mechanisms for specifying and describing the format of Internet message bodies". MIME is completely backwards compatible with RFC 822. The most striking modifications are that messages can now have multiple bodies and their content is no longer limited to plain text only. This is done by adding new header fields and several encoding algorithms to allow for RFC 822 conformity and transport compatibility with SMTP. The following section is a summary of the major MIME header fields as defined in RFC 1521. Note that this list is not complete: a more detailed overview can be found in RFC 1521.
One of the advantages of MIME is that it is an open-ended standard. This means that new content-types can be added to accommodate the email-based transport of new data types. In the future, for example, the content-type "smell-o-vision" may be added to allow for transport of 'smelly messages'. There are two ways to extend MIME. If a new content-type is intended to be used universally through the Internet, it should be registered at IANA. (Experimental) content-types which are to be used by consenting mail systems by mutual agreement, can be created at will. However, these private content-types should always begin with the characters "X-", but are not required to be registered at IANA.
Click here for an example of a MIME-message.
The MIME standard itself does not raise new security problems, though it can be used to send messages that are a threat to security. Potential security risks are messages that contain application/* content-types. Perhaps the most obvious security threat is content-type: application/postscript. The postscript interpreter allows a virtually unrestricted access to the recipient's resources, like files, system privileges, and processes. Clearly this kind of unrestricted access cannot be tolerated. To prevent misuse, a restricted version of the postscript interpreter is available so that it can safely be used with MIME based mail.
So, with MIME it is possible to include, in a standardised way, arbitrary types of data objects with RFC 822 conformant mail messages. It is now time to turn our attention to other problems that arise in enabled mail systems: finding a general- purpose programming language (or any other usable application) that safe guards users (recipients) against malicious users who try to delete the recipient's files or steal confidential information via active messages. Security is the most important consideration when it comes to selecting such a language or application. Other considerations are power, extensibility and portability.
Tcl and Tk, designed by J. Ousterhout [5] provide an initial suitable environment. Tcl is an acronym for Tool Command Language and is pronounced as "tickle". It is a simple, though powerful programming language that has all the features of a general purpose-programming languages: variables, procedures, arrays, program-flow-control (for..do, if..then..else, etc.), string manipulation, file access etc. Furthermore, Tcl is embeddable: its interpreter is implemented as a library of C procedures that can easily be incorporated into applications, and each application can extend the core Tcl features with additional commands specific to that application. TK (pronounced as "teekay") is a Tcl ToolKit for the Unix X-Windows system. TK is used to develop user interfaces for X-Windows. TK has also been implemented as a library of C procedures and is also embeddable. By now there are several Tcl/TK applications available:
N. Borenstein and M. Rose have introduced the first general purpose programming language for enabled mail: Safe-Tcl. This language is an extended subset of Tcl and is designed to solve the security problems that arise with enabled mail, while offering a powerful scripting language and a high-quality graphic user interface. The only difference between Tcl and Safe-Tcl is the set of available primitive functions and procedure. In Safe-Tcl all the "dangerous" primitives that exist in Tcl have been removed and new, safer, primitives have been added. Safe-Tcl is based on a "twin interpreter" model: a trusted interpreter and an untrusted interpreter. Untrusted code (such as in an active message) is evaluated in the untrusted interpreter. The trusted interpreter never directly evaluates untrusted code, but may be used to extend the untrusted interpreter via mechanisms that are defined as part of the Safe-Tcl language. As long as the extensions are carefully designed and implemented, this kind of extensibility should not compromise security. With regard to interface portability, Safe- Tcl offers both a text-oriented user interface and a high-quality graphical user interface (GUI). When a GUI is available the recipient can respond by clicking buttons or picking items from a picklist, otherwise he can type answers in a text-oriented environment.
A weakness of Safe-Tcl is that it is currently available on Unix systems only. However, Tcl/Tk has been successfully ported to MS-Windows. Rumors suggest that people are working to port Safe-Tcl to MS-Windows and other systems.
Click here for an example of an embedded Safe-Tcl script.
Quite another way to solve incompatibilities between operating systems by means of active messages is to use existing applications, such as database management systems (DBMS). Since MIME enables users to send and receive arbitrary types of data objects, it can also be used for email-based transfer of database forms, reports, queries, etc. Figure 3 shows the enabled mail process if a DBMS is used as a user environment.
Figure 3: DBMS as a secure and portable environment for active messaging.
The major advantage of using a DBMS is that users already work in a safe and restricted environment where each database user has specific rights. If necessary, extra security can be obtained by using database views instead of tables. As many database management systems have been ported to other operating systems the problem of portability has already been solved: forms generated on one operating system should be usable on another operating system if both systems have the same DBMS. There are no problems with respect to remote installation and user buy-in, since the DBMS has already been installed and users know how to use the system.
As has been made clear in previous sections it is vital that recipients can trust the originator of an active message. Therefore it is necessary that the identity of the originator can be verified and that the message has not been modified during transport. In some cases confidentiality may also be an important issue. Encryption is a universally applied technique to ensure authenticity, integrity and confidentiality of messages. A crypto-algorithm is used to transform data through an encryption process. The input of this process is called plaintext and the output is called ciphertext. The encryption is reversed by a decryption process, which accepts ciphertext and yields plaintext. Both processes are controlled by a key, which is a parameter to the process. Figure 4 shows the encryption/decryption process.
Figure 4: The encryption/decryption process
In symmetric crypto-systems Key-1 and Key-2 are identical. Using a single key implies that this key has to be transmitted from originator to recipient via a secured transport mechanism. The Data Encryption Standard (DES) is a symmetric crypto- system. Asymmetric cryptographic systems use two distinct but mathematically related keys. One key is secret and is known only to its owner, while the other key is made public. Hence the name "public-key cryptography". In normal situations the secret (private) key can not be calculated from the public key. Everybody may use the public key to encrypt a message for someone with the corresponding secret key. Nobody except the owner of the secret key can decrypt the message. Message authenticity is supported by adding a digital signature to a message. With the public key the digital signature can be verified and therefore also the identity of the originator. Encoding and signing can be combined to guarantee privacy, integrity and authenticity: first the message is signed using the secret key of the originator; then the message is encrypted by using the recipient's public key. The recipient reverses the process by decrypting the message with his own private key and then verifying the digital signature with the originators public key. Usually cryptographic software takes care of both processes.
Privacy Enhanced Mail (PEM) [6] is the provision of security of email users by applying public-key crypto-algorithms. The PEM effort began in 1985 under the auspices of the Internet Architecture Board (IAB) and has resulted in a set of RFCs (1421-1424) that have presently the proposed status. Various software implementations for public-key mail encryption are available. M. Riordan's Privacy Enhanced Mail (RIPEM) and Pretty Good Privacy (PGP) from P. Zimmerman are two widely used systems. The major differences between PGP and RIPEM are:
There are several legal considerations when using cryptographic products. Distribution and export of cryptographic products from the United States and Canada, fall under the International Traffic in Arms Regulations (ITAR) and unlicensed exports are prohibited by US law. Therefore RIPEM is not available for users outside the US, however PGP has managed to slip outside the US and is now widely available. Another legal issue is that in some countries cryptography is illegal: Iran and Iraq have outlawed the use of it. A few months back the Dutch government proposed new (anti-) cryptography legislation, but the proposal was withdrawn later on.
Just how safe are RIPEM and PGP? Of course, any crypto-system is useless if it is used incorrectly or carelessly. The most important aspect is the safe-keeping of one's own private and secret key. Once that private key is no longer secret, other users can use your secret key pretending to be you. Also by creating a private/public key combination for someone else you may upset trusted relations. One should always be careful to accept public keys from other people. Another more serious threat comes from the scientific research area known as crypto-analysis, which is trying to break secret keys by using mathematical techniques. Until recently people assumed that a 516bit key would be practically impossible to break. On 27 April 1994 an announcement was made in several Usenet newsgroups that RSA-129 had been broken. It had taken about 5000 mips years: 600 volunteers from more that twenty countries have worked for eight months to break that key. This means that only one possible RSA key has been cracked: if someone else uses the same resources, other RSA-129 keys could be cracked as well. For now 1024bit keys are considered to be practically unbreakable. So RSA is still quite safe, so are RIPEM and PGP...
In order to extend traditional electronic mail systems to support MIME, it is necessary that architecture of the user agent is modified. A typical traditional user agent has the following components:
Enabled mail systems need besides the message interface and message manager an interface to support MIME. In addition a language like Safe-Tcl should also be present to add computational power (like automatic delivery confirmation, active messaging and encrypting/decrypting). Existing user agents can, with some minor modifications be made to be MIME compliant by calling an external interface. Metamail is such a program and has been developed by N. Borenstein. Metamail is available for Unix systems and also has been ported to many other operating systems, including (MS-) DOS, Apple, and Amiga. The architecture of MIME compliant mailers with an external MIME interface is shown in figure 5.
Figure 5: The components of a MIME compliant user agent, using Metamail
Whenever a user agent detects MIME message it executes Metamail. Metamail then consults various mailcap files to determine the correct viewer to display the data. Mailcap files map content-types to their corresponding viewers. RFC 1343 [7] specifies the format of the mailcap files. Finally the correct viewer is executed to display the data. Metamail's major advantages are:
It is likely that future mailers will include their own internal MIME support interface, thus obsoleting Metamail. However mailcap files will probably be the best way to map content-types, since the all major MIME support interfaces depend on this principle.
The conclusions of this paper can be split into two groups. The first group of conclusions is related to the new possibilities that MIME offers. The second group is related to enabled mail.
MIME specific conclusions.
The Multi-purpose Internet Mail Extensions standard offers a wide range of new applications of electronic mail. MIME compliant mailers are able to process arbitrary types of data objects. MIME's major strength is that it is a flexible and open ended standard. Another important advantage is the complete backwards compatibility with SMTP and the (old) RFC 822 message format. Mailers are easily adapted to conform to this new standard by using an external MIME interface like Metamail, in combination with mailcap files.
Enabled Mail specific conclusions.
Traditional electronic mail is a suitable mechanism to solve certain incompatibility problems between operating systems for applications that allow for distributed asynchronous work, but miss the ability of interactive communication of users via messages. Enabled mail systems do have this important feature. However, the ability to send active messages can pose a security threat to users of enabled mail. Other problems that arise are portability and extensibility of an enabled mail programming language. A promising solution to these problems is Safe-Tcl: a safe Tcl/Tk related interpreter for Unix systems that offers also a high quality graphical user interface. Another possible solution is to use existing applications to provide a safe and portable interactive environment. Database management systems are suitable for this purpose. It is vital that a recipient of an active message can trust the originator. Therefore it is necessary to be able to verify the originator's identity. In many cases it will also be useful to be able to check message integrity, before evaluating an active message. In some situations confidentiality may also be required. Cryptography offers all these features. Thus the combination of cryptography and enabled mail with Safe-Tcl, results in what is called Privacy Enhanced Mail. PEM should be able to guarantee a safe and user-friendly interactive enabled mail system.
[1]: Borenstein, N. and Freed, N., "MIME (Multi-purpose Internet Mail Extensions) Part One: Mechanisms for specifying and describing the format of Internet message bodies", RFC 1521, September 1993.
[2]: Borenstein, N., "Email with a mind of its own: the Safe-Tcl language for enabled mail".
[3]: Fridael, M.R., "A computer supported cooperative work environment for an authoring tool", master thesis, October 1993.
[4]: Rose, M., and Borenstein, N., "A model for enabled mail (EM)", draft in preparation, July 1994.
[5]: Ousterhout, J.K., "Tcl and the Tk ToolKit", parts 1-4, draft version, November 1993.
[6]: Kent, S.T., "Internet Privacy Enhanced Mail", Communications of the ACM, august 1993, volume 36, number 8, page. 48-60.
[7]: Borenstein, N., "RFC 1343: A user agent configuration mechanism for multimedia mail format information", RFC 1343, June 1992.