pesos acero

The PAPI system: Point of Access to Providers of Information Rodrigo Castro-Rojo Diego R. López RedIRIS - Spanish National Research and Educational Network Serrano 142, E-28006 Madrid, Spain Phone: +34 915855145 Abstract: The goal of this system is to solve the problems that users often suffer when trying to access an information provider outside their networks, since in many cases access control is performed by IP-address filters. The solution we present here is based on public and symmetric key encryption and allows users to seamlessly access, during a limited period of time fixed by the authentication system, information provider web servers through points of access that evaluate the trust of the user requests. This paper describes the design of the system and presents an implementation of the system that is currently working at RedIRIS. Keywords: authentication, information provider, cryptography, key, temporary key, session key, user mobility

1. Introduction In the last years some new technologies and devices have appeared in IP networks that make very difficult for a server to detect what is the real IP address for the source of a request. One of these are transparent proxies, that intercept TCP connections to some specific ports and make the request by themselves to the intended server, masquerading the IP address of the original requester of the TCP connection [1]. The use of web proxy/cache [5] servers has become very common at the institutes and universities of our network. As a consequence, problems when accessing information provider web servers from our affiliated institutions have become more and more frequent in the last years, as more contracts for Internet access to information resources have been established between these institutions and content publishing companies [4,2]. Some months ago, RedIRIS organized a meeting with representatives of different organizations at both sides of these connectivity problems. The outcome of this meeting was a list of requirements for a solution and the commitment of RedIRIS to work on a system that fulfills the agreed requirements. This was the starting point of the PAPI (Point of Access to Providers of Information) system, a project in which several affiliated institutions and information publishers agreed to collaborate. In the next sections the requirements for the system are presented, the design of the system is described, and the current status of its implementation is presented as well.

2. System Requirements System requirements were compiled by RedIRIS from the requests of the different actors: clients (our affiliated institutions) and providers (information publishers). The following list is a compilation of the (somehow conflicting [3]) needs of both sides: 1. The system should not allow access to any service to non-authorized users. 2. The access control should be independent from the IP origin address of requests. 3. Authentication and access control should be independent enough so as to be managed by different organizations. 4. Every user should be authenticated to an authentication server operated by the organization he/she belongs to. Each organization will manage its own server. After the authentication has been correctly performed, the user should be able to access, during a configurable limited period of time, all the services that he/she is authorized to. 5. The authentication mechanisms used by the authentication server should be as flexible as possible, allowing each organization to use its own authentication schema. 6. Information providers should be able to define access control rules based on public attributes of the request (organization that user belongs to, department, etc). 7. The system should allow user mobility. 8. The mechanisms for access control should be as transparent as is possible to the user. 9. The access control implemented by this system should be fully compatible with other access control systems used by information providers. 10. The user should be able to access information providers servers using the most commonly employed Web browsers, i.e., Netscape/MSIE/Lynx, and any operating system. 11. When a user accesses a service using this system, his/her identity should never be deduced from the information provided for granting the access. On the other hand, this information should allow to distinguish accesses from different users. This means that privacy in the access has to be guaranteed at the user level. Each user should be identified with a code distinguishing him/her among other different user accesses. Only the organization that the user belongs to should be able to get personal information from this code. This code will allow information providers to build access statistics at the user level, but should not allow them to track specific user behaviors.

3. The PAPI Architecture Access to the servers of information providers is seldom granted to individual users. The common practice is granting access to a certain number of users in an organization, or more often to all users that belong to an organization. Organizations use to have internal databases, and internal authentication systems based on personal information that cannot be disclosed. For example, it is

very common to only grant access to some services to people belonging to certain departments or with a concrete organizational rank. On the other hand, information providers need to keep the control of who accesses their web servers, including the appropriate filters to enforce contracts with their clients. It is also a common practice gathering information at this filters in order to get statistics about information usage.

These considerations lead us to divide the system in two independent elements: the authentication server (AS) and the point of access (PoA). This structure, shown in Figure 1, makes the final system much more flexible and able to be integrated to different environments.There is no need of a one-to-one mapping between ASs and PoAs: a given PoA may manage to deal with requests from any number of ASs and direct them to any number of web servers.

3.1 The Authentication Server The purpose of the AS is provide users with a single authentication point and provide them (in a completely transparent manner) all the temporary keys that will let them to access the services they are authorized to. The structure of the server is shown in Figure 2. It is composed of the following three modules: The authentication module implements an authentication mechanism that can be configured by the organization that manages it. Each organization can use its own authentication module. Some examples that have been discussed with institutions collaborating in the project include LDAP authentication, POP-based authentication, and X.509 certificates. The site database module generates, from information about the user and some filter rules managed by the organization, a list of authorized sites the user can access and during how much time is authorized to. The authentication server interface gets the authentication requests from the web browser

