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
|
<html>
<body>
<h2><a href="cvm.html">CVM</a></h2>
<h2><a href="protocol-1.html">CVM Version 1 Protocol</a></h2>
<h1>CVM Version 2 Protocol</h1>
<p>The version 2 protocol was built based on lessons learned while
working with the version 1 protocol. In particular, it is impossible to
pass binary data with the version 1 protocol without escaping to avoid
NUL bytes. It is also difficult to differentiate between different
types of credentials (ie secret vs. password vs. challenge/response)
since there is no indication given in the request packet what types of
credentials are being sent. Spoofing attacks are possible against
version 1 UDP clients, since an attacker may forge valid responses with
relative ease. This second version protocol retains the efficiency of
the original protocol while correcting these deficiencies.</p>
<h2>General Packet Format</h2>
<p>Input to and output from the module follows a similar packet format:
a packet identifier byte, a length byte L, L bytes of random data (used
to help prevent spoofing of UDP responses), followed by a series of
tagged strings and completed with a single NUL (zero) byte. The total
size of either the input or the output must not exceed 512 bytes. The
random data in the response is copied exactly from the request.</p>
<p>A tagged string consists of a tag byte T, a length byte L, and L
bytes of data. The tag byte identifies what <a
href="credentials.html">credential</a> (in the input request) or what <a
href="facts.html">fact</a> (in the output response) is represented by
the data. Note that the initial random data in the packet may be viewed
as a tagged string that just differs in the tag value convention.</p>
<h2>Input</h2>
<p>The packet identifier in the input (request) packet is the protocol
version number (2). Example (all numbers are hexadecimal):</p>
<pre>
0000000: 0208 0102 0304 0506 0708 0108 7573 6572 ............user
0000010: 6e61 6d65 0209 6c6f 6361 6c68 6f73 7403 name..localhost.
0000020: 0870 6173 7377 6f72 6400 .password.
</pre>
<h2>Output</h2>
<p>The packet identifier in the output (response) packet is the <a
href="errors.html">error code</a> value, with zero representing
successful validation.</p>
<h2>Implementation Considerations</h2>
<p>The module must report a temporary error if it detects malformed
input (incorrect credentials, etc.). Extra data following the final
NUL byte in the credentials is a fault in the invoking code, and must
be rejected by the module. Similarly, extra data following the final
NUL byte in the facts is a fault in the module code.</p>
<p>All data following an unsuccessful result status code must be
ignored by the invoking code. Modules should not produce any facts
when validation fails.</p>
<p>An executable module must exit 0 if authentication succeeds.
Non-zero exit codes from an executable module should be treated as a
temporary error.</p>
<p>The invoker of an executable module must assume a temporary error
if the module either fails to completely read its input or produces
incomplete output, even if the module exits without error.</p>
</body>
</html>
|
