diff options
Diffstat (limited to 'doc/specs/rfc86.0.txt')
| -rw-r--r-- | doc/specs/rfc86.0.txt | 1851 |
1 files changed, 0 insertions, 1851 deletions
diff --git a/doc/specs/rfc86.0.txt b/doc/specs/rfc86.0.txt deleted file mode 100644 index 6dd5e6ea..00000000 --- a/doc/specs/rfc86.0.txt +++ /dev/null @@ -1,1851 +0,0 @@ - - - - - - - - - Open Software Foundation V. Samar (SunSoft) - Request For Comments: 86.0 R. Schemers (SunSoft) - October 1995 - - - - UNIFIED LOGIN WITH - PLUGGABLE AUTHENTICATION MODULES (PAM) - - - 1. INTRODUCTION - - Since low-level authentication mechanisms constantly evolve, it is - important to shield the high-level consumers of these mechanisms - (system-entry services and users) from such low-level changes. With - the Pluggable Authentication Module (PAM) framework, we can provide - pluggability for a variety of system-entry services -- not just - system authentication _per se_, but also for account, session and - password management. PAM's ability to _stack_ authentication modules - can be used to integrate `login' with different authentication - mechanisms such as RSA, DCE, and Kerberos, and thus unify login - mechanisms. The PAM framework can also provide easy integration of - smart cards into the system. - - Modular design and pluggability have become important for users who - want ease of use. In the PC hardware arena, no one wants to set the - interrupt vector numbers or resolve the addressing conflict between - various devices. In the software arena, people also want to be able - to replace components easily for easy customization, maintenance, and - upgrades. - - Authentication software deserves special attention because - authentication forms a very critical component of any secure computer - system. The authentication infrastructure and its components may - have to be modified or replaced either because some deficiencies have - been found in the current algorithms, or because sites want to - enforce a different security policy than what was provided by the - system vendor. The replacement and modification should be done in - such a way that the user is not affected by these changes. - - The solution has to address not just how the applications use the new - authentication mechanisms in a generic fashion, but also how the user - will be authenticated to these mechanisms in a generic way. The - former is addressed by GSS-API [Linn 93], while this RFC addresses - the later; these two efforts are complementary to each other. - - Since most system-entry services (for example, `login', `dtlogin', - `rlogin', `ftp', `rsh') may want to be independent of the specific - authentication mechanisms used by the machine, it is important that - there be a framework for _plugging_ in various mechanisms. This - requires that the system applications use a standard API to interact - - - - Samar, Schemers Page 1 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - with the authentication services. If these system-entry services - remain independent of the actual mechanism used on that machine, the - system administrator can install suitable authentication modules - without requiring changes to these applications. - - For any security system to be successful, it has to be easy to use. - In the case of authentication, the single most important ease-of-use - characteristic is that the user should not be required to learn about - various ways of authentication and remember multiple passwords. - Ideally, there should be one all-encompassing authentication system - where there is only one password, but for heterogeneous sites, - multiple authentication mechanisms have to co-exist. The problem of - integrating multiple authentication mechanisms such as Kerberos - [Steiner 88], RSA [Rivest 78], and Diffie-Hellman [Diffie 76, Taylor - 88], is also referred to as _integrated login_, or _unified login_ - problem. Even if the user has to use multiple authentication - mechanisms, the user should not be forced to type multiple passwords. - Furthermore, the user should be able to use the new network identity - without taking any further actions. The key here is in modular - integration of the network authentication technologies with `login' - and other system-entry services. - - In this RFC we discuss the architecture and design of pluggable - authentication modules. This design gives the capability to use - field-replaceable authentication modules along with unified login - capability. It thus provides for both _pluggability_ and _ease-of- - use_. - - The RFC is organized as follows. We first motivate the need for a - generic way to authenticate the user by various system-entry services - within the operating system. We describe the goals and constraints - of the design. This leads to the architecture, description of the - interfaces, and _stacking_ of modules to get unified login - functionality. We then describe our experience with the design, and - end with a description of future work. - - - 2. OVERVIEW OF IDENTIFICATION AND AUTHENTICATION MECHANISMS - - An identification and authentication ("I&A") mechanism is used to - establish a user's identity the system (i.e., to a local machine's - operating system) and to other principals on the network. On a - typical UNIX system, there are various ports of entry into the - system, such as `login', `dtlogin', `rlogin', `ftp', `rsh', `su', and - `telnet'. In all cases, the user has to be identified and - authenticated before granting appropriate access rights to the user. - The user identification and authentication for all these entry points - needs to be coordinated to ensure a secure system. - - In most of the current UNIX systems, the login mechanism is based - upon verification of the password using the modified DES algorithm. - - - - Samar, Schemers Page 2 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - The security of the implementation assumes that the password cannot - be guessed, and that the password does not go over the wire in the - clear. These assumptions, however, are not universally valid. - Various programs are now available freely on the Internet that can - run dictionary attack against the encrypted password. Further, some - of the network services (for example, `rlogin', `ftp', `telnet') send - the password over in clear, and there are "sniffer" programs freely - available to steal these passwords. The classical assumptions may be - acceptable on a trusted network, but in an open environment there is - a need to use more restrictive and stronger authentication - mechanisms. Examples of such mechanisms include Kerberos, RSA, - Diffie-Hellman, one-time password [Skey 94], and challenge-response - based smart card authentication systems. Since this list will - continue to evolve, it is important that the system-entry services do - not have hard-coded dependencies on any of these authentication - mechanisms. - - - 3. DESIGN GOALS - - The goals of the PAM framework are as follows: - - (a) The system administrator should be able to choose the default - authentication mechanism for the machine. This can range from - a simple password-based mechanism to a biometric or a smart - card based system. - - (b) It should be possible to configure the user authentication - mechanism on a per application basis. For example, a site may - require S/Key password authentication for `telnet' access, - while allowing machine `login' sessions with just UNIX password - authentication. - - (c) The framework should support the display requirements of the - applications. For example, for a graphical login session such - as `dtlogin', the user name and the password may have to be - entered in a new window. For networking system-entry - applications such as `ftp' and `telnet', the user name and - password has to be transmitted over the network to the client - machine. - - (d) It should be possible to configure multiple authentication - protocols for each of those applications. For example, one may - want the users to get authenticated by both Kerberos and RSA - authentication systems. - - (e) The system administrator should be able to _stack_ multiple - user authentication mechanisms such that the user is - authenticated with all authentication protocols without - retyping the password. - - - - - Samar, Schemers Page 3 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - (f) The architecture should allow for multiple passwords if - necessary to achieve higher security for users with specific - security requirements. - - (g) The system-entry services should not be required to change when - the underlying mechanism changes. This can be very useful for - third-party developers because they often do not have the - source code for these services. - - (h) The architecture should provide for a _pluggable_ model for - system authentication, as well as for other related tasks such - as password, account, and session management. - - (i) For backward-compatibility reasons, the PAM API should support - the authentication requirements of the current system-entry - services. - - There are certain issues that the PAM framework does not specifically - address: - - (a) We focus only on providing a generic scheme through which users - use passwords to establish their identities to the machine. - Once the identity is established, how the identity is - communicated to other interested parties is outside the scope - of this design. There are efforts underway at IETF [Linn 93] - to develop a Generic Security Services Application Interface - (GSSAPI) that can be used by applications for secure and - authenticated communication without knowing the underlying - mechanism. - - (b) The _single-signon_ problem of securely transferring the - identity of the caller to a remote site is not addressed. For - example, the problem of delegating credentials from the - `rlogin' client to the other machine without typing the - password is not addressed by our work. We also do not address - the problem of sending the passwords over the network in the - clear. - - (c) We do not address the source of information obtained from the - "`getXbyY()'" family of calls (e.g., `getpwnam()'). Different - operating systems address this problem differently. For - example, Solaris uses the name service switch (NSS) to - determine the source of information for the "`getXbyY()'" - calls. It is expected that data which is stored in multiple - sources (such as passwd entries in NIS+ and the DCE registry) - is kept in sync using the appropriate commands (such as - `passwd_export'). - - - - - - - - Samar, Schemers Page 4 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - 4. OVERVIEW OF THE PAM FRAMEWORK - - We propose that the goals listed above can be met through a framework - in which authentication modules can be _plugged_ independently of the - application. We call this the _Pluggable Authentication Modules_ - (PAM) framework. - - The core components of the PAM framework are the authentication - library API (the front end) and the authentication mechanism-specific - modules (the back end), connected through the Service Provider - Interface (SPI). Applications write to the PAM API, while the - authentication-system providers write to the PAM SPI and supply the - back end modules that are independent of the application. - - ftp telnet login (Applications) - | | | - | | | - +--------+--------+ - | - +-----+-----+ - | PAM API | <-- pam.conf file - +-----+-----+ - | - +--------+--------+ - UNIX Kerberos Smart Cards (Mechanisms) - - Figure 1: The Basic PAM Architecture - - Figure 1 illustrates the relationship between the application, the - PAM library, and the authentication modules. Three applications - (`login', `telnet' and `ftp') are shown which use the PAM - authentication interfaces. When an application makes a call to the - PAM API, it loads the appropriate authentication module as determined - by the configuration file, `pam.conf'. The request is forwarded to - the underlying authentication module (for example, UNIX password, - Kerberos, smart cards) to perform the specified operation. The PAM - layer then returns the response from the authentication module to the - application. - - PAM unifies system authentication and access control for the system, - and allows plugging of associated authentication modules through well - defined interfaces. The plugging can be defined through various - means, one of which uses a configuration file, such as the one in - Table 1. For each of the system applications, the file specifies the - authentication module that should be loaded. In the example below, - `login' uses the UNIX password module, while `ftp' and `telnet' use - the S/Key module. - - - - - - - - Samar, Schemers Page 5 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - Table 1: A Simplified View of a Sample PAM Configuration File. - - service module_path - ------- ----------- - login pam_unix.so - ftp pam_skey.so - telnet pam_skey.so - - Authentication configuration is only one aspect of this interface. - Other critical components include account management, session - management, and password management. For example, the `login' - program may want to verify not only the password but also whether the - account has aged or expired. Generic interfaces also need to be - provided so that the password can be changed according to the - requirements of the module. Furthermore, the application may want to - log information about the current session as determined by the - module. - - Not all applications or services may need all of the above - components, and not each authentication module may need to provide - support for all of the interfaces. For example, while `login' may - need access to all four components, `su' may need access to just the - authentication component. Some applications may use some specific - authentication and password management modules but share the account - and session management modules with others. - - This reasoning leads to a partitioning of the entire set of - interfaces into four areas of functionality: (1) authentication, (2) - account, (3) session, and (4) password. The concept of PAM was - extended to these functional areas by implementing each of them as a - separate pluggable module. - - Breaking the functionality into four modules helps the module - providers because they can use the system-provided libraries for the - modules that they are not changing. For example, if a supplier wants - to provide a better version of Kerberos, they can just provide that - new authentication and password module, and reuse the existing ones - for account and session. - - 4.1. Module Description - - More details on specific API's are described in Appendix A. A brief - description of four modules follows: - - (a) Authentication management: This set includes the - `pam_authenticate()' function to authenticate the user, and the - `pam_setcred()' interface to set, refresh or destroy the user - credentials. - - (b) Account management: This set includes the `pam_acct_mgmt()' - function to check whether the authenticated user should be - - - - Samar, Schemers Page 6 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - given access to his/her account. This function can implement - account expiration and access hour restrictions. - - (c) Session management: This set includes the `pam_open_session()' - and `pam_close_session()' functions for session management and - accounting. For example, the system may want to store the - total time for the session. - - (d) Password management: This set includes a function, - `pam_chauthtok()', to change the password. - - - 5. FRAMEWORK INTERFACES - - The PAM framework further provides a set of administrative interfaces - to support the above modules and to provide for application-module - communication. There is no corresponding service provider interface - (SPI) for such functions. - - 5.1. Administrative Interfaces - - Each set of PAM transactions starts with `pam_start()' and ends with - the `pam_end()' function. The interfaces `pam_get_item()' and - `pam_set_item()' are used to read and write the state information - associated with the PAM transaction. - - If there is any error with any of the PAM interfaces, the error - message can be printed with `pam_strerror()'. - - 5.2. Application-Module Communication - - During application initialization, certain data such as the user name - is saved in the PAM framework layer through `pam_start()' so that it - can be used by the underlying modules. The application can also pass - opaque data to the module which the modules will pass back while - communicating with the user. - - 5.3. User-Module Communication - - The `pam_start()' function also passes conversation function that has - to be used by the underlying modules to read and write module - specific authentication information. For example, these functions - can be used to prompt the user for the password in a way determined - by the application. PAM can thus be used by graphical, non- - graphical, or networked applications. - - - - - - - - - - Samar, Schemers Page 7 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - 5.4. Inter-Module Communication - - Though the modules are independent, they can share certain common - information about the authentication session such as user name, - service name, password, and conversation function through the - `pam_get_item()' and `pam_set_item()' interfaces. These API's can - also be used by the application to change the state information after - having called `pam_start()' once. - - 5.5. Module State Information - - The PAM service modules may want to keep certain module-specific - state information about the session. The interfaces `pam_get_data()' - and `pam_set_data()' can be used by the service modules to access and - update module-specific information as needed from the PAM handle. - The modules can also attach a cleanup function with the data. The - cleanup function is executed when `pam_end()' is called to indicate - the end of the current authentication activity. - - Since the PAM modules are loaded upon demand, there is no direct - module initialization support in the PAM framework. If there are - certain initialization tasks that the PAM service modules have to do, - they should be done upon the first invocation. However, if there are - certain clean-up tasks to be done when the authentication session - ends, the modules should use `pam_set_data()' to specify the clean-up - functions, which would be called when `pam_end()' is called by the - application. - - - 6. MODULE CONFIGURATION MANAGEMENT - - Table 2 shows an example of a configuration file `pam.conf' with - support for authentication, session, account, and password management - modules. `login' has three entries: one each for authentication - processing, session management and account management. Each entry - specifies the module name that should be loaded for the given module - type. In this example, the `ftp' service uses the authentication and - session modules. Note that all services here share the same session - management module, while having different authentication modules. - - - - - - - - - - - - - - - - Samar, Schemers Page 8 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - Table 2: Configuration File (pam.conf) with Different Modules - and Control Flow - - service module_type control_flag module_path options - ------- ----------- ------------ ----------- ------- - login auth required pam_unix_auth.so nowarn - login session required pam_unix_session.so - login account required pam_unix_account.so - ftp auth required pam_skey_auth.so debug - ftp session required pam_unix_session.so - telnet session required pam_unix_session.so - login password required pam_unix_passwd.so - passwd password required pam_unix_passwd.so - OTHER auth required pam_unix_auth.so - OTHER session required pam_unix_session.so - OTHER account required pam_unix_account.so - - The first field, _service_, denotes the service (for example, - `login', `passwd', `rlogin'). The name `OTHER' indicates the module - used by all other applications that have not been specified in this - file. This name can also be used if all services have the same - requirements. In the example, since all the services use the same - session module, we could have replaced those lines with a single - `OTHER' line. - - The second field, _module_type_, indicates the type of the PAM - functional module. It can be one of `auth', `account', `session', or - `password' modules. - - The third field, _control_flag_ determines the behavior of stacking - multiple modules by specifying whether any particular module is - _required_, _sufficient_, or _optional_. The next section describes - stacking in more detail. - - The fourth field, _module_path_, specifies the location of the - module. The PAM framework loads this module upon demand to invoke - the required function. - - The fifth field, _options_, is used by the PAM framework layer to - pass module specific options to the modules. It is up to the module - to parse and interpret the options. This field can be used by the - modules to turn on debugging or to pass any module specific - parameters such as a timeout value. It is also used to support - unified login as described below. The options field can be used by - the system administrator to fine-tune the PAM modules. - - If any of the fields are invalid, or if a module is not found, that - line is ignored and the error is logged as a critical error via - `syslog(3)'. If no entries are found for the given module type, then - the PAM framework returns an error to the application. - - - - - Samar, Schemers Page 9 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - 7. INTEGRATING MULTIPLE AUTHENTICATION SERVICES WITH STACKING - - In the world of heterogeneous systems, the system administrator often - has to deal with the problem of integrating multiple authentication - mechanisms. The user is often required to know about the - authentication command of the new authentication module (for example, - `kinit', `dce_login') after logging into the system. This is not - user-friendly because it forces people to remember to type the new - command and enter the new password. This functionality should be - invisible instead of burdening the user with it. - - There are two problems to be addressed here: - - (a) Supporting multiple authentication mechanisms. - - (b) Providing unified login in the presence of multiple mechanisms. - - In the previous section, we described how one could replace the - default authentication module with any other module of choice. Now - we demonstrate how the same model can be extended to provide support - for multiple modules. - - 7.1. Design for Stacked Modules - - One possibility was to provide hard-coded rules in `login' or other - applications requiring authentication services [Adamson 95]. But - this becomes very specific to the particular combination of - authentication protocols, and also requires the source code of the - application. Digital's Security Integration Architecture [SIA 95] - addresses this problem by specifying the same list of authentication - modules for all applications. Since requirements for various - applications can vary, it is essential that the configuration be on a - per-application basis. - - To support multiple authentication mechanisms, the PAM framework was - extended to support _stacking_. When any API is called, the back - ends for the stacked modules are invoked in the order listed, and the - result returned to the caller. In Figure 2, the authentication - service of `login' is stacked and the user is authenticated by UNIX, - Kerberos, and RSA authentication mechanisms. Note that in this - example, there is no stacking for session or account management - modules. - - - - - - - - - - - - - Samar, Schemers Page 10 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - login - | - +--------+--------+ - | | | - session auth account - | | | - +--+--+ +--+--+ +--+--+ - | PAM | | PAM | | PAM | - +--+--+ +--+--+ +--+--+ - | | | - UNIX UNIX UNIX - session auth account - | - Kerberos - auth - | - RSA - auth - - Figure 2: Stacking With the PAM Architecture - - Stacking is specified through additional entries in the configuration - file shown earlier. As shown in Table 2, for each application (such - as `login') the configuration file can specify multiple mechanisms - that have to be invoked in the specified order. When mechanisms - fail, the _control_flag_ decides which error should be returned to - the application. Since the user should not know which authentication - module failed when a bad password was typed, the PAM framework - continues to call other authentication modules on the stack even on - failure. The semantics of the control flag are as follows: - - (a) `required': With this flag, the module failure results in the - PAM framework returning the error to the caller _after_ - executing all other modules on the stack. For the function to - be able to return success to the application all `required' - modules have to report success. This flag is normally set when - authentication by this module is a _must_. - - (b) `optional': With this flag, the PAM framework ignores the - module failure and continues with the processing of the next - module in sequence. This flag is used when the user is allowed - to login even if that particular module has failed. - - (c) `sufficient': With this flag, if the module succeeds the PAM - framework returns success to the application immediately - without trying any other modules. For failure cases, the - _sufficient_ modules are treated as `optional'. - - Table 3 shows a sample configuration file that stacks the `login' - command. Here the user is authenticated by UNIX, Kerberos, and RSA - authentication services. The `required' key word for _control_flag_ - - - - Samar, Schemers Page 11 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - enforces that the user is allowed to login only if he/she is - authenticated by _both_ UNIX and Kerberos services. RSA - authentication is optional by virtue of the `optional' key word in - the _control_flag_ field. The user can still log in even if RSA - authentication fails. - - Table 3: PAM Configuration File with Support for Stacking - - service module_type control_flag module_path options - ------- ----------- ------------ ----------- ------- - login auth required pam_unix.so debug - login auth required pam_kerb.so use_mapped_pass - login auth optional pam_rsa.so use_first_pass - - Table 4 illustrates the use of the sufficient flag for the `rlogin' - service. The Berkeley `rlogin' protocol specifies that if the remote - host is trusted (as specified in the `/etc/hosts.equiv' file or in - the `.rhosts' file in the home directory of the user), then the - `rlogin' daemon should not require the user to type the password. If - this is not the case, then the user is required to type the password. - Instead of hard coding this policy in the `rlogin' daemon, this can - be expressed with the `pam.conf' file in Table 4. The PAM module - `pam_rhosts_auth.so.1' implements the `.rhosts' policy described - above. If a site administrator wants to enable remote login with - only passwords, then the first line should be deleted. - - Table 4: PAM Configuration File for the rlogin service - - service module_type control_flag module_path options - ------- ----------- ------------ ----------- ------- - rlogin auth sufficient pam_rhosts_auth.so - rlogin auth required pam_unix.so - - 7.2. Password-Mapping - - Multiple authentication mechanisms on a machine can lead to multiple - passwords that users have to remember. One attractive solution from - the ease-of-use viewpoint is to use the same password for all - mechanisms. This, however, can also weaken the security because if - that password were to be compromised in any of the multiple - mechanisms, all mechanisms would be compromised at the same time. - Furthermore, different authentication mechanisms may have their own - distinctive password requirements in regards to its length, allowed - characters, time interval between updates, aging, locking, and so - forth. These requirements make it problematic to use the same - password for multiple authentication mechanisms. - - The solution we propose, while not precluding use of the same - password for every mechanism, allows for a different password for - each mechanism through what we call _password-mapping_. This - basically means using the user's _primary_ password to encrypt the - - - - Samar, Schemers Page 12 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - user's other (_secondary_) passwords, and storing these encrypted - passwords in a place where they are available to the user. Once the - primary password is verified, the authentication modules would obtain - the other passwords for their own mechanisms by decrypting the - mechanism-specific encrypted password with the primary password, and - passing it to the authentication service. The security of this - design for password-mapping assumes that the primary password is the - user's strongest password, in terms of its unguessability (length, - type and mix of characters used, etc.). - - If there is any error in password-mapping, or if the mapping does not - exist, the user will be prompted for the password by each - authentication module. - - To support password-mapping, the PAM framework saves the primary - password and provides it to stacked authentication modules. The - password is cleared out before the `pam_authenticate' function - returns. - - How the password is encrypted depends completely on the module - implementation. The encrypted secondary password (also called a - "mapped password") can be stored in a trusted or untrusted place, - such as a smart card, a local file, or a directory service. If the - encrypted passwords are stored in an untrusted publicly accessible - place, this does provide an intruder with opportunities for potential - dictionary attack. - - Though password-mapping is voluntary, it is recommended that all - module providers add support for the following four mapping options: - - (a) `use_first_pass': Use the same password used by the first - mechanism that asked for a password. The module should not ask - for the password if the user cannot be authenticated by the - first password. This option is normally used when the system - administrator wants to enforce the same password across - multiple modules. - - (b) `try_first_pass': This is the same as `use_first_pass', except - that if the primary password is not valid, it should prompt the - user for the password. - - (c) `use_mapped_pass': Use the password-mapping scheme to get the - actual password for this module. One possible implementation - is to get the mapped-password using the XFN API [XFN 94], and - decrypt it with the primary password to get the module-specific - password. The module should not ask for the password if the - user cannot be authenticated by the first password. The XFN - API allows user-defined attributes (such as _mapped-password_) - to be stored in the _user-context_. Using the XFN API is - particularly attractive because support for the XFN may be - found on many systems in the future. - - - - Samar, Schemers Page 13 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - (d) `try_mapped_pass': This is the same as `use_mapped_pass', - except that if the primary password is not valid, it should - prompt the user for the password. - - When passwords get updated, the PAM framework stores both the old as - well as the new password to be able to inform other dependent - authentication modules about the change. Other modules can use this - information to update the encrypted password without forcing the user - to type the sequence of passwords again. The PAM framework clears - out the passwords before returning to the application. - - Table 3 illustrates how the same password can be used by `login' for - authenticating to the standard UNIX login, Kerberos and RSA services. - Once the user has been authenticated to the primary authentication - service (UNIX `login' in this example) with the primary password, the - option `use_mapped_pass' indicates to the Kerberos module that it - should use the primary password to decrypt the stored Kerberos - password and then use the Kerberos password to get the ticket for the - ticket-granting-service. After that succeeds, the option - `use_first_pass' indicates to the RSA module that instead of - prompting the user for a password, it should use the primary password - typed earlier for authenticating the user. Note that in this - scenario, the user has to enter the password just once. - - Note that if a one-time password scheme (e.g., S/Key) is used, - password mapping cannot apply. - - 7.3. Implications of Stacking on the PAM Design - - Because of the stacking capability of PAM, we have designed the PAM - API's to not return any data to the application, except status. If - this were not the case, it would be difficult for the PAM framework - to decide which module should return data to the application. When - there is any error, the application does not know which of the - modules failed. This behavior enables (even requires) the - application to be completely independent from the modules. - - Another design decision we have made is that PAM gives only the user - name to all the underlying PAM modules, hence it is the - responsibility of the PAM modules to convert the name to their own - internal format. For example, the Kerberos module may have to - convert the UNIX user name to a Kerberos principal name. - - Stacking also forces the modules to be designed such that they can - occur anywhere in the stack without any side-effects. - - Since modules such as the authentication and the password module are - very closely related, it is important they be configured in the same - order and with compatible options. - - - - - - Samar, Schemers Page 14 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - 8. INTEGRATION WITH SMART CARDS - - Many networking authentication protocols require possession of a long - key to establish the user identity. For ease-of-use reasons, that - long key is normally encrypted with the user's password so that the - user is not required to memorize it. However, weak passwords can be - compromised through a dictionary attack and thus undermine the - stronger network authentication mechanism. Furthermore, the - encrypted data is normally stored in a centrally accessible service - whose availability depends upon the reliability of the associated - service. Solutions have been proposed to use a pass-phrase or one- - time-password, but those are much longer than the regular eight - character passwords traditionally used with UNIX `login'. This makes - the solution user-unfriendly because it requires longer strings to be - remembered and typed. - - For most authentication protocol implementations, the trust boundary - is the local machine. This assumption may not be valid in cases - where the user is mobile and has to use publicly available networked - computers. In such cases, it is required that the clear text of the - key or the password never be made available to the machine. - - Smart cards solve the above problems by reducing password exposure by - supporting a _two factor_ authentication mechanism: the first with - the possession of the card, and the second with the knowledge of the - PIN associated with the card. Not only can the smart cards be a - secure repository of multiple passwords, they can also provide the - encryption and authentication functions such that the long (private) - key is never exposed outside the card. - - The PAM framework allows for integrating smart cards to the system by - providing a smart card specific module for authentication. - Furthermore, the unified login problem is simplified because the - multiple passwords for various authentication mechanisms can be - stored on the smart card itself. This can be enabled by adding a - suitable key-word such as `use_smart_card' in the _options_ field. - - - 9. SECURITY ISSUES - - It is important to understand the impact of PAM on the security of - any system so that the site-administrator can make an informed - decision. - - (a) Sharing of passwords with multiple authentication mechanisms. - - If there are multiple authentication modules, one possibility - is to use the same password for all of them. If the password - for any of the multiple authentication system is compromised, - the user's password in all systems would be compromised. If - this is a concern, then multiple passwords might be considered - - - - Samar, Schemers Page 15 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - at the cost of ease-of-use. - - (b) Password-mapping. - - This technique of encrypting all other passwords with the - primary password assumes that it is lot more difficult to crack - the primary password and that reasonable steps have been taken - to ensure limited availability of the encrypted primary - password. If this is not done, an intruder could target the - primary password as the first point of dictionary attack. If - one of the other modules provide stronger security than the - password based security, the site would be negating the strong - security by using password-mapping. If this is a concern, then - multiple passwords might be considered at the cost of ease-of- - use. If smart cards are used, they obviate the need for - password-mapping completely. - - (c) Security of the configuration file. - - Since the policy file dictates how the user is authenticated, - this file should be protected from unauthorized modifications. - - (d) Stacking various PAM modules. - - The system administrator should fully understand the - implications of stacking various modules that will be installed - on the system and their respective orders and interactions. - The composition of various authentication modules should be - carefully examined. The trusted computing base of the machine - now includes the PAM modules. - - - 10. EXPERIENCE WITH PAM - - The PAM framework was first added in Solaris 2.3 release as a private - internal interface. PAM is currently being used by several system - entry applications such as `login', `passwd', `su', `dtlogin', - `rlogind', `rshd', `telnetd', `ftpd', `in.rexecd', `uucpd', `init', - `sac', and `ttymon'. We have found that PAM provides an excellent - framework to encapsulate the authentication-related tasks for the - entire system. The Solaris 2.3 PAM API's were hence enhanced and - simplified to support stacking. - - PAM modules have been developed for UNIX, DCE, Kerberos, S/Key, - remote user authentication, and dialpass authentication. Other PAM - modules are under development, and integration with smart cards is - being planned. - - Some third parties have used the PAM interface to extend the security - mechanisms offered by the Solaris environment. - - - - - Samar, Schemers Page 16 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - The PAM API has been accepted by Common Desktop Environment (CDE) - vendors as the API to be used for integrating the graphical interface - for login, `dtlogin' with multiple authentication mechanisms. - - - 11. FUTURE WORK - - Amongst the various components of PAM, the password component needs - to be carefully examined to see whether the stacking semantics are - particularly applicable, and how PAM should deal with partial - failures when changing passwords. - - The _control_flag_ of the configuration file can be extended to - include other semantics. For example, if the error is "name service - not available", one may want to retry. It is also possible to offer - semantics of "return success if any of the modules return success". - - In an earlier section, we had mentioned integration of smart cards - with PAM. Though we feel that integration should be straight forward - from the PAM architecture point of view, there may be some issues - with implementation because the interfaces to the smart cards have - not yet been standardized. - - One possible extension to PAM is to allow the passing of module- - specific data between applications and PAM modules. For example, the - `login' program likes to build its new environment from a select list - of variables, yet the DCE module needs the `KRB5CCNAME' variable to - be exported to the child process. For now we have modified the - `login' program to explicitly export the `KRB5CCNAME' variable. - - Administrative tools are needed to help system administrators modify - `pam.conf', and perform sanity checks on it (i.e., a `pam_check' - utility). - - - 12. CONCLUSION - - The PAM framework and the module interfaces provide pluggability for - user authentication, as well as for account, session and password - management. The PAM architecture can be used by `login' and by all - other system-entry services, and thus ensure that all entry points - for the system have been secured. This architecture enables - replacement and modification of authentication modules in the field - to secure the system against the newly found weaknesses without - changing any of the system services. - - The PAM framework can be used to integrate `login' and `dtlogin' with - different authentication mechanisms such as RSA and Kerberos. - Multiple authentication systems can be accessed with the same - password. The PAM framework also provides easy integration of smart - cards into the system. - - - - Samar, Schemers Page 17 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - PAM provides complementary functionality to GSS-API, in that it - provides mechanisms through which the user gets authenticated to any - new system-level authentication service on the machine. GSS-API then - uses the credentials for authenticated and secure communications with - other application-level service entities on the network. - - - 13. ACKNOWLEDGEMENTS - - PAM development has spanned several release cycles at SunSoft. - Shau-Ping Lo, Chuck Hickey, and Alex Choy did the first design and - implementation. Bill Shannon and Don Stephenson helped with the PAM - architecture. Rocky Wu prototyped stacking of multiple modules. - Paul Fronberg, Charlie Lai, and Roland Schemers made very significant - enhancements to the PAM interfaces and took the project to completion - within a very short time. Kathy Slattery wrote the PAM - documentation. John Perry integrated PAM within the CDE framework. - - - APPENDIX A. PAM API'S - - This appendix gives an informal description of the various interfaces - of PAM. Since the goal here is just for the reader to get a working - knowledge about the PAM interfaces, not all flags and options have - been fully defined and explained. The API's described here are - subject to change. - - The PAM Service Provider Interface is very similar to the PAM API, - except for one extra parameter to pass module-specific options to the - underlying modules. - - A.1. Framework Layer API's - - int - pam_start( - char *service_name, - char *user, - struct pam_conv *pam_conversation, - pam_handle_t **pamh - ); - - `pam_start()' is called to initiate an authentication transaction. - `pam_start()' takes as arguments the name of the service, the name of - the user to be authenticated, the address of the conversation - structure. `pamh' is later used as a handle for subsequent calls to - the PAM library. - - The PAM modules do not communicate directly with the user; instead - they rely on the application to perform all such interaction. The - application needs to provide the conversation functions, `conv()', - and associated application data pointers through a `pam_conv' - - - - Samar, Schemers Page 18 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - structure when it initiates an authentication transaction. The - module uses the `conv()' function to prompt the user for data, - display error messages, or text information. - - int - pam_end( - pam_handle_t *pamh, - int pam_status - ); - - `pam_end()' is called to terminate the PAM transaction as specified - by `pamh', and to free any storage area allocated by the PAM modules - with `pam_set_item()'. - - int - pam_set_item( - pam_handle_t *pamh, - int item_type, - void *item - ); - - int - pam_get_item( - pam_handle_t *pamh, - int item_type, - void **item); - - `pam_get_item()' and `pam_set_item()' allow the parameters specified - in the initial call to `pam_start()' to be read and updated. This is - useful when a particular parameter is not available when - `pam_start()' is called or must be modified after the initial call to - `pam_start()'. `pam_set_item()' is passed a pointer to the object, - `item', and its type, `item_type'. `pam_get_item()' is passed the - address of the pointer, `item', which is assigned the address of the - requested object. - - The `item_type' is one of the following: - - Table 5: Possible Values for Item_type - - Item Name Description - --------- ----------- - PAM_SERVICE The service name - PAM_USER The user name - PAM_TTY The tty name - PAM_RHOST The remote host name - PAM_CONV The pam_conv structure - PAM_AUTHTOK The authentication token (password) - PAM_OLDAUTHTOK The old authentication token - PAM_RUSER The remote user name - - - - - Samar, Schemers Page 19 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - Note that the values of `PAM_AUTHTOK' and `PAM_OLDAUTHTOK' are only - available to PAM modules and not to the applications. They are - explicitly cleared out by the framework before returning to the - application. - - char * - pam_strerror( - int errnum - ); - - `pam_strerror()' maps the error number to a PAM error message string, - and returns a pointer to that string. - - int - pam_set_data( - pam_handle_t *pamh, - char *module_data_name, - char *data, - (*cleanup)(pam_handle_t *pamh, char *data, - int error_status) - ); - - The `pam_set_data()' function stores module specific data within the - PAM handle. The `module_data_name' uniquely specifies the name to - which some data and cleanup callback function can be attached. The - cleanup function is called when `pam_end()' is invoked. - - int - pam_get_data( - pam_handle_t *pamh, - char *module_data_name, - void **datap - ); - - The `pam_get_data()' function obtains module-specific data from the - PAM handle stored previously by the `pam_get_data()' function. The - `module_data_name' uniquely specifies the name for which data has to - be obtained. This function is normally used to retrieve module - specific state information. - - A.2. Authentication API's - - int - pam_authenticate( - pam_handle_t *pamh, - int flags - ); - - The `pam_authenticate()' function is called to verify the identity of - the current user. The user is usually required to enter a password - or similar authentication token, depending upon the authentication - - - - Samar, Schemers Page 20 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - module configured with the system. The user in question is specified - by a prior call to `pam_start()', and is referenced by the - authentication handle, `pamh'. - - int - pam_setcred( - pam_handle_t *pamh, - int flags - ); - - The `pam_setcred()' function is called to set the credentials of the - current process associated with the authentication handle, `pamh'. - The actions that can be denoted through `flags' include credential - initialization, refresh, reinitialization and deletion. - - A.3. Account Management API - - int - pam_acct_mgmt( - pam_handle_t *pamh, - int flags - ); - - The function `pam_acct_mgmt()' is called to determine whether the - current user's account and password are valid. This typically - includes checking for password and account expiration, valid login - times, etc. The user in question is specified by a prior call to - `pam_start()', and is referenced by the authentication handle, - `pamh'. - - A.4. Session Management API's - - int - pam_open_session( - pam_handle_t *pamh, - int flags - ); - - `pam_open_session()' is called to inform the session modules that a - new session has been initialized. All programs which use PAM should - invoke `pam_open_session()' when beginning a new session. - - int - pam_close_session( - pam_handle_t *pamh, - int flags - ); - - Upon termination of this session, the `pam_close_session()' function - should be invoked to inform the underlying modules that the session - has terminated. - - - - Samar, Schemers Page 21 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - A.5. Password Management API's - - int - pam_chauthtok( - pam_handle_t *pamh, - int flags - ); - - `pam_chauthtok()' is called to change the authentication token - associated with the user referenced by the authentication handle - `pamh'. After the call, the authentication token of the user will be - changed in accordance with the authentication module configured on - the system. - - - APPENDIX B. SAMPLE PAM APPLICATION - - This appendix shows a sample `login' application which uses the PAM - API's. It is not meant to be a fully functional login program, as - some functionality has been left out in order to emphasize the use of - PAM API's. - - #include <security/pam_appl.h> - - static int login_conv(int num_msg, struct pam_message **msg, - struct pam_response **response, void *appdata_ptr); - - static struct pam_conv pam_conv = {login_conv, NULL}; - - static pam_handle_t *pamh; /* Authentication handle */ - - void - main(int argc, char *argv[], char **renvp) - { - - /* - * Call pam_start to initiate a PAM authentication operation - */ - - if ((pam_start("login", user_name, &pam_conv, &pamh)) - != PAM_SUCCESS) - login_exit(1); - - pam_set_item(pamh, PAM_TTY, ttyn); - pam_set_item(pamh, PAM_RHOST, remote_host); - - while (!authenticated && retry < MAX_RETRIES) { - status = pam_authenticate(pamh, 0); - authenticated = (status == PAM_SUCCESS); - } - - - - - Samar, Schemers Page 22 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - if (status != PAM_SUCCESS) { - fprintf(stderr,"error: %s\n", pam_strerror(status)); - login_exit(1); - } - - /* now check if the authenticated user is allowed to login. */ - - if ((status = pam_acct_mgmt(pamh, 0)) != PAM_SUCCESS) { - if (status == PAM_AUTHTOK_EXPIRED) { - status = pam_chauthtok(pamh, 0); - if (status != PAM_SUCCESS) - login_exit(1); - } else { - login_exit(1); - } - } - - /* - * call pam_open_session to open the authenticated session - * pam_close_session gets called by the process that - * cleans up the utmp entry (i.e., init) - */ - if (status = pam_open_session(pamh, 0) != PAM_SUCCESS) { - login_exit(status); - } - - /* set up the process credentials */ - setgid(pwd->pw_gid); - - /* - * Initialize the supplementary group access list. - * This should be done before pam_setcred because - * the PAM modules might add groups during the pam_setcred call - */ - initgroups(user_name, pwd->pw_gid); - - status = pam_setcred(pamh, PAM_ESTABLISH_CRED); - if (status != PAM_SUCCESS) { - login_exit(status); - } - - /* set the real (and effective) UID */ - setuid(pwd->pw_uid); - - pam_end(pamh, PAM_SUCCESS); /* Done using PAM */ - - /* - * Add DCE/Kerberos cred name, if any. - * XXX - The module specific stuff should be removed from login - * program eventually. This is better placed in DCE module and - * will be once PAM has routines for "exporting" environment - - - - Samar, Schemers Page 23 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - * variables. - */ - krb5p = getenv("KRB5CCNAME"); - if (krb5p != NULL) { - ENVSTRNCAT(krb5ccname, krb5p); - envinit[basicenv++] = krb5ccname; - } - environ = envinit; /* Switch to the new environment. */ - exec_the_shell(); - - /* All done */ - } - - /* - * login_exit - Call exit() and terminate. - * This function is here for PAM so cleanup can - * be done before the process exits. - */ - static void - login_exit(int exit_code) - { - if (pamh) - pam_end(pamh, PAM_ABORT); - exit(exit_code); - /*NOTREACHED*/ - } - - /* - * login_conv(): - * This is the conv (conversation) function called from - * a PAM authentication module to print error messages - * or garner information from the user. - */ - - static int - login_conv(int num_msg, struct pam_message **msg, - struct pam_response **response, void *appdata_ptr) - { - - while (num_msg--) { - switch (m->msg_style) { - - case PAM_PROMPT_ECHO_OFF: - r->resp = strdup(getpass(m->msg)); - break; - - case PAM_PROMPT_ECHO_ON: - (void) fputs(m->msg, stdout); - r->resp = malloc(PAM_MAX_RESP_SIZE); - fgets(r->resp, PAM_MAX_RESP_SIZE, stdin); - /* add code here to remove \n from fputs */ - - - - Samar, Schemers Page 24 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - break; - - case PAM_ERROR_MSG: - (void) fputs(m->msg, stderr); - break; - - case PAM_TEXT_INFO: - (void) fputs(m->msg, stdout); - break; - - default: - /* add code here to log error message, etc */ - break; - } - } - return (PAM_SUCCESS); - } - - - APPENDIX C. DCE MODULE - - This appendix describes a sample implementation of a DCE PAM module. - In order to simplify the description, we do not address the issues - raised by password-mapping or stacking. The intent is to show which - DCE calls are being made by the DCE module. - - The `pam_sm_*()' functions implement the PAM SPI functions which are - called from the PAM API functions. - - C.1. DCE Authentication Management - - The algorithm for authenticating with DCE (not including error - checking, prompting for passwords, etc.) is as follows: - - pam_sm_authenticate() - { - sec_login_setup_identity(...); - pam_set_data(...); - sec_login_valid_and_cert_ident(...); - } - - pam_sm_setcred() - { - pam_get_data(...); - sec_login_set_context(...); - } - - The `pam_sm_authenticate()' function for DCE uses the - `pam_set_data()' and `pam_get_data()' functions to keep state (like - the `sec_login_handle_t' context) between calls. The following - cleanup function is also registered and gets called when `pam_end()' - - - - Samar, Schemers Page 25 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - is called: - - dce_cleanup() - { - if (/* PAM_SUCCESS and - sec_login_valid_and_cert_ident success */) { - sec_login_release_context(...); - } else { - sec_login_purge_context(...); - } - } - - If everything was successful we release the login context, but leave - the credentials file intact. If the status passed to `pam_end()' was - not `PAM_SUCCESS' (i.e., a required module failed) we purge the login - context which also removes the credentials file. - - C.2. DCE Account Management - - The algorithm for DCE account management is as follows: - - pam_sm_acct_mgmt() - { - pam_get_data(...); - sec_login_inquire_net_info(...); - /* check for expired password and account */ - sec_login_free_net_info(...); - } - - The `sec_login_inquire_net_info()' function is called to obtain - information about when the user's account and/or password are going - to expire. A warning message is displayed (using the conversation - function) if the user's account or password is going to expire in the - near future, or has expired. These warning messages can be disabled - using the `nowarn' option in the `pam.conf' file. - - C.3. DCE Session Management - - The DCE session management functions are currently empty. They could - be modified to optionally remove the DCE credentials file upon - logout, etc. - - C.4. DCE Password Management - - The algorithm for DCE password management is as follows: - - - - - - - - - - Samar, Schemers Page 26 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - pam_sm_chauthtok - { - sec_rgy_site_open(...); - sec_rgy_acct_lookup(...); - sec_rgy_acct_passwd(...); - sec_rgy_site_close(...); - } - - The `sec_rgy_acct_passwd()' function is called to change the user's - password in the DCE registry. - - - REFERENCES - - [Adamson 95] W. A. Adamson, J. Rees, and P. Honeyman, "Joining - Security Realms: A Single Login for Netware and - Kerberos", CITI Technical Report 95-1, Center for - Information Technology Integration, University of - Michigan, Ann Arbor, MI, February 1995. - - [Diffie 76] W. Diffie and M. E. Hellman, "New Directions in - Cryptography", IEEE Transactions on Information - Theory, November 1976. - - [Linn 93] J. Linn, "Generic Security Service Application - Programming Interface", Internet RFC 1508, 1509, 1993. - - [Rivest 78] R. L. Rivest, A. Shamir, and L. Adleman., "A Method - for Obtaining Digital Signatures and Pubic-key - Cryptosystems", Communications of the ACM, 21(2), - 1978. - - [SIA 95] "Digital UNIX Security", Digital Equipment - Corporation, Order Number AA-Q0R2C-TE, July 1995. - - [Skey 94] N. M. Haller, "The S/Key One-Time Password System", - ISOC Symposium on Network and Distributed Security, - 1994. - - [Steiner 88] J.G. Steiner, B. C. Neuman, and J. I. Schiller, - "Kerberos, An Authentication Service for Open Network - Systems", in Proceedings of the Winter USENIX - Conference, Dallas, Jan 1988. - - [Taylor 88] B. Taylor and D. Goldberg, "Secure Networking in the - Sun Environment", Sun Microsystems Technical Paper, - 1988. - - [XFN 94] "Federated Naming: the XFN Specifications", X/Open - Preliminary Specification, X/Open Document #P403, - ISBN:1-85912-045-8, X/Open Co. Ltd., July 1994. - - - - Samar, Schemers Page 27 - - - - - - - - OSF-RFC 86.0 PAM October 1995 - - - - AUTHOR'S ADDRESS - - Vipin Samar Internet email: vipin@eng.sun.com - SunSoft, Inc. Telephone: +1-415-336-1002 - 2550 Garcia Avenue - Mountain View, CA 94043 - USA - - Roland J. Schemers III Internet email: schemers@eng.sun.com - SunSoft, Inc. Telephone: +1-415-336-1035 - 2550 Garcia Avenue - Mountain View, CA 94043 - USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Samar, Schemers Page 28 - - - - - - |