blob: d5fbdd565a58a0648a98b4d166e5d093f54fa50b (
plain)
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
|
PAM working group ## A.G. Morgan
## $Id$ ##
## Pluggable Authentication Modules ##
## REGISTERED AGENTS AND THEIR AGENT-ID'S ##
#$ Purpose of this document
#$$#{definition} Definition of an agent-id
The most complete version of a "PAM agent-id" is contained in this
reference [#$R#{PAM_RFC2}]. A copy of a recent definition is
reproduced here for convenience. The reader is recommended to consult
reference [#{PAM_RFC2}] for definitions of other terms that are
used in this document.
## -------------- ##
The agent_id is a sequence of characters satisfying the following
regexp:
/^[a-z0-9\_]+(@[a-z0-9\_.]+)?$/
and has a specific form for each independent agent.
o Agent_ids that do not contain an at-sign (@) are to be considered as
representing some authentication mode that is a "public
standard". Registered names MUST NOT contain an at-sign (@).
o Anyone can define additional agents by using names in the format
name@domainname, e.g. "ouragent@example.com". The part following
the at-sign MUST be a valid fully qualified internet domain name
[RFC-1034] controlled by the person or organization defining the
name. (Said another way, if you control the email address that
your agent has as an identifier, they you are entitled to use
this identifier.) It is up to each domain how it manages its local
namespace.
## -------------- ##
#$ Registered agent-id's
The structure of this section is a single subsection for each
registered agent-id. This section includes a full definition of binary
prompts accepted by the agent and example responses of said
agent. Using the defining section alone, it should be possible for a
third party to create a conforming agent and modules that can
interoperate with other implementations of these objects.
*$ "userpass" - the user+password agent
Many legacy authentication systems are hardcoded to support one and
only one authentication method. Namely,
username: joe
password: <secret>
Indeed, this authentication method is often embedded into parts of the
transport protocol. The "user+password" agent with PAM agent-id:
"userpass"
Is intended to support this legacy authentication scheme. The protocol
for binary prompt exchange with this 'standard agent' is as follows:
Case 1: module does not know the username, but expects the agent to
obtain this information and also the user's password:
module: {LENGTH;PAM_BP_SELECT;userpass;'/'}
agent: {}
Case 2: module has suggested username, but would like agent to confirm
it and gather password:
module: {}
agent: {}
Case 3: module knows username and will not permit the agent to change it:
module: {}
agent: {}
#$ References
[#{PAM_RFC2}] Internet draft, "Pluggable Authentication Modules
(PAM)", available here:
# http://linux.kernel.org/pub/linux/libs/pam/pre/doc/current-draft.txt #
#$ Author's Address
Andrew G. Morgan
Email: morgan@kernel.org
|
