dip/remote.html at master · daftano/dip · GitHub

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
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
       "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<title>
GnuDIP Remote User Maintenance Protocol
</title>

<base target="_blank">

</head>

<body bgcolor=white>

<table><tr valign=middle><td>
<img align=middle src="gnudip/html/gnudip.jpg" alt="GnuDIP Logo" border=0 height=60 width=113>
</td><td>
<h1>GnuDIP Remote User Maintenance Protocol</h1>
</table>

<hr>

<p>
Here we describe the remote user maintenance protocol provided by the
<a href="gnudip/sbin/gdiprmaint.pl"><code>gdiprmaint.pl</code></a>
(X)INETD daemon, and which is used by the
<a href="gnudip/sbin/gdiprmclt.pl"><code>gdiprmclt.pl</code></a>
client script.
<p><hr>

<p>
ASCII is (of course) used for representing printable characters.

<p>
The client makes a TCP connection to the appropriate port on the server host.
There is no standard port. Each GnuDIP site should choose its own.

<p>
As soon as the connection is established the server will send a <b>randomly
generated 10 character "salt" string</b>. The manner in which this is used
depends on whether the maintenance message is sent in unencrypted or
encrypted form.

<h3>Unencrypted Form</h3>

<p>
In this case the maintenance request and response messages are not
encrypted, but the <b>remote maintenance access password</b> (a value
known both to the server and the client) is still protected.
The random salt is used in this process in a way that prevents the possibility
of "spoofing" the server by replaying requests.

<p>
The random salt sent by the server is used in the following algorithm for
hashing the password:

<ul>

<li>
Digest the remote maintenance access password using
<a href="http://www.ietf.org/rfc/rfc1321.txt">
the MD5 digest message digest algorithm</a>.
Convert the digest value (which is a <u>binary</u> value)
to its hexadecimal character string representation
(characters 0-9 and lower case a-f).

<p><li>
Append a period (".") and the salt value to create a longer character string.

<p><li>
Digest this longer character string and convert it to its hexadecimal
character representation.

</ul>

<p>
The message character string is then transmited to the GnuDIP server.
It is sent as several lines using a <b><u>single new line character as the line
ending</u></b>. The general form is:

<blockquote><pre>
0
hashed_password
maintenance_request_line_1
maintenance_request_line_2
   *
   *
maintenance_request_line_n
end
</pre></blockquote>

<p>
The response from the server will in most cases be single line containing a
response code:

<blockquote><pre>
response_code
</pre></blockquote>

<p>
For a response code of zero to a <b><code>get</code></b> request, there will
also be two or more data lines:

<blockquote><pre>
0
get_response_line_1
get_response_line_2
   *
   *
get_response_line_n
end
</pre></blockquote>

<p>
The format of maintenance requests and responses to a "get" is explained
below, along with the possible response codes.

<h3>Encrypted Form</h3>

<p>
In this case the maintenance request and response messages are both
encrypted with
<a href="http://www.counterpane.com/blowfish.html">
Blowfish encryption</a> using a key known both to the server and
the client. This random salt sent by the server is included in the encrpyted
request message to prevent the possibility of "spoofing" the server by
replaying requests.

<p>
<b>Note:</b>
<blockquote>
The Blowfish encryption option is not yet implemented.
<p>
It probably never will be either, since encryption over the public Internet
is easily done using <a href="http://www.stunnel.org/">Stunnel</a>.
</blockquote>

<p>
The encrypted request is then converted from binary form to its character
hexadecimal representation, using the digits and the <u>lower case</u> letters
"a", "b", "c", "d", "e" and "f".
The message character string is then transmited to the GnuDIP server.
It is sent as two lines using a single new line character as the line
ending. The general form is:

<blockquote><pre>
1
encrypted_message_as_hex_on_one_line
</pre></blockquote>

<p>
Before being encrypyted, the message that gets encrypted and placed in the
second line above consists of several lines using <b><u>single new line character
as the line ending</u></b>, with this form:

<blockquote><pre>
random_salt
maintenance_request_line_1
maintenance_request_line_2
   *
   *
maintenance_request_line_n
</pre></blockquote>

