• Abstract and Figures
• Public Full-text

University of Illinois at Chicago Strong Distributed Authentication Architecture for UNIX by Ashwin Ganti A PROJECT SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE MASTER OF SCIENCE in COMPUTER SCIENCE Approved, MASTERS PROJECT COMMITTEE Jon Solworth, Adviser Associate Professor of Computer Science V.N. Venkatakrishnan Assistant Professor of Computer Science Chicago, Illinois December, 2007 This project is dedicated to my family. Acknowledgments I would like to thank my adviser Jon Solworth for his invaluable guidance throughout the course of the research for this project and for having been most patient and supportive of me during the entire duration of my time in graduate school. Ashwin 2 Contents 1 Introduction 7 2 Overview of the Frameworks used 9 2.1 PAM........................................ 10 2.2 Name Service Module . 11 2.3 IPSec . 12 3 System Design 12 3.1 Statics . 12 3.1.1 Modules of the system . 12 3.1.2 Relation between the Modules . 13 3.1.3 SayAnything Certificates Used . 13 3.1.4 Relation between certificates . 15 3.2 Dynamics - Logical Flow . 17 4 System Internals 18 4.1 pam sayAnything . 18 4.2 nss sayAnything . 18 4.2.1 getpwuid (uid t uid) . 19 4.2.2 getpwnam (char* name) . 20 4.2.3 setpwent (void) . 20 4.2.4 getpwent (void) . 20 4.2.5 endpwent (void) . 21 4.3 sayAnything Agent . 21 4.3.1 Overview . 22 4.3.2 Logical Flow . 22 4.4 Certificate Server . 24 3 4.4.1 Add Certificate . 24 4.4.2 Get Certificate . 24 5 System Administration 25 5.1 pam sayAnything . 25 5.1.1 Overview . 25 5.1.2 Configuration . 26 5.2 nss sayAnything . 27 5.2.1 Overview . 27 5.2.2 Configuration . 30 5.3 IPSEC . 30 5.3.1 Components that need to be setup . 31 5.3.2 Steps to setup ipsec on two test machines host1 and host2 ..... 31 5.3.3 The hosts have a static ip . 32 5.3.4 Road-warrior scenario . 36 6 Conclusion 39 A Appendix 41 A.1 PAM........................................ 41 A.1.1 Framework Layer API’s . 41 A.2 Name Service Module . 42 A.2.1 NSS Module Nomenclature . 42 A.2.2 NSS Module Interface . 42 A.3 Feedback . 43 4 Summary I have designed and implemented a Strong Distributed Authentication Architecture for Linux as part of this Master’s Project. This document begins by giving an introduction to the current authentication mechanisms, the security issues faced with them and the motivation for implementing a new mechanism for distributed authentication. I then describe the design of the system, the modules that are part of it, how they are related to each other and the logical flow of the entire authentication process once a user types the name and password in the login screen. The report also covers the system internals that are specific to the implementation intended to be useful for the developers of applications that use this architecture. It finally ends with a section that intends to serve as a reference for the system administrators explaining the configuration details of the system. 5 Abstract The Distributed Authentication Architecture described in this report is a novel way for authentication of users using Public Key Infrastructure. It uses sayAnything certifi- cates and cryptography (through IPSec) for the flow of the authentication information in the network. Host authentication is done through IPSec. The issue of a user logging into a client terminal (which may not be trusted) is considered as a context to explain the effectiveness of this authentication mechanism. As part of a login to the terminal, the user’s private key is obtained which is used to create new authentication tokens. The user is not required to type passwords for accessing every network service after the login. The authentication happens implicitly for each network service request within the system and is controlled by the kernel thus providing better security. Misuse of the authentication token that has been created at the client side by an attacker (if the client is compromised) is limited by reducing its lifetime (to the order of some hours). To prevent off-line attacks, this scheme only provides the password encrypted private-key to someone who has the password. If this assumption is violated the server might leak the encrypted private-key, but the attacker still needs to crack the password in an off-line attack. The keys are distributed as part of sayAnything certificates and are sent in the network over IPSec thereby providing confidentiality, integrity and non-repudiation (because of public key cryptography). 6 1 Introduction Authentication is any process by which a system verifies that someone is who they claim to be. This section gives an overview of the current authentication mechanisms in UNIX. In earlier UNIX systems passwords were usually stored in the /etc/passwd (in a hashed form) which also keeps track of user information (such as the home directory and default shell). When a user types in a user name and password at login, a cryptographic hash of the password is generated and is compared with the existing hash in the file for that user. If the hashes match, then the system authenticates the user and the login scripts are executed. The problem with this approach is that the /etc/passwd file is world readable and anyone having access to the machine could retrieve the hashed passwords from the file. To address this vulnerability, the hashed passwords were stored in a separate file called /etc/shadow which is readable only by root. This might have solved the issue of the password hash being readable by an attacker but there were some problems that still remained: • Applications heavily depended on these files leading to less extensible code. • This approach did not scale well to distributed systems due to the availability of data being static and lack of inherent support from the operating system for running applications in a truly distributed way. • The password-based authentication over the network was subject to dictionary based attacks. • If a new authentication mechanism is introduced, it requires all the applications (like login, su etc.) that use the authentication information to be rewritten to support it. In order to address these issues Pluggable Authentication Modules and Naming Services were introduced to provide more effective ways to authenticate users. Pluggable Authentication Modules (PAM) [6] provide a generic framework enabling uniform authentication of user applications. PAM enables user applications to perform authentication without actually knowing the implementation details of the underlying authentication mechanisms. It is usually done through a password-based authentica- tion mechanism, but also supports a challenge-response interaction. An application can dynamically link a PAM module that implements a particular authentication scheme (ex: Kerberos). The advantage of PAM is that any change that occurs in the au- thentication mechanism does not require the applications to be retrofitted to support it. Naming services (NIS) store the information in central place which enables users ma- chines and applications to communicate across the network. The information can include user names, passwords, access permissions etc. Storing this information at a central place makes administration much easier. 7 When a user types in a name and password on the login screen, the appropriate PAM module configured for the specific authentication scheme performs the authentication. Information about the user like default shell and home directory can be obtained with the help of calls (like getpwnam()) to the Naming Service Module. PAM and NIS have been leveraged by many authentication infrastructures, the most popular and widely used among them being Kerberos. Kerberos [4] is a network authentication protocol that allows users communicating over an insecure network to securely prove their identity to each other. When a user logs in, the user name is sent to the authentication server along with the name of the service that user wants to access (say the remote file system needs to be mounted and the user is authenticated for the file server). The authentication server constructs a ticket containing a session key that is randomly generated and encrypts the ticket with the secret key of the server that the user is trying to connect to (file server). This ticket is sent to the client. If the user typed in the correct password then the client can decrypt the session key, present the ticket to the file server and use the shared session key for further communication. The ticket generally is provided only for a small duration. Once it expires the user needs to type in the password again to get a fresh ticket. In practice, there is a separate ticket-granting server (TGS) whose job typically is to grant tickets for other services. The first service requested by the user is now the TGS which then grants tickets for other additional services. The authentication server and the ticket granting server are together called the Key Distri- bution center (KDC). The client or the server shares a secret key known only to itself and the KDC. The drawbacks of Kerberos are: • It uses symmetric cryptography to encrypt the tickets. This has an inherent drawback of the key distribution and the problem of trust between the parties sharing the secret key. • Single Point of failure : The effectiveness of the authentication scheme of Kerberos is contingent on the integrity of the KDC. Since KDC is the central place where all the keys are stored, compromise of the KDC would render the entire authentication mechanism useless. • Non Repudiation is not possible as they are no certificates being used. The current work is an attempt to achieve stronger authentication when compared to the mechanisms existing today.

Load more

  44

Copy Link