draft draft draft draft draft draft draft draft - Semantic Scholar

AF T

A Framework and Prototyping Environment for a W3 Security Architecture Gustaf Neumann

University of Essen, Germany Information Systems and Software Techniques [email protected]

Stefan Nusser

Vienna University of Economics and BA, Austria Management Information Systems [email protected]

June 25, 1997

Abstract

This paper presents an architectural framework, which identi es the core services necessary for a secure Internet-based communication and information infrastructure. We show how these services can be realized using existing software packages and new technologies. Then, we turn to the development of security infrastructures using the rapid prototyping environment \Wafe " and the extensible Web browser \Cineast ". We explain how basic operations such as secure transfer and certi cate acquisition can be realized and demonstrate the implementation of dierent certi cate veri cation strategies. Finally, we show how advanced trust management concepts can be developed and tested. Concluding, we present a comparison with the features of other Web browsers and indicate some directions of future research. The goal of this paper is to identify and describe the services necessary to build a secure corporate Intranet and to show how prototypical implementations of these components can be realized to evaluate dierent approaches and con gurations.

DR

1 Introduction and Motivation

With the advent of the large scale deployment of Internet technology as a foundation for electronic commerce, new requirements for document and communication security emerged in interlinked environments. This tendency was reinforced by the use of Internet applications as a low-priced alternative to classical IS development and to commercial groupware products, which lead to the increasing propagation of corporate Intranets. This evolution of the World Wide Web (W3) towards a company's information system and telecommunication infrastructure triggered the development of several enhancements of the original Internet concepts with the goal of providing a secure distributed computing environment. Most of the security proposals are based on asymmetric cryptography and require the establishment of a public-key infrastructure (PKI), which refers to the distribution and maintenance of trusted public-keys. While the technical concepts are not new, their deployment is dicult for several reasons: Deploying Internet security techniques on an enterprise scale is mostly not a technical, but an engineering and organizational problem. Existing security protocols based on a secure transport layer (such as SSL [5] or PCT [2]) provide a relatively simple technical low level solution for a secure point to point connection, but they leave the end-user or a security manager with many dierent ways to build a security architecture on a larger scale. 1

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

The use of the same techniques for securing Intranet and public Internet communication often leads to a trade-o: Adhering to standards might restrict a company's freedom and exibility, but is an advantage when internal resources should be made publicly available. This is especially true in public-key environments, where electronic certi cates are exchanged among the communicating parties. While a proprietary certi cate format might oer advantages if used in a company's Intranet, this will render the communication with external parties impractical if not impossible. The purpose of PKIs is changing. While the currently used certi cate standards [3] were designed to provide an authentication framework, the motivation behind recent developments in certi cation techniques (such as SDSI [19] or SPKI [4]) is to enhance this mechanism to a means of access control. The most important security access points in a W3 security architecture are along the information ows, where the information source is a W3 server, and the primary information sink is a W3 Browser. In order to prototype new approaches it is necessary to modify and extend the involved software packages in a substantial way. For popular W3 browsers this is not feasible or might be even impossible (plug-ins are not sucient). Therefore the development of new security features is practically in the hands of a few companies who can integrate new features in their browsers. In this paper we identify the building blocks of a secure Internet-based communication and information infrastructure. Following a top-down approach, we describe the functionality of the core services in an implementation independent manner in Section 2. In Section 3 we concentrate on existing certi cation techniques, the properties of the underlying trust models and research activities in this eld. Section 4 describes how the components of the proposed security architecture can be practically realized. In Section 5, we present our implementation framework for dierent security schemes using the Wafe environment [14] and demonstrate its use to extend existing concepts into new directions. There we will concentrate on W3 browsers. This section follows a bottom-up approach, rst describing the basic functionality before we start putting the pieces back together into useful services. We conclude with a summary and some suggestions for future research.

Authorization Service Access Control: Is the subject authorised to access the object ?

Directory Service •

User Information (DN, E-Mail) • Certificates of Users and Services • Revocation Lists

Authentication Service

Domain Management

•

•

Verification of user’s identity • Authentication of the service accessed • Trust Model

Group membership of users • Role assignments • Domain membership of resources

Communication Service

Figure 1: Security Architecture

2