<p>
The response from the server will in most cases be single line containing a
response code:

<blockquote><pre>
response_code
</pre></blockquote>

<p>
For a response code of zero to a <b><code>get</code></b> request, there will
also be an encrypted data line:

<blockquote><pre>
0
encrypted_get_response_as_hex_on_one_line
</pre></blockquote>

<p>
Before being encrypyted, the get response that gets encrypted and placed in the
second line above consists of several lines using <b><u>single new line character
as the line ending</u></b>, with this form:

<blockquote><pre>
get_response_line_1
get_response_line_2
   *
   *
get_response_line_n
</pre></blockquote>

<p>
The format of maintenance requests and responses to a "get" is explained
below, along with the possible response codes.

<h3>Maintenance Requests, Response Codes and Get Responses</h3>

<p>
These requests correspond precisely at a semantic level to the user
maintenance commands described in
<a href="maintenance_commands.html">
<code>maintenance_commands.html</code></a>.

<p>
A request consists of several lines using a <b><u>single new line
character as the line ending</u></b>. The general form is:

<blockquote><pre>
command
parameter_1=value_1
parameter_2=value_2
   *
   *
parameter_n=value_n
</pre></blockquote>

<p>
The number of parameter/value pairs will vary. The "command" is one of:

<blockquote><ul>
<li><code>get</code>
<li><code>add</code>
<li><code>mod</code>
<li><code>del</code>
</ul></blockquote>

<p>
The response from to successful <b><code>get</code></b> request consists of
two or more data lines:

<blockquote><pre>
parameter_1=value_1
parameter_2=value_2
   *
   *
parameter_n=value_n
</pre></blockquote>

<p>
We now describe the exchange for each command in more detail:

<dl>

<dt><b>get</b>
<dd>

<p>
In this case the request will be of the form:
<blockquote><pre>
get
user=user_name
domain=domain_name
</pre></blockquote>

<p>
If the specified user name is registered for the specified domain, the get will
succeed and the response will be similiar to:

<blockquote><pre>
MXbackup = NO
wildcard = NO
password = 34e24c964fa7adfb317e2444a94c4357
forwardurl =
allowmx = NO
MXvalue =
autourlon =
level = USER
currentip = 127.0.0.1
username = rob
allowwild = NO
updated = 2002-05-22 14:39:07
domain = dyn.yourhost.com
email = rob@elsewhere.com
</pre></blockquote>

<p>
The response codes are:
<ul>
<li>0 - User existed - get response returned
<li>1 - User did not exist
<li>2 - Invalid request - look for GnuDIP log messages
</ul>

<p>

<dt><b>add</b>
<dd>

<p>
In this case the full message will be of the form:

<blockquote><pre>
add
user=user_name
domain=domain_name
password=clear_text_password
email=email_address
</pre></blockquote>

<p>
The "password" or "email" parameters may be omitted.

<p>
The response codes are:
<ul>
<li>0 - User did not exist - user was added
<li>1 - User already existed
<li>2 - Invalid request - look for GnuDIP log messages
</ul>

<p>

<dt><b>mod</b>
<dd>

<p>
In this case the full message will be of the form:

<blockquote><pre>
mod
user=user_name
domain=domain_name
password=clear_text_password
hashedpw=MD5_hashed_password
email=email_address
allowwild={YES|NO}
allowmx={YES|NO}
removedns=YES
</pre></blockquote>

<p>
Any of the "password", "hashedpw", "email", "allowwild", "allowmx" or
"removedns" parameters may be omitted.

<p>
The response codes are:
<ul>
<li>0 - User existed - user was updated
<li>1 - User did not exist
<li>2 - Invalid request - look for GnuDIP log messages
</ul>

<p>

<dt><b>del</b>
<dd>

<p>
In this case the full message will be of the form:

<blockquote><pre>
del
user=user_name
domain=domain_name
</pre></blockquote>

<p>
The response codes are:
<ul>
<li>0 - User existed - user was deleted
<li>1 - User did not exist
<li>2 - Invalid request - look for GnuDIP log messages
</ul>

</dl>

<p><hr>

</body>

</html>