diff options
Diffstat (limited to 'contrib/libpam/doc/specs/draft-morgan-pam-00.raw')
| -rw-r--r-- | contrib/libpam/doc/specs/draft-morgan-pam-00.raw | 270 |
1 files changed, 0 insertions, 270 deletions
diff --git a/contrib/libpam/doc/specs/draft-morgan-pam-00.raw b/contrib/libpam/doc/specs/draft-morgan-pam-00.raw deleted file mode 100644 index 6e37b86..0000000 --- a/contrib/libpam/doc/specs/draft-morgan-pam-00.raw +++ /dev/null @@ -1,270 +0,0 @@ -PAM working group ## A.G. Morgan -Internet Draft: ## March 24, 1998 -Document: draft-morgan-pam-00.txt ## -Expires: September 24, 1998 ## -Obsoletes: ## - -## Pluggable Authentication Modules ## - -#$ Status of this memo - -This document is an Internet-Draft. Internet-Drafts are working -documents of the Internet Engineering Task Force (IETF), its areas, -and its working groups. Note that other groups may also distribute -working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet- Drafts as reference -material or to cite them other than as "work in progress." - -To view the entire list of current Internet-Drafts, please check the -"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow -Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), -ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), -ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - -#$ Abstract - -This document is concerned with the definition of a general -infrastructure for module based authentication. The infrastructure is -named Pluggable Authentication Modules (PAM for short). - -#$ Introduction - -Computers are tools. They provide services to people and other -computers (collectively we shall call these "users" entities). In -order to provide convenient, reliable and individual service to -different entities, it is common for entities to be labelled. Having -defined a label as refering to a some specific entity, the label is -used for the purpose of protecting and allocating data resources. - -All modern operating systems have a notion of labelled entities and -all modern operating systems face a common problem: how to -authenticate the association of a predefined label with applicant -entities. - -There are as many authentication methods as one might care to count. -None of them are perfect and none of them are invulnerable. In -general, any given authentication method becomes weaker over time. It -is common then for new authentication methods to be developed in -response to newly discovered weaknesses in the old authentication -methods. - -The problem with reinventing authentication methods is the fact that -old applications do not support them. This contributes to an inertia -that discourages the overhaul of weakly protected systems. Another -problem is that individuals (people) are frequently powerless to layer -the protective authentication around their systems. They are forced -to rely on single (lowest common denominator) authentication schemes -even in situations where this is far from appropriate. - -PAM, as discussed in this document, is a generalization of the -approach first introduced in [#$R#{OSF_RFC_PAM}]. In short, it is a -general framework of interfaces that abstract the process of -authentication. With PAM, a service provider can custom protect -individual services to the level that they deam is appropriate. - -PAM has nothing explicit to say about transport layer encryption. -Within the context of this document encryption and/or compression of -data exchanges are application specific (strictly between client and -server). - -#$ Definitions - -Here we pose the authentication problem as one of configuring defined -interfaces between two entities. - -#$$#{players} Players in the authentication process - -PAM reserves the following words to specify unique entities in the -authentication process: - - applicant - the entity (user) initiating an application for service - [PAM associates PAM_RUSER with this requesting user]. - - arbitrator - the entity (user) under who's identity the service application - is negotiated and with who's authority service is granted. - - user - the entity (user) who's identity is being authenticated - [PAM associates PAM_USER with this identity]. - - server - the application that provides service, or acts as an - authenticated gateway to the requested service. This - application is completely responsible for the transport - layer. PAM makes no assumptions about how data is - exchanged between the server and the client. - - client - application providing the direct/primary interface to - applicant. This application is completely responsible - for transporting client-side data to the server. - PAM makes no assumptions about how data is exchanged between - the client and the server. - - module - authentication binary that provides server-side support for - some authentication method. - - agent - authentication binary that provides client-side support for - some authentication method. - -#$$ Special cases - -In the previous section (#{players}) we identified the most general -selection of authentication participants. In the case of network -authentication, it is easy to ascribe identities to the defined -players. However, there are special (less general) cases and we -recognize them here. - -The primary authentication step, when a user is directly introduced -into a computer system (log's on to a workstation) is a special case. -In this situation, the "client" and the "server" are generally one -application. Before authenticating such a user, the "applicant" is -formally unknown. - -#$ Defined interfaces - -Here, we discuss the formal interfaces between the players in the -authentication process. - -#$$#{applicant_client} Applicant <-> client - -Once the client is invoked, requests to the applicant entity are -initiated by the client application. General clients are able to make -the following requests to an applicant: - - echo text - echo error - prompt for echo'd text input - prompt for concealed text input - -the nature of the interface provided by the client for the benefit of -the applicant entity is client specific and not defined by PAM. - -#$$ Client <-> agent - -In general, authentication schemes require more modes of exchange than -the four defined in the previous section (#{applicant_client}). This -provides a role for client-loadable agents. The client and agent -exchange binary-messages that can have one of the following forms: - - client -> agent - prompt for binary data packet using a binary packet - - agent -> client - set environment variable - get environment variable - echo text - echo error - prompt for echo'd text input - prompt for concealed text input - -The single defined procedure for exchange is that the client first -prompts the agent with a binary packet and expects to receive a binary -(response) packet in return. Before returning the binary response, -the agent may request an arbitrary number of exchanges with the client. - -#$$ Client <-> server - -Once the client has established a connection with the server (the -nature of the transport protocol is not specified by PAM), the server -is reponsible for driving the authentication process. - -General servers can request the following from the client: - - (directed to the applicant) - echo text - echo error - prompt for echo'd text response - prompt for concealed text response - - (directed to the appropriate agent) - binary prompt for a binary response - -Client side agents are required to process binary prompts. Their -binary responses are passed directly back to the server. - -#$$ Server <-> module - -Modules drive the authentication process. The server provides a -conversation function with which it encapsulates module-generated -requests and exchanges them with the client. - -General conversation functions can support the following five -"conversation" requests: - - echo text - echo error - prompt for echo'd text response - prompt for concealed text response - prompt for binary packet with binary packet - -The server is responsible for redirecting these requests to the -client. - -#$ C API for defined interfaces - -#$$ Applicant <-> client - -No API is defined for this interface. The interface is considered to -be specific to the client application. Example applications include -terminal login, (X)windows login, machine file transfer applications. - -#$$ Client <-> agent - -This interface is concerned with the exchange of "binary prompts". A -binary prompt has the following form: { 4 8-bit bytes in network order -encoding an unsigened 32 bit integer (length), 4 8-bit bytes in -network order encoding an unsigened 32 bit integer (control), -"length-4" 8-bit bytes bytes comprising upto 2^32-4 bytes of binary -data }. - -## [ u32 | u32 | (length-4 bytes) ] ## -## length control data ## - -The composition of the "data" is not specified. Valid control values -are: - -##control value | used by | description ## -##------------------------------------------------------------------## -## | | ## -##PAMC_CONTROL_OK | agent | agent is happy ## -##PAMC_CONTROL_FAIL | agent | agent failed ## -##PAMC_CONTROL_BUSY | agent | agent is busy ## -##PAMC_CONTROL_PUTENV | agent | set envvar of client ## -##PAMC_CONTROL_GETENV | agent | want envvar of client ## -##PAMC_CONTROL_GETECHO | agent | echo'd prompt to applicant## -##PAMC_CONTROL_GETNOECHO | agent | secret prompt to applicant## -##PAMC_CONTROL_PUTTEXT | agent | echo text to applicant ## -##PAMC_CONTROL_SELECT | client | client selects named agent## -##PAMC_CONTROL_EXCHANGE | client+agent | data exchange packet ## -##PAMC_CONTROL_DONE | agent | agent has completed ## -##PAMC_CONTROL_EMPTY | agent | agent has no reply ## - -#$ Security considerations - -This document is devoted to standardizing authentication -infrastructure: everything in this document has implications for -security. - -#$ Contact - -The email list for discussing issues related to this document is -<pam-list@redhat.com>. - -#$ References - -[#{OSF_RFC_PAM}] OSF RFC 86.0, "Unified Login with Pluggable Authentication - Modules (PAM)", October 1995 - -#$ Author's Address - -Andrew Morgan -Email: morgan@ftp.kernel.org - |