2 The Core Services Figure 1 shows our framework of a corporate security infrastructure. In developing this framework we built in many aspects on existing research in the area of distributed object security (especially [27]) and role based access control concepts (see [21] for an excellent summary). The overall goal of our security architecture is to manage access control in a large Intranet. This is realized by the authorization service shown at the top of Figure 1. The purpose of this service is to determine whether a user has the right to access a speci ed resource. In doing this, the authorization service depends on several other components of our framework. The authentication service is mainly concerned with the reliability and validity of public keys. It authenticates users and services in accordance with a well de ned policy, a process which is often referred to as \Management of Trust ". We will take a closer look at the dierent models and approaches in the next section. Note that the authentication service complements the functionality of the underlying public-key cryptosystem and is completely independent of the algorithms used. The authentication service uses the directory service in order to make information about users and services publicly available. Consequently, the directory service itself is a trusted component of the architecture and will most likely be an authenticated service itself. The information propagated by means of the directory service should be sucient to identify users or services by their commonly known names. In our context it is important that the directory service is the primary device to make public keys available for the public. Any authorization service which has to deal with a larger number of resources or users will have to use some grouping concepts in order to facilitate the creation of access control rules. For this reason, our framework includes the domain management, which provides information on membership relationships for both users and objects. This service can also be used to maintain role assignments and is therefore a good foundation for the implementation of role based access control (RBAC) in an Intranet context (for a general description of RBAC see [21]). All services described so far are based on the Internet protocols as a communication infrastructure. Since the idea of using cryptographic techniques in order to secure the Internet has been around for many years, there are several proposals available for providing a standardized way of transmitting encrypted data or distributing public keys. These mechanisms are shown in Figure 1 as communication service. We will not describe these basic mechanisms in detail, an overview of the dierent approaches can be found in [9]. Since authentication is of special importance to the other services shown in Figure 1, we refer to it as the primary service of our security architecture and cover it in depth in the following section.

3 The Authentication Service: Public-Key Infrastructure and Certi cation Technologies In this section, we further examine the authentication service as a primary component in a secure environment. First we brie y describe the characteristics of the underlying public-key infrastructure and then we focus on the use of certi cates as a means of binding a person's identity to a public-key.

3


3.1 The Public-Key Infrastructure Public-key cryptography basically facilitates two dierent kinds of operations: Encrypt/decrypt: Data encrypted with the private key of the sender (or the public key of the recipient) is decrypted at the recipient with the corresponding key half. Sign/verify: A hash code computed from the data is encrypted by the sender with his private key and decrypted (and thereby veri ed) by the recipient with the corresponding public key. Encryption provides message con dentiality when the data is encrypted with the public key of the recipient and authentication when the data is encrypted with the private key of the sender. Signing provides authentication of the signer and message integrity. These operations are not mutual exclusive (consult [23] for a good introduction). Since public-key operations are computationally very demanding, they are usually not applied on large amounts of data. The performance of the encryption process can be improved by using public-key encryption only during the initial connection establishment phase in order to exchange a session key, which is then used for the symmetric encryption of bulk data. The collection of algorithms deployed in connection with the public-key operations described above is called a public-key cryptosystem. Examples for public-key algorithms are Die-Hellman or RSA, common one-way hash functions are MD5 or SHA and an example for a symmetrical cipher suitable for the encryption of large amounts of data is DES. For an excellent description of these algorithms see [22]. All public-key operations require the existence of trusted public keys. A public-key infrastructure (PKI) provides mechanisms for generating, verifying, distributing and revoking public keys in a global environment.

3.2 Certi cates and Management of Trust A certi cate, as de ned in the CCITT recommendation X.509 [3], binds an entity's distinguished name and some optional attributes to a public key with a digital signature. The certi cate also contains the distinguished name and the signature (with an signature identi er) of the certi cate issuer, an issuer-speci c serial number and a validity period. A Certi cation Authority (CA) is trusted to verify a user's identity in accordance with its particular requirements and issues certi cates. The most common kind of certi cates are identity certi cates. In addition, a CA can also certify other CAs, transferring by this means trust to the other authority's signature. Consequently, certi cates issued by the trusted CA will be accepted by any user accepting certi cates from the signing CA. This delegation of trust is referred to as creating a chain of trust, the overall process of setting up and maintaining these chains of trust is called trust management. In virtually all existing implementations, the certi cation mechanism is based on the CCITT X.509 standards [3], which were developed as part of the X.500 framework. It is important to note that { while many aspects of the X.500 standards were never realized { the X.509 certi cate format is now in widespread use for authenticating persons and services on the Internet. By creating chains of trust, dierent trust models can be realized (see Figure 2). The trust models discussed in this paper have some underlying basic de nitions in common (for detailed de nitions and discussions of the distributed and centralized trust model see [10]): A trust model de nes the chain of trust between trust points, which are representing either persons (users) or CAs. A trust point representing a person has its identity certi ed by at least one CA. 4


A set of CAs and the persons certi ed by these CAs are referred to as a domain. Trust relationships of dierent quality are established between the CAs by direct certi cation or by chains of trust. A CA is trusted to certify persons identities or other CAs, which can be in a hierarchy with the certifying CA (superior superior or subordinate) or not (cross certi cation). Every trust point has a most trusted CA, whose public key was typically obtained by out-of-band mechanisms. Frequently the most trusted CA issues the personal certi cates. In Figure 2 the most trusted CA is shown with a shaded background. The user's CA determines the circumstances under which certi cates issued by another CA may be trusted. Once a trust relationship with a foreign CA is established, certi cates issued by the foreign CA can be accepted without re-establishing the relationship every time, provided that all of the certi cates included in the chain are still valid. We will focus here rst on the simplest model (a at model with a single CA) and on a highly distributed \web of trust" which is proposed by PGP. Then we will present the distributed and the centralized trust model, which are both based on the ANSI X9.75 [1] document.

