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
|
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
from spec on 25 November 2000 -->
<TITLE>Exim Specification - 36. The plaintext authenticator</TITLE>
</HEAD>
<body bgcolor="#FFFFFF" text="#00005A" link="#FF6600" alink="#FF9933" vlink="#990000">
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_35.html">previous</A>, <A HREF="spec_37.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
<P><HR><P>
<H1><A NAME="SEC760" HREF="spec_toc.html#TOC760">36. The plaintext authenticator</A></H1>
<P>
<A NAME="IDX1692"></A>
The <EM>plaintext</EM> authenticator can be configured to support the PLAIN and LOGIN
authentication mechanisms, both of which transfer authentication data as plain
(unencrypted) text, though encoded in base 64.
<font color=green>
The use of plain text is a security risk. If you use one of these mechanisms
without also making use of SMTP encryption (see chapter 38) you should
not use the same passwords for SMTP connections as you do for login accounts.
</font>
</P>
<P>
<H2><A NAME="SEC761" HREF="spec_toc.html#TOC761">36.1 Using plaintext in a server</A></H2>
<P>
When running as a server, <EM>plaintext</EM> performs the authentication test by
expanding a string. It has the following options:
</P>
<P>
<P>
<A NAME="IDX1693"></A>
<H3><A NAME="SEC762" HREF="spec_toc.html#TOC762">server_prompts (plaintext)</A></H3>
<P>
Type: string, expanded<BR>
Default: unset
</P>
<P>
This option contains a colon-separated list of prompt strings.
</P>
<P>
<A NAME="IDX1694"></A>
<H3><A NAME="SEC763" HREF="spec_toc.html#TOC763">server_condition (plaintext)</A></H3>
<P>
Type: string, expanded<BR>
Default: unset
</P>
<P>
This option must be set in order to configure the driver as a server. Its use
is described below.
</P>
<P>
The data sent with the AUTH command or in response to subsequent prompts is
encoded in base 64, and so may contain any byte values when decoded. If any
data was supplied with the command, it is treated as a list of NUL-separated
strings which are placed in the expansion variables $<EM>1</EM>, $<EM>2</EM>, etc. If there
are more strings in <EM>server_prompts</EM> than the number of strings supplied with
the AUTH command, the remaining prompts are used to obtain more data. Each
response from the client may be a list of NUL-separated strings.
</P>
<P>
Once a sufficient number of data strings has been received, <EM>server_condition</EM>
is expanded. Failure of the expansion (forced or otherwise) causes a temporary
error code to be returned. If the result of a successful expansion is an empty
string, `0', `no', or `false', authentication fails. If the result of the
expansion is `1', `yes', or `true', authentication succeeds and the generic
<EM>server_set_id</EM> option is expanded and saved in $<EM>authenticated_id</EM>. For
any other result, a temporary error code is returned, with the expanded string
as the error text.
</P>
<P>
The PLAIN authentication mechanism (RFC 2595) specifies that three strings be
sent with the AUTH command. The second and third of them are a
user/password pair. Using a single fixed user and password as an example, this
could be configured as follows:
<PRE>
fixed_plain:
driver = plaintext
public_name = PLAIN
server_condition = \
${if and {{eq{$2}{ph10}}{eq{$3}{secret}}}{yes}{no}}
server_set_id = $2
</PRE>
<P>
This would be advertised in the response to EHLO as
<PRE>
250-AUTH PLAIN
</PRE>
<P>
and a client host could authenticate itself by sending the command
<PRE>
AUTH PLAIN AHBoMTAAc2VjcmV0
</PRE>
<P>
The argument string is encoded in base 64, as required by the RFC. This
example, when decoded, is `<<EM>NUL</EM>>ph10<<EM>NUL</EM>>secret', where <<EM>NUL</EM>> represents
a zero byte. This is split up into three strings, the first of which is empty.
The condition checks that the second two are `ph10' and `secret' respectively.
Because no prompt strings are set, if no data is given with the AUTH command,
authentication fails.
</P>
<P>
A more sophisticated instance of this authenticator could make use of the user
name in $<EM>2</EM> to look up a password in a file or database, and maybe do an
encrypted comparison (see <EM>crypteq</EM> in chapter 9). Note, however,
that the authentication data has traversed the network in clear, albeit encoded
as a base 64 string.
</P>
<P>
The LOGIN authentication mechanism is not documented in any RFC, but is in use
in a number of programs. No data is sent with the AUTH command. Instead, a
user name and password are supplied separately, in response to prompts. The
plaintext authenticator can be configured to support this as in this example:
<PRE>
fixed_login:
driver = plaintext
public_name = LOGIN
server_prompts = User Name : Password
server_condition = \
${if and {{eq{$1}{ph10}}{eq{$2}{secret}}}{yes}{no}}
server_set_id = $1
</PRE>
<P>
This authenticator would accept data with the AUTH command
<font color=green>
(in contravention of the specification of LOGIN),
</font>
but if the client does not supply it (as is the case for LOGIN clients), the
prompt strings are used to obtain two data items.
</P>
<H2><A NAME="SEC764" HREF="spec_toc.html#TOC764">36.2 Using plaintext in a client</A></H2>
<P>
The <EM>plaintext</EM> authenticator has just one client option:
</P>
<P>
<P>
<A NAME="IDX1695"></A>
<H3><A NAME="SEC765" HREF="spec_toc.html#TOC765">client_send (plaintext)</A></H3>
<P>
Type: string, expanded<BR>
Default: unset
</P>
<P>
The string is a colon-separated list of authentication data strings. Each
string is independently expanded before being sent to the server. The first
string is sent with the AUTH command; any more strings are sent in response
to prompts from the server.
</P>
<P>
Because the PLAIN authentication mechanism requires NUL (zero) bytes in the
data sent with the AUTH command, further processing is applied to each
string before it is sent. If there are any single circumflex characters in the
string, they are converted to NULs. Should an actual circumflex be required as
data, it must be doubled in the string.
</P>
<P>
This is an example of a client configuration that implements the PLAIN
authentication mechanism with a fixed name and password:
<PRE>
fixed_plain:
driver = plaintext
public_name = PLAIN
client_send = ^ph10^secret
</PRE>
<P>
The lack of colons means that the entire text is sent with the AUTH comand,
with the circumflex characters converted to NULs. A similar example that
uses the LOGIN mechanism is:
<PRE>
fixed_login:
driver = plaintext
public_name = LOGIN
client_send = : ph10 : secret
</PRE>
<P>
The initial colon ensures that no data is sent with the AUTH command
itself. The remaining strings are sent in response to prompts.
</P>
<P><HR><P>
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_35.html">previous</A>, <A HREF="spec_37.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
</BODY>
</HTML>
|