of the user and passes the request to the authentication module. If the user is correctly authenticated, the locations and periods of time this user has authorization to are extracted from the site database. Every element of this list is encrypted using a private key that represents the AS inside the whole PAPI structure, and sent to the web browser as a list of URLs to connect to, included into an HTML page with the results of the authentication. In the case that the authentication procedure fails, an error message is sent.

A example of authentication can be seen in Figure 3. In this method a "userid" and "password" must be given, but the system is designed to be adapted to any other authentication method that a organization is currently using.

Figure 3: Example of authentication screen

Once a user is successful authenticated a list of authorized locations is presented in his browser as is shown in Figure 4.

Figure 4: Example of web page received by the user with the list of authorized locations

3.2. The Point of Access This element manages actual access control to a set of web locations for a given organization. The information provider (or the owner of the web servers) have the responsibility of managing this point of access. A point of access can be adapted to any web server, whatever its implementation is. Moreover, a given web server can have more than one point of access, and a point of access can control more than one web server. Other important property of this system is that is completely compatible with any other access control system in use, since it does not impose any constraints on additional procedures used for these purposes. In other words, PAPI access control is completely

orthogonal to procedures such as password protection, IP filters, TLS-based access control, etc. An PoA has the structure shown in Figure 5 and is composed of two kind of elements: A key generation module for the authentication phase that will generate and send temporary keys for accessing the services controlled by this PoA, using the tokens for temporary keys produced by an authentication server and any applicable local filter rules. Some access control modules. Every time a request is received by one of these modules, it checks the specific temporary keys that are sent for that location by the user’s web browser. If everything is correct, the module performs the request and its results are sent back to the user. The details about how the temporary keys are checked, and the procedures for validating and re-validating them (if needed) will be discussed in the next section.

4. The PAPI Protocol The protocol that PAPI employs is divided into two phases: authentication and access control. The authentication phase starts every time a user accesses the authentication server to get fresh temporary keys. During the timeframe these keys are valid, this user does not need to return to this phase. Only in certain specific cases the user has to start the authentication phase before the expiration of her/his keys: 1. When the temporary keys are forgotten by the web browser (in the current implementation, when the cookies are deleted or the cookies file is deleted).

2. When the temporary keys become corrupted. 3. When the temporary keys are copied to another browser and are employed by another user at the same time. 4. When the main encryption key (the K1 key described below) of the point of access is changed because it has been compromised.

4.1. Authentication Phase At this stage the user is authenticated and a set of temporary keys (two per each location the user is authorized to access) are stored in the user web browser. This phase is composed of the following steps: 1. The user accesses the authentication server with a web browser. The authentication method will depend, as described above, on the organization policies. 2. If the authentication succeeds, and depending on the policy the organization applies for granting access (taking into account, for example, the type of user, her/his rank, the number of accesses the organization may offer, the type of services requested, etc.), a list of URLs corresponding to the points of access for the required services are sent to the web browser of the user. The format of each URL is: The location that generates the temporary keys for this location. The name of the authentication server this user belongs to. A list of parameters that are encrypted with the private key of the authentication server: The code identifying this user. The expiration time for the main temporary key that is going to be generated. A timestamp for the URL, so the same request cannot be used again in the future. 3. The web browser, after receiving the list of URLs, contacts (in a completely transparent way to the user) the points of access in the list. Each of them, using the public key of the authentication server, checks the integrity and the timestamp of the request. Any applicable filter rules (organization, department, etc) may be checked as well. If everything is correct, two temporary keys are generated: the main temporary key Hcook and the secondary temporary key Lcook. The main temporary key, together with a random block, is registered into a temporary key database at the point of access. Both temporary keys are sent to the web browser of the user, coded as cookies. The formats of the elements used in this authentication phase are: Hcook is the primary, heavyweight temporary key. It contains several access control information (shown in Figure 6), encrypted with a symmetric key (K1) that is privative to the PoA. The access control fields are: The user code. The location this key gives access to. The expiration time. A random block. The temporary key database registers all the valid primary temporary keys. This database is used for avoiding illegal accesses by cookie copying, since when checking Hcook, the PoA

needs to compare the random block of this Hcook with the last one generated for it. The attributes it stores for each primary temporary key are: The user code. The location this key gives access to. The expiration time. The current random block for this key. A timestamp for the register (or the last modification). Lcook is the secondary, lightweight temporary key. It is used at the access control phase to perform lightweight checks and it also consists of a set of access control data (also shown in Figure 4), encrypted with another symmetric key (K2), that it is also privative to the PoA but shorter than K1. The fields it contains are: The location this key gives access to. The creation time.

