blob: ea301bb28888e047f56a74c0c61fcc6694a5ffc6 (
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
|
description of distcc GSS-API mutual authentication
protocol
copyright (C) 2009 CERN
disclaimer
----------
This document is provided as explanation for people developing or
debugging distcc. Discrepancies between this document and the distcc
code are an error in the document.
protocol
--------
This protocol exists independently of, and occupies a logical
position beneath, all existing distcc protocols. Due to this fact it
should remain compatible with all future version of the distcc
protocol.
Mutual authentication transpires after the network connection is
established between the client and server and the clients IP address
has been evaluated, but before the client transmits a request.
control flow overview
---------------------
The overall structure of the protocol is very simple:
1: The client attempts a handshake with the server.
2: The server responds with a handshake with the client.
3: The client and server attempt to establish a secure
context using the GSS-API framework by exchanging
an unspecified number of GSS-API tokens.
4: After successfully establishing the secure context
distcc and distccd function as per the higher level
distcc protocol.
handshake
---------
A client wishing to perform mutual authentication attempts a
handshake with the server by sending an * (asterisk) character.
A mutually authenticating server responds by sending back an
* (asterisk) character.
GSS-API context and tokens
---------------------------
Applications utilising the GSS-API are required to exchange tokens,
tokens are opaque to applications and consist of the length of the
token, and the token data itself.
distcc and distccd now exchange context-level tokens when
establishing a secure context. The underlying mechanism can
require several token exchanges before a secure context is
established.
When transmitting tokens to the peer both distcc and distccd
first transmit the token length, followed by the token itself,
as per the following packet specification.
TLEN <len> <bytes>
Non-authenticating clients and authenticating servers
-----------------------------------------------------
An authenticating server expects the first character it receives
from the client to be the handshake character. A non-authenticating
client will not transmit this character which will cause the server
to disconnect.
Authenticating clients and non-authenticating servers
-----------------------------------------------------
An authenticating client expects to receive the handshake character
from the server. If this is not received within a predefined
time period the client will timeout, close the connection, and
try to compile locally.
|
