1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
|
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
|