Adding upstream version 1.4.0.upstream/1.4.0upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 1845 insertions, 0 deletions

diff --git a/doc/specs/rfc86.0.txt b/doc/specs/rfc86.0.txt
new file mode 100644
index 0000000..b8c635a
--- /dev/null
+++ b/doc/specs/rfc86.0.txt
@@ -0,0 +1,1845 @@
+
+
+
+
+
+
+
+
+   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