summaryrefslogtreecommitdiffstats
path: root/doc/specs/std-agent-id.raw
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