4.2. Access Control Phase At this phase the point of access verifies the temporary keys associated with the requested location. The use of two temporary keys (cookies) is justified because Lcook (the secondary key) is valid during a very short period of time and requires a very lightweight verification, in order to reduce the cryptographic calculation overhead at the point of access, thus increasing the whole system performance. Since Lcook has a very short period of validity, when it expires a heavyweight verification is performed: Hcook must be decrypted, new temporary keys are generated and stored into the temporary key database, and sent to the user’s web browser, etc. The steps in this phase are: 1. Every time the user tries to access a controlled location, the web browser sends the temporary keys along with the request, without any user intervention. This is possible because the temporary keys are implemented as cookies. 2. The point of access verifies the Lcook key (lightweight verification): It decrypts the cookie (using K2) It checks if the location and timestamp in the cookie are correct. If they are, the request is processed. If the location is wrong, the request is rejected. 3. If Lcook has expired, Hcook has to be checked (heavyweight verification): Hcook is decrypted (with K1) If it has expired, the request is rejected. If the location in the cookie is not valid, the request is rejected. If the random block in Hcook is different from the random block field registered into the

temporary key database, it means that a new cookie Hcook was generated for this user, so two users are trying to use the same Hcook. This is a case of copy of temporary keys, so the request if rejected. 4. If Hcook is correct, a new Hcook (with a new random block) will be generated and registered in the temporary key database. Then, a new Lcook is generated and the two new cookies are sent to the web browser, along with the results of the request. If new requests are received with the old Hcook value, its random block will not be correct, so the PoA assumes that a copy of cookies has been detected.

5. Conclusions and Future Work This paper has presented a system that intends to harmonize the needs of both consumers and producers of information, when access to this information is provided in a contractual framework. The architecture and protocols the system is based upon overcome the limitations that current access control practices impose on the use of network bandwidth optimization technologies, while guaranteeing the independence of the actors and preserving user privacy. Furthermore, all the procedures are kept transparent to the user, so they do not require additional training and can be seamlessly deployed in any organization. At the time of this writing, a demonstrator of the system described in this paper has been established for evaluation by the collaborating organizations. At least one of these organizations has already began to install one AS and one PoA to give ubiquitous access to library registers to its users. The authentication system of the demonstrator has been written in Perl, using Apache mod_perl [6] and specific Perl bindings to the low-level functions of openSSL. The point of access implemented in the demonstrator is also based on Apache and openSSL, using a redirector module with access control elements that also use mod_perl [6]. Once the evaluation phase is completed, and requests received from collaborators are implemented, we will begin to work on refining the system, in order to provide a collection of authentication methods, and to make as simple as possible the installation and configuration of both ASs and PoAs. We also plan to port the AS and the PoA systems to servlets, so they can be built on top of different web server implementations.

6. References [1] P. Danzig, K. L. Swartz, Transparent, scalable, fail-safe Web caching, Network Appliance tecnical report, 1999. [2] I. Fuchs, Remote Authentication and Authorization for JSTOR, JSTORNEWS, no. 2, Issue 3, Fall 1998. [3] E. Giabarra, Licenses, contracts and intellectual property rights, Workshop on Electronic Resources, Spanish Society of Documentation and Scientific Information, Madrid, May 2000.

[4] C. Lynch, A White Paper on Authentication and Access Management Issues in Cross-organizational Use of Networked Information Resources, Coalition for Networked Information, http://www.cni.org/projects/authentication/authentication-wp.html [5] O. Pearson, Squid (A User’s Guide), http://squid-docs.sourceforge.net/latest/html/book1.htm [6] L. Stein, D. MacEachern, Writing Apache Modules with Perl and C, O’Reilly & Associates, April 1999.

7. Vitae Rodrigo Castro-Rojo is an application engineer at the Network Applications Area of RedIRIS, the Spanish NREN. He graduated in Computer Science at the Universidad Politécnica of Madrid in 2000. From 1997 to 1999 was member of the technical staff of PNTIC, acting as systems and communications manager. Diego R. López is the coordinator of the Network Applications Area of RedIRIS, the Spanish NREN. He graduated in Physics at the University of Granada in 1985 and joined the Conformance Testing Division of Telefonica I+D, working in several projects related to e-mail and directory services. From 1992 to 2000 was member of the technical staff of CICA, acting as the responsible for network services. In January 2000 he joined RedIRIS. His current work is focused on semantic Web interfaces and security-enhanced services.