CA U U U CA CA U U U U U U U (a) Flat Trust Model

CA U U U

(b) PGP-style Trust Model

U U

U U

CA 1

CA 2

CA 3 (c) Distributed Trust Model

Root CA CA 1

CA 2

U U U

U U U

(d) Centralized Trust Model

Figure 2: Dierent Trust Models

Flat Trust Model The at trust model (Figure 2 a) represents the trivial case of a single

CA which certi es all users and services. While this might be sucient in a completely secluded environment, this structure has to evolve towards one of the other models as soon as communication with externally certi ed parties is desired or internal services are to be made publicly accessible. PGP-Style Trust Model The PGP-style trust model (Figure 2, b) is based on the assumption that every user is his own certi cation authority. Accordingly, it is up to the user to decide who is trusted and to de ne his own chain of trust by accepting other people as CA. The resulting structure is often referred to as a \Web of trust" and is typical for PGP's decentralized way of managing trust. PGP signatures and encryption methods [29] are widely used for electronic mail, but have currently no importance for other Internet services. Distributed Trust Model The distributed trust model (Figure 2, c) is based on decentralized CAs where the CA issuing a personal certi cate is the most trusted CA. These personal CAs operate in an independent manner, each one having its own requirements for the establishing identities and distributing a trusted copy of the CA's public key. In addition to these personal CAs there are as well higher level CAs (such as CA3 in Figure 2, c) purely for key management and cross certi cation purposes. If a personal CA's public key becomes compromised, the damage is restricted, only the personal certi cates of the compromised CA have to be re-issued. A distributed trust model might be chosen for example by two relatively autonomous units of an organization in order to make certi cates mutually acceptable. 5


Centralized Trust Model In contrary to the distributed trust model, the centralized trust

model uses one central CA (the root CA) as the most trusted authority of the whole domain. The public key of the root CA is not signed by another CA and is the most trusted public key of the domain. Consequently, every user must be in possession of a trusted copy of the certi cate of the root CA. A valid certi cation path can only be set up, if a trust relationship exists between the root CA and all of the parties (CAs and users). If the certi cate of the root CA is compromised, all the users are aected in the recovery process. The centralized trust model implies the existence of a very powerful root CA which makes this model suited for closed hierarchically structured organizations. It is important to note that the relationships described in these trust models are concerned exclusively with the identity of a person. In developing the X.509 standard [3], the intention was to provide a global authentication framework | to bind a person's public key to his name. Today, these certi cates are more and more being used as a basis for access control decisions in an Internet-based distributed computing environment. Consequently, new certi cate techniques are being developed which we will brie y introduce in the following section.

3.3 Recent Developments Looking at current eorts to extend the functionality of the X.509 identity certi cate standard, two dierent approaches can be distinguished. In its latest version (version 3) the X.509 standard allows the integration of user de ned data, so called extensions, into the certi cate. This extends the original idea of certifying a user's identity towards a more exible concept, which facilitates the binding of arbitrary attributes to a user's public key. This approach is for example pursued by the recently published standards for credit card based electronic transactions SET [11], which uses X.509v3 extensions in order to associate data such as a credit card number or a merchant identi er with a public key. Note that in this case, the purpose of the X.509 certi cate is not only to identify the user, but also to authorize him to perform certain transactions. There are currently at least two dierent concepts under development (namely SPKI [4] and SDSI [19]), which de ne a new PKI from scratch. Both of them regard the domain of access control as a central issue. Both of them reject the further use of the X.509 standards and propose new certi cate encoding schemes and key acquisition mechanisms. SDSI (Simple Distributed Security Infrastructure) incorporates several new ideas, which were derived from the shortcomings of existing global PKIs. It encourages a loose, PGP-style trust model where everybody is capable to act as a CA as well as a strictly hierarchical one, which can be used to establish global root certi cates. The three certi cate types de ned by SDSI are identity certi cates, name/value certi cates, which allow the issuer to bind a name to a speci c value and group certi cates. The latter can be used to certify group membership as well as role assignments. SPKI (Simple Public Key Infrastructure) has similar goals as SDSI but is even more focused on the topic of access control. The central issue of the SPKI concept is the idea that the certi cate is used as a means of delegating authority to perform a certain operation | such as accessing a le or spending a certain amount of money. It can be seen that certi cate technology is evolving towards a more exible mechanism using certi cates which have meanings only in a local context. Looking back at the core services identi ed in section 2, we can summarize that an authentication service will currently perform its task on the basis of X.509 certi cates and a well de ned trust model, possibly using an existing global public-key infrastructure. But we have also shown in this section 6


that certi cates provide a more general means of managing access control and provide also mechanisms suitable for realizing the domain management component or the authorization service.

4 Secondary Services of the Security Architecture After having covered the authentication service in depth, we will in this section nish our description of the components which can be used to implement the core services presented in Section 2 (Figure 1) and present our implementation framework for this architecture.

4.1 Realizing the Secondary Services The Communication Service A secure communication service based on the Internet

Protocols ideally ful lls the following requirement (see [16] and [9]): 1. Provide the necessary record de nitions for transporting the (encrypted or unencrypted) data as well as the message authentication check and information on the algorithms used. These de nitions should be independent from the actual cryptographic algorithm or the key lengths in use. 2. De ne a key acquisition protocol, which can be used for exchanging public keys (currently in most cases as X.509 certi cates). 3. Make these protocol de nitions accessible with a number of cryptographic algorithms providing a well de ned API or integrated transparently in the TCP/IP protocol stack. The communication service can be realized at dierent layers of the TCP/IP protocol stack, but currently the only practical alternatives are either to realize it on the application layer (an example for this approach being the secure HTTP extension S-HTTP) or on the transport layer (for example SSL [5] and PCT [2]). A detailed description of the advantages and disadvantages of these approaches can be found in [16]. As we will show in the next section, in our prototyping environment we will be using the SSL-Protocol [5] as a communication service, which ful lls all the requirements mentioned above and is available as a freely available library implementation [28].

The Directory Service While the global directory infrastructure envisioned by the X.500

standards never was realized, there seems to be a trend towards the use of the Lightweight Directory Access Protocol (LDAP) [26] which is currently available in version 2. A directory service basically behaves like a database, with the main dierence that the data stored is much more likely to be read than to be updated. Hence, directory servers typically do not provide the transaction and recovery mechanisms which are part of a commercial database management systems, but are optimized for high volume read access and for this reason usually support some sort of replication. LDAP can be used to store and distribute public keys, string attributes associated with a person as well as base64 encoded binary data, such as for example JPEG images. Since LDAP is based on the same global naming conventions as X.509 certi cates it is straightforward to combine these two. There is a free version available, which includes the LDAP-server as well as the easy-to-use client library [8].

7


Domain Management and Authorization Service There is much work to be done in providing a uniform, central repository of group-membership, role assignment and access control information in an Internet-based distributed computing environment. This information is typically provided on a per-service-basis (such as the group- les used by many W3 servers) or as part of the underlying operating system (for example the Unix group le). The absence of a central repository makes it dicult to keep access control entries and group or role assignments, in a consistent state. Recent product announcements indicate the use of LDAP-servers for this purpose (for example [12] or [25]). Current research activities (both commercial and academic) { as described in Section 3 { concentrate on the use of certi cates for asserting group membership, role assignments or access privileges.

4.2 The Security Infrastructure As a summary, Figure 3 shows our framework to realize the core services identi ed in Section 2. The authentication service is provided by a local CA, which issues identity certi cates and certi es other CAs in accordance with the trust model used. The directory service makes the certi cates available to the public. User

Server

HTTP/GET Document

Peer-to-Peer

User

Resource

Certificate Management

Directory

Reference Monitor

Figure 3: Security Infrastructure Domain management and access control is either realized as part of the certi cate management or independently by using a reference monitor. The latter is in charge of accepting or refusing the requests of authenticated users for speci c services using the central repository of group and role assignments. Alternatively, this information can be integrated in the certi cates. In this scenario, the CA is responsible for the domain management and certi es group memberships, role-assignments or access privileges. In this case, the reference monitor is obsolete, since the veri cation of the presented certi cates is sucient for granting or refusing the access. Within this framework, many dierent implementations can be realized. In the next section, we will demonstrate how the Wafe environment can be used to construct and test dierent security infrastructures in accordance with the framework presented in Figure 3. 8


5 Designing and Prototyping a Security Infrastructure As indicated above we concentrate in this paper on the browser side rather than on the server side of W3 applications. A browser supporting a W3 security infrastructure consists of the following components: 1. User interface (including HTML rendering and image support) 2. General networking functionality 3. Event handling mechanism 4. Cryptographic support 5. Access to directory services 6. Glue code (managing the interaction between the above items) We have implemented a W3 browser called \Cineast " which is a freely available, extensible browser intending to provide an environment for prototyping new client side Internet technologies. The browser is implemented in the Wafe [14] environment which provides the basic infrastructure. The user interface is implemented using OSF/Motif and a self developed widget for HTML parsing and rendering. The general networking functionality is taken from the reference library of the W3 Consortium [6] (called libwww), the basic event handling mechanism is from the X Toolkit (Xt) [15] from the MIT, we use the cryptographic support from SSLeay [28] and the directory services from LDAP [26, 8] and mix nally all components together using the object oriented Tcl variant OTcl [24]. Motif based Widgets XmGraph, XbaeMatrix, XmTree, Xew Widgets OSF/Motif Widgets V 1.0, 1.2 or 2.0

MIT Athena Widgets R4, R5, R6 Xaw3d

Extra Widgets Plotter, Layout, Clock, HTML, Ghostview, Kino

Xlib, X Toolkit and Extensions Basic Widgetclasses, Xpm, Dnd, Offix

TCL Extensions OTCL, iTCL, MSQL-TCL

C based Extensions LDAP, Libwww, SSLeay

Tool Command Language (TCL)

Figure 4: Components of Wafe (version 1.0.17) Wafe is a public available rapid prototyping environment built upon the Tcl language [17] and was originally created for GUI-based applications in the X Window environment. Wafe is in some respects similar to the Tcl/Tk package [18] but does, instead of providing it's own look and feel, integrate a broad variety of dierent GUI components primarily based on MIT's generic X Toolkit. Furthermore, Wafe provides a C code generator which eases the integration of new packages. In the Wafe system we follow the principle that all basic functionality is implemented completely in C, whereas Tcl (or OTcl) functions merely as a glue language for controlling and con guring these components (as originally proposed by Ousterhout in [17]). In this concept the purpose of Tcl is comparable to that of a 4th generation language. Table 1 gives an overview of the amount of code written in C and OTcl using the { inaccurate { number of lines of code. These gures do not include the X Toolkit, OSF/Motif, or other more basic libraries. We can see from these gures that the amount of code to create and control the browser (the piece of code that makes the actual dierence between a W3 browser and any other 9


Component Language Lines of Code Cineast OTcl 2400 Hand-coded part of Wafe C 23200 Generated code in Wafe C 42000 Library code SSLeay C 73300 Library code LDAP C 28500 Library code libwww C 60700 Library code HTML widget (Kino) C 15000 Library code Tcl C 58520 Library code OTcl (uses Tcl) C 2500 Other optional supported library code such as additional C 208000 widgets, drag and drop, graphic formats, etc.

Table 1: Source Code Size of the Components of the Wafe Environment program implemented by Wafe such as a CPU monitor or a front end for the program tar) is about one hundredth of the involved code size counting only the core components.

5.1 Basic Components and Conventions In order to give the reader a rough impression how the Cineast browser is implemented we give here an introduction which is a short as possible. All the top level commands issued in Wafe are in Tcl syntax. The most important functions of the used components (libraries) are accessible from within Wafe after a simple name mapping, where typically a standardized pre x is added to avoid name clashes. For example the C function \HtLoadAnchor(HTAnchor *a, HTRequest *r)" of the W3C reference library (libwww) is available in Wafe in the form of \w3LoadAnchor $anchor $req". In this example \w3" is the pre x for the libwww library.

5.2 GUI Components In order to create a graphical user interface in the Xt context one has to create instances of widget classes which are con gured through attributes. Using the following Wafe commands a small application is created that displays a HTML le and oers a push button for termination. XmRowColumn rc topLevel HtmlKino h rc -text [getFile menu.html] XmPushButton b rc -activateCallback quit realize

The rst line creates a widget of the class \XmRowColumn" named \rc" which functions for the placement of the later created widgets. \Xm" is here the pre x for the OSF/Motif name space. In the second line an instance of the HTML widget is created as child of \rc", which receives in its text resource the content of the speci ed HTML document. The third line creates the push button \b" as well as child of \rc". When the button is pressed, the command speci ed in the \activateCallback" attribute is executed and the program terminates. The last line tells the X Toolkit that the speci cation of the widget tree is complete and that it should be displayed to the user (in Xt terms \realized").

10


5.3 Networking Facilities The W3C reference library (libwww) [6] is a general-purpose Web API written in C. We use libwww (version 5.0a) for the Cineast browser as primary means to support networking protocols such as HTTP/1.1, FTP and NNTP as well as for client tasks such as caching, logging, or proxy-handling etc. Libwww supports non-blocking I/O as well, which is essential for a browser for two reasons: 1. Blocking read operations would prohibit multiple simultaneous transfers in a single process. 2. Since Wafe is tightly coupled with the X Toolkit's event loop, preemptive loading of large amounts of data over slow network connections would render any GUI components useless in the meantime. Libwww is furthermore available as a source code distribution, which makes literally all aspects of the implementation con gurable. Most of the changes we proposed during the implementation of Wafe's libwww module were integrated by the W3C. As the W3C itself states: \The purpose of libwww is to provide an environment for experimenting with extensions and new features - most notably for HTTP but also for many other parts of the Web" [7]. The following Wafe command loads a document from the speci ed URL and displays it with the \xedit" editor available on many Unix systems. set anchor [w3GetAnchor http://nestroy.wi-inf.uni-essen.de/] set request [w3RequestNew wwwPresent {Presenter {xedit %s}}] w3LoadAnchor $anchor $request

The command \w3GetAnchor" is used to create an empty anchor structure and to bind it to the speci ed URL. An anchor is the basic handle to a HTML document. The command \w3RequestNew" is used to create a new request object. This command accepts several attribute/value pairs in order to con gure the request. We only specify a \Presenter" which is a program to display the transfered data when it is completed. Later examples will discuss more of these attributes. \w3RequestNew" returns a request handle. Finally, the command \w3LoadAnchor" accepts these two handles and starts the transfer. In this example we implicitly performed an incremental download with asynchronous transfers though we did not notice this fact, since the \Presenter" speci ed can not incrementally display the incoming data. Let us consider the following example, which illustrates the use of asynchronous transfer more clearly. w3AddConverter image/gif \ {FileWriter {puts "%r: [w3RequestGet %r bytesRead] Bytes to %d"}} set request [w3RequestNew postCb {puts Done}] w3LoadAnchor [w3GetAnchor http://wwwi.wu-wien.ac.at/buchcover.gif] $request

This script transfers a large GIF le and prints the request handle, the number of bytes read and the name of the temporary le used every time a new chunk of data arrives. Furthermore it uses the \Format Manager" of libwww in order to nd a presenter for the incoming object. The \w3AddConverter" command is used to register a converter for a speci ed content-type with the format manager. The converter \FileWriter" incrementally dumps a data object to disk and invokes a handler procedure every time a new chunk has been added to the le. \FileWriter" takes one additional parameter which speci es the \incCB" handler procedure. From within the handler procedure, we use the \w3RequestGet" command in order to access the \bytesRead" member of the request structure. Note the use of Wafe's percent-code substitution mechanism in the speci cation of the handler: \%r" allows us to retrieve the request handle and \%d" is replaced by the name of the temporary le. An anchor and a request object are created and the request is started. A termination handler is registered for the request, which will simply print the word \Done" when the transfer is nished. 11


Create: Input: Output: Sign: Verify:

RSA w3RSA new w3RSA decode w3RSA pem w3RSA text

X509 Request w3X509 REQ new w3X509 REQ decode w3X509 REQ pem w3X509 REQ text w3X509 REQ sign

X509 Certi cate w3X509 decode w3X509 pem w3X509 text

w3X509 certVerify w3X509 verify GetAttr: w3X509 REQ getPubkey w3X509 get Special: w3RSA spkac w3X509 loadVerifyLocations Certi cate Context Create: w3CertCtx new Free: w3CertCtx free Get: w3CertCtx getCert Special: w3CertCtx addCertFile Others: w3Text sign, w3Text verify

Table 2: SSLeay-Functions currently supported by the Wafe environment

5.4 Security Support In the Cineast browser we use SSLeay (version 0.6.6) [28] for cryptographic support. SSLeay is a free implementation of SSL (currently SSL version 2) supporting DES, RSA, RC4 and IDEA as encryption algorithms and MD2, MD5, SHA and SHA1 for message integrity calculations (hash codes). SSLeay supports X.509v3 certi cates and PKCS#10 certi cate requests. SSleay provides both a library and a command line interface for many operations. In order to implement SSL over libwww we wrote a small C module which implements libwwww's state machine for SSL using the SSLeay library. Wafe registers HTTP over SSL as a new protocol named \https" via the protocol manager of libwww. The following script uses additional request attributes in order to con gure a SSL connection on a per request basis. The attributes \sslPrivateKey" and \sslCertFile" specify the user's credentials for the SSL handshake. If asked for, client authentication can now be performed. Since the attribute \sslVerify" is set to \peer", a connection can only be established if the peer's certi cate is signed by a known certi cate authority. set W3SSL $env(HOME)/.cineast/ssl set request [w3RequestNew \ wwwPresent {Presenter {xedit %s}} \ sslPrivateKey $W3SSL/priv/seen.pem \ sslCertFile $W3SSL/priv/seen.pem \ sslVerify peer] w3LoadAnchor [w3GetAnchor https://www.eunet.co.at/] $request

For a browser supporting the security architecture it is not sucient to solely connect via SSL to HTTP server, it has to provide facilities for certi cate acquisition, signing and verifying various types of documents and to provide means for certi cate management. At the time of this writing Wafe supports the library functions of SSLeay summarized in Table 2. The \create" operations create objects of the respective column, the \load" functions read les in the PEM format and decrypt it if necessary (using a provided key). The \output" functions transform the internal objects either into a PEM encoded representation (optionally encrypted) or they produce a human readable text. Furthermore there are operations to extract certain attributes from a object and to perform certi cate management. The follwing sections discuss certi cate acquisition, certi cate checking and certi cate management in the W3 context. 12


Certi cate Acquisition In order to obtain a certi cate we follow in our environment the Public-Key Cryptography Standard number 10 (PKCS#10) as de ned by RSA Laboratories [20]. The certi cate request contains the distinguished name (DN), a public key and optionally a set of attribuites provided by the requestor. The requestor signs the request with his private key. In the W3 context the primary means to prompt a user for data are HTML forms. Therefore we use a form to collect the organizsational and personal data to construct the DN from the user. When the request is created a new key pair has to be generated. The user can provide the key size through the form (Figure 5).

Figure 5: HTML Form to Request a Personal Certi cate In a standard HTML form, all collected input elds are transmitted to the server where a CGI script is started. When a certi cate request is to be generated this is not practical since the private key produced as a side product of the certi cate request generation must not leave the user's environment. The Cineast browser has a small extension for HTML forms called a \ lter" which can post-process and transform the input elds before they are transmitted to the server. We use a lter called PKCS#10 to generate the certi cate request and the private key and transmit the request to a CGI script on the server side, where it is placed into a request repository (see Figure 6). When the CA issues the certi cate it retrieves the request from the repository, processes it, places the generated X.509 certi cate into the 13


W3 Browser

HTTP Server 5

1

Certificate Repository

FormFields Fields Form postprocessing

2

Request Repository 4

X.509Request Request X.509

3

CA

cgi-script

6

URL-encoded X.509 Request in PKCS#10 Notification Containing URL pointing to X.509 certificate in PEM or DER format

Figure 6: Process of Certi cate Acquisition certi cate repository and sends an URL pointing to the certi cate to the requestor1. When the certi cate is transmitted the MIME content type is set to application/x-x509-user-cert. There is no encryption necessary since the certi cates contain only public data. The format handler of the browser allows to register a special handler for this content type, which will save the obtained certi cate into the user's personal certi cate repository. When a W3 server requires client authentication during the SSL handshaking phase the browser can present a list of personal certi cates to the user who can choose the appropriate one. Below is the part of the browser that processes the entry elds of the form (stored in the associative array form) in the lter method. First a new key pair and a new X.509 request are generated using input elds of the form. The request is signed and the key mananager object of Cineast is called with methods to save the request and the private key. set rsa [w3RSA_new $form(keySize)] set x509req [w3X509_REQ_new $rsa \ countryName $form(C) \ stateOrProvinceName $form(SP) \ localityName $form(L) \ organizationName $form(O) \ organizationalUnitName $form(OU) \ commonName $form(CN) \ emailAddress $form(Email) \ challengePassword "" \ unstructuredName "" ] w3X509_REQ_sign $x509req $rsa set pemReq [w3X509_REQ_pem $x509req] keyMgr saveX509req $pemReq keyMgr savePK $rsa

Note that our approach for generating keys diers from Netscape's Navigator and Communicator [13], where a special HTML form tag named KEYGEN is introduced. This tag is \magically" displayed in the form as an option menu for choosing the keysize. When the form is submitted this tag causes the generation of the key pair and the so-called SPKAC (signed public key and challenge, DER and base64 encoded) eld is transmitted together with the DN information to the server. The SPKAC format was introduced by Netscape. Our apporach has the following advantages: 1. Cineast does not introduce any new formats (such as SPKAC). 1

Alternatively the CA can send the certi cate to the user via email.

14


2. Cineast does do not introduce any \magical" elds into the HTML form that introduce new input types. 3. The implementation of the Navigator de nes the entries of the option menu. It is not clear how these automatically generated entries can be provided in dierent languages. 4. Cineast does not require any input method (such as an option menu or a text eld), the order of the entries is arbitrary. 5. Cineast keeps the certi cates in a readable directory, the certi cates can be used for other applications as well. The Navigator uses non-documented format. However, Cineast requires (like Navigator) certain names for the input elds and it makes use of the lter method (which is a fairly general mechanism not constraint to a single application).

Certi cate Checking In addition to the personal certi cates the browsers maintains a

repository of CA certi cates. CA certi cates can be added similar to user certi cates by using the content-type application/x-x509-ca-cert. These CA certi cates are used to verify other parties certi cates. To introduce a higher degree of exibility SSLeay allows to create multiple certi cate contexts, with possibly non-disjoint sets of trusted CA certi cates. A certi cate context speci es which CAs are trusted in a particular situation. Examples for such context speci c trust management might be in interactions with a bank, a cooperation project with other company, some con dential research projects or private communications.

Figure 7: Certi cate Management in the Cineast Browser Figure 7 displays the screen pf the certi cate management window of the Cineast browser. The left side of the window contains a menu of the subtasks such as management of personal and server certi cates and certi cation contexts. When the latter item is selected, the right part of the window gives a selection of de ned certi cation contexts (not shown) where a particular one can be selected and edited. The right part of the window in Figure 7 allows to 15


edit the certi cation context named \INTERN ", where CAs can be added or removed from the list of trusted CAs. The example code below shows the technical realization of the basic tasks in the Wafe environment. A new certi cate context is created, a CA is added into this context and a test certi cate is veri ed in this context. set cert [loadFile ~/wafe/src/cineast/test.cert] set ctx [w3CertCtx_new] w3CertCtx_addCertFile $ctx ~/.cineast/ssl/certs/vsign1.pem pem if [string match 0 [w3X509_cert_verify [w3X509_decode $cert ""] $ctx]] { puts "verification of certificate in context $ctx was OK" } else { puts "Verification of Certificate in Context $ctx FAILED" }

At the time of this writing all the basic mechanisms to support the certi cate contexts are implemented in the Wafe environment. For example, every new \https" request can be con gured with a certi cate context by using a request attribute. What's currently missing from the graphical user interface is some easy and intuitive way to specify the context to be used. We are planning to allow the user to set the certi cate context per (named) browser instance.

6 Conclusion and Summary In this paper we tried to de ne a framework to identity the core services needed for developing a scalable Intranet architecture. We concentrated from the architectural point of view on the authentication service that plays in this architecture the central role. The technologies for communication and directory services are today available and well understood, domain management and authorization services are in our application context still in their early days. We tried to emphasize that a prototyping environment is needed and presented our approach using Wafe where only very little code was needed to implement the Cineast browser. We demonstrated that in some respects our browser compares favorably with Netscape Inc.'s Navigator and Communicator. We believe that our environment is a productive platform for extending security management, to experiment or to develop new security components and to build novel Web applications.

References [1] American National Standards Institute. Accredited Standards Committee X9 Working Draft: American National Standard X9.57 Certi cate Management, American Bankers Association 1995. [2] J. Benloh, B. Lampson, D. Simon, T. Spies, B. Yee, The Private Communication Technology Protocol, Internet Draft (Work in progress), September 1995. [3] CCITT Recommendation X.509, The Directory{Authentication Framework. Blue Book | Melbourne 1988, Fascicle VIII.8: Data Communication networks: Directory, International Telecommunications Union, Geneva, Switzerland 1989. [4] C. Ellison, B. Frantz, B. Thomas, Simple Public-Key Certi cate, Internet Draft (Work in progress), July 1996. [5] A. Freier, P. Karlton, P. Kocher, The SSL Protocol Version 3.0, Internet Draft (Work in progress), March 1996. 16


[6] H. Frystyk-Nielsen, Libwww - the W3C Reference Library, http://www.w3.org/pub/WWW/Library, W3 Consortium, October 1996. [7] H. Frystyk-Nielsen, W3C Reference Library Position Statement, http://www.w3.org/pub/WWW/Library/Activity.html, W3 Consortium, October 1996. [8] T. Howes, M. Smith, The LDAP Application Program Interface, RFC 1823, August 1995. [9] P. Lipp, V. Hassler, Security Concepts for the WWW, in: P. Horster (ed), Communications and Multimedia Security II, Chapmann and Hall, London 1996. [10] J. Maley, Enterprise Security Infrastructure, in: Proceedings of the Fifth Workshops on Enabling Technologies: Infrastructure for Collaborating Enterprises, Stanford, California, June 1996. [11] Mastercard, SET: Secure Electronic Transactions, http://www.mastercard.com/set/, Draft 8/7/96, August 1996. [12] Netscape Inc., The Netscape Directory Server, product description http://www.netscape.com/comprod/server central/product/directory/, February 1997. [13] Netscape Inc., Netscape Certi cate Speci cations, http://home.netscape.com/eng/security/certs.html, Draft by Je Weinstein, June 1996. [14] G. Neumann, S. Nusser, Wafe { An X Toolkit Based Frontend for Application Programs in Various Programming Languages, USENIX Winter 1993 Technical Conference, San Diego, California, January 1993. [15] A. Nye, T. O'Reilly, X Toolkit Intrinsics Programming Manual, O'Reilly and Associates Inc., USA 1990. [16] R. Oppliger, Internet Security: Firewalls and Beyond, to be published in CACM 1997 [17] John K. Ousterhout, Tcl: An embeddable Command Language, Proceedings USENIX Winter Conference, January 1990. [18] John K. Ousterhout, An X11 Toolkit Based on the Tcl Language, Proceedings USENIX Winter Conference, January 1991. [19] R. Rivest, B. Lampson, SDSI | A Simple Distributed Security Infrastructure, in Proceedings of DIMACS Workshop on Trust Management in Networks, South Plain eld, NJ, USA, 1996. [20] RSA Laboratories, PKCS#10: Certi cation Request Syntax Standard, Version 1.0, November 1993. [21] R. Sandhu, E. Coyne, H. Feinstein, C. Youman, Role based access control models, in: IEEE Computer, February 1996. [22] B. Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, New York 1994. [23] W. Stallings, Network and Internetwork Security, Prentice Hall, Englewood Clis 1995. [24] David Wetherall and Christopher J. Lindblad, Extending Tcl for Dynamic ObjectOriented Programming, Proceedings of the Tcl/Tk Workshop '95, Toronto, July 1995. [25] Xcert Software Inc., The Xcert Software Sentry CA, product description http://www.xcert.com/software/sentry/ca/, February 1997. [26] W. Yeong, T.Howes, S.Kille, Lightweight Directory Access Protocol, RFC 1777, March 1995. [27] N. Yialelis, E. Lupu, M. Sloman, Role Based Security for Distributed Object Systems, in: Proceedings of the Fifth Workshops on Enabling Technologies: Infrastructure for Collaborating Enterprises, Stanford, California, June 1996. 17


[28] E. Young, T. Hudson, SSLeay and SSLapps FAQ, http://www.psy.oz.au:/~ftp/Crypto/, February 1997. [29] P. Zimmermann, The Ocial PGP User's Guide, MIT Press, Cambridge, Massachusetts 1995.

18
