2 ./" * (c) Copyright 1993, 1994 Hewlett-Packard Company *
3 ./" * (c) Copyright 1993, 1994 International Business Machines Corp. *
4 ./" * (c) Copyright 1993, 1994 Sun Microsystems, Inc. *
5 ./" * (c) Copyright 1993, 1994 Novell, Inc. *
9 define oc % "\\fR{\\fP" %
10 define cc % "\\fR}\\fP" %
24 \s+2\fBX Display Manager Control Protocol\fP\s-2
30 Laboratory for Computer Science
31 Massachusetts Institute of Technology
34 Copyright \(co 1989 by the Massachusetts Institute of Technology
36 This document is for internal use by Member and Affiliate
37 organizations of the MIT X Consortium. It may be redistributed
38 internally within such organizations, provided the above copyright
39 notice and this permission notice appear in all copies, but it is not
40 to be published and it is not to be redistributed externally. MIT
41 makes no representations about the suitability for any purpose of the
42 information in this document. It is provided ``as is'' without express
43 or implied warranty. The information in this document is a
44 preliminary draft and therefore subject to change, and does not
45 represent an approved specification of the MIT X Consortium.
49 Since the X Display Manager (xdm) may be used to manage remote displays (such
50 as X terminals), a protocol for requesting service over the network is
51 needed. Since the display manager is a scarce resource, the X Display
52 Manager Control Protocol (also called XDMCP) is designed to use unreliable
53 datagrams and places the bulk of the burden for sequencing and retransmission
54 on the display. A standard byte order and synchronous responses reduces the
55 complexity of the protocol.
58 .ie o .tl 'XDMCP''X Display Manager Control Protocol '
59 .el .tl 'X Display Manager Control Protocol ''XDMCP'
68 XDMCP is designed to provide authenticated access to display management
69 services for remote displays. A new network server, called a \fBDisplay
70 Manager\fP will use XDMCP to communicate with displays to negotiate the
71 startup of X sessions. The protocol allows the display to authenticate the
72 manager. It also allows most of the configuration information to be
73 centralized with the manager, to ease the burden of system administration in
74 a large network of displays. The essential goal is to provide plug-and-play
75 services similar to those provided in the familiar mainframe/terminal world.
77 Displays may be turned off by the user at any time. Any existing session
78 running on a display which has been turned off must be identifiable. This
79 is made possible by requiring a three-way handshake to start a session. If
80 the handshake succeeds, any existing session is terminated immediately and a
81 new session started. There is the problem (at least with TCP) that
82 connections may not be closed when the display is turned off. The manager
83 could reduce this problem by periodically XSync'ing on its own connection,
84 and terminating the session if its own connection ever closes. This,
85 however, could add considerable network load in a large network.
87 Displays should not be required to retain permanent state for purposes of
88 the control protocol. One solution to packets received out of sequence
89 would be to use monotonically-increasing message identifiers in each message
90 to allow both sides to ignore messages which arrive out-of-sequence. For
91 this to work, displays would at a minimum have to increment a stable "crash
92 count" each time they are powered on, and use that number as part of a
93 larger sequence number. But if displays cannot retain permanent state this
94 cannot work. Instead, the manager assumes the responsibility for permanent
95 state by generating unique numbers which identify a particular session and
96 the protocol simply ignores packets which correspond to an invalid session.
98 The Manager must not be responsible for packet reception. To prevent the
99 Manager from becoming stuck because of a hostile display, no portion of the
100 protocol requires the Manager to retransmit a packet. Part of this means
101 that any valid packet which the Manager does receive \fImust\fP be
102 acknowledged in some way, to prevent the display from continuously resending
103 packets. The display can keep the protocol running as it will always know
104 when the Manager has received (at least one copy of) a packet. On the
105 Manager side, this means that any packet may be received more than once (if
106 the response was lost) and duplicates must be ignored.
110 XDMCP packets contain several types of data. For multi-byte integers, the
111 values are stored in ``Big Endian'' order; most significant byte first.
112 As XDMCP will not be used to transport large quantities of data, this
113 restriction will not substantially hamper the efficiency of any
114 implementation. Also, no padding of any sort will occur within the packets.
120 Type Name Length Description
122 CARD8 1 A single byte unsigned integer
123 CARD16 2 Two byte unsigned integer
124 CARD32 4 Four byte unsigned integer
125 ARRAY8 n+1 This is actually a CARD8 followed by
126 a collection of CARD8. The value of the first CARD8
127 field (n) specifies the number of CARD8 values to
129 ARRAY16 2*m+1 This is a CARD8 (m) which specifies the
130 number of CARD16 values to follow
131 ARRAY32 4*l+1 This is a CARD8 (l) which specifies the
132 number of CARD32 values to follow
133 ARRAYofARRAY8 ? This is a CARD8 which specifies the
134 number of ARRAY8 values to follow.
140 All XDMCP packets have the following information:
151 Length in Field Description of field
154 2 CARD16 version number
155 2 CARD16 opcode packet header
156 2 CARD16 n = length of remaining data in bytes
158 n ??? packet-specific data
161 The fields are as follows:
165 This specifies the version of XDMCP that generated this packet in
166 case changes in this protocol are required. Displays and
167 managers may choose to support older versions for compatibility.
168 This field will initially be 1.
173 This specifies what step of the protocol this packet represents and should
174 contain one of the following values (encoding provided in section below):
175 \f8BroadcastQuery\fP, \f8Query\fP, \f8IndirectQuery\fP, \f8ForwardQuery\fP,
176 \f8Willing\fP, \f8Unwilling\fP, \f8Request\fP, \f8Accept\fP, \f8Decline\fP,
177 \f8Manage\fP, \f8Refuse\fP, \f8Failed\fP.
180 Length of data in bytes
182 This specifies the length of the information following the first 6 bytes.
183 Each packet-type has a different format, and will need to be separately
184 length-checked against this value. As every data item has either an
185 explicit length, or an implicit length, this can be easily accomplished.
186 Packets that have too little or too much data should be ignored.
189 Packets should be checked to make sure that they satisfy the following
193 They must contain valid opcodes.
195 The length of the remaining data should correspond to the sum of the
196 lengths of the individual remaining data items.
200 should be expected (a finite state diagram is given
203 If the packet is of type \f8Manage\fP or \f8Refuse\fP, the \f7Session ID\fP
204 should match the value sent in the preceding \f8Accept\fP packet.
209 Each of the opcodes is described below. Since a given packet type is only
210 ever sent one way, each packet description below indicates the direction.
211 Most of the packets have additional information included beyond the
212 description above. The additional information is appended to the packet
213 header in the order described without padding, and the length field is
214 computed accordingly.
226 \f7Authentication Names\fP:
229 A list of authentication names which the display supports. The manager will
230 choose one of these and return it in the \f8Willing\fP packet.
235 A \f8Query\fP packet is sent from the display to a specific host to ask if
236 that host is willing to provide management services to this display. The
237 host should respond with \f8Willing\fP if it is willing to service the
238 display or \f8Unwilling\fP if it is not.
240 A \f8BroadcastQuery\fP packet is similar to the \f8Query\fP packet except
241 that it is intended to be received by all hosts on the network (or
242 sub-network). However, unlike \f8Query\fP requests, hosts that are not
243 willing to service the display should simply ignore \f8BroadcastQuery\fP
246 An \f8IndirectQuery\fP packet is sent to a well-known manager which forwards
247 the request to a larger collection of secondary managers using
248 \f8ForwardQuery\fP packets. In this way, the collection of managers which
249 respond can be grouped on other than network boundaries; the use of a
250 central manager reduces system administrative overhead. The primary manager
251 may also send a \f8Willing\fP packet in response to this packet.
253 Each packet type has slightly different semantics:
255 The \f8Query\fP packet is destined only for a single host. If the display
256 is instructed to \f8Query\fP multiple managers, it will send multiple
257 \f8Query\fP packets. The \f8Query\fP packet also demands a response from
258 the manager, either \f8Willing\fP or \f8Unwilling\fP.
260 The \f8BroadcastQuery\fP packet is sent to many hosts. Each manager which
261 receives this packet will not respond with an \f8Unwilling\fP packet.
263 The \f8IndirectQuery\fP packet is sent to only one manager, with the request
264 that the request be forwarded to a larger list of managers using
265 \f8ForwardQuery\fP packets. This list is expected to be maintained at one
266 central site to reduce administrative overhead. The function of this packet
267 type is similar to \f8BroadcastQuery\fP except that \f8BroadcastQuery\fP is
272 \f8Willing\fP, \f8Unwilling\fP
278 Not all managers receive the query packet.
283 none if \f8BroadcastQuery\fP or \f8IndirectQuery\fP was sent, else failure
284 to receive \f8Willing\fP.
288 Repeatedly send the packet while waiting for user to choose a manager.
292 Timeout/Retransmission policy:
294 An exponential backoff algorithm should be used here to reduce network load
295 for long-standing idle displays. Start at 2 seconds, back off by factors of
296 2 to 32 seconds and discontinue retransmit after 126 seconds. The display
297 should reset the timeout when user-input is detected. In this way, the
298 display will ``wakeup'' when touched by the user.
304 Primary Manager \(-> Secondary Manager
308 \f7Client Address\fP:
311 The network address of the client display.
316 An identification of the client task on the client display.
318 \f7Authentication Names\fP:
321 This is a duplicate of \f7Authentication Names\fP array which was received
322 in the \f8IndirectQuery\fP
328 When primary manager receives a \f8IndirectQuery\fP packet, it is
329 responsible for sending \f8ForwardQuery\fP packets to an appropriate list of
330 managers which can provide service to the display using the same network
331 type as the one the original \f8IndirectQuery\fP packet was received from.
332 The \f7Client Address\fP and \f7Client Port\fP fields must contain an
333 address which the secondary manager can use to reach the display also using
334 this same network. Each secondary manager sends a \f8Willing\fP packet to
335 the display if it is willing to provide service.
337 \f8ForwardQuery\fP packets are similar to \f8BroadcastQuery\fP packets in
338 that managers which are not willing to service particular displays should
339 not send a \f8Unwilling\fP packet.
347 Identical to \f8BroadcastQuery\fP
349 Timeout/Retransmission policy:
351 Like all packets sent from a manager, this packet should never be
363 \f7Authentication Name\fP:
366 This specifies the authentication method, selected from the list offered in
367 the \f8Query\fP, \f8BroadcastQuery\fP or \f8IndirectQuery\fP packet that the
368 manger expects the display to use in the subsequent \f8Request\fP packet.
369 This choice should remain as constant as feasible so that displays which
370 send multiple \f8Query\fP packets can use the \f7Authentication Name\fP from
371 any \f8Willing\fP packet which arrives.
373 The display is free to ignore managers which request an insufficient level
379 A human readable string describing the host from which the packet was sent.
380 The protocol specifies no interpretation of the data in this field.
385 A human readable string describing the ``status'' of the host. This could
386 include load average/number of users connected or other information. The
387 protocol specifies no interpretation of the data in this field.
392 A \f8Willing\fP packet is sent by managers that may service connections from
393 this display. It is sent in response to either a \f8Query\fP,
394 \f8BroadcastQuery\fP or \f8ForwardQuery\fP but does not imply a commitment
395 to provide service (e.g. it may later decide that it has accepted enough
396 connections already).
402 \f8Willing\fP not received by the display.
406 none if \f8BroadcastQuery\fP or \f8IndirectQuery\fP was sent, else failure to
407 receive \f8Willing\fP.
411 The display should continue to send the query until a response is received.
415 Timeout/Retransmission policy:
417 Like all packets sent from the manager to the display, this packet should
418 never be retransmitted.
428 The same fields as in the \f8Willing\fP packet. The \f7Status\fP field
429 should indicate to the user a reason for the refusal of service.
433 An \f8Unwilling\fP packet is sent by managers in response to direct
434 \f8Query\fP requests (as opposed to \f8BroadcastQuery\fP or
435 \f8IndirectQuery\fP requests) if the manager will not accept requests for
436 management. This is typically sent by managers that wish to only service
437 particular displays or which handle a limited number of displays at once.
443 \f8Unwilling\fP not received by the display.
447 Display fails to receive \f8Unwilling\fP.
451 The display should continue to send \f8Query\fP messages until a response is
456 Timeout/Retransmission policy:
458 Like all packets sent from the manager to the display, this packet should
459 never be retransmitted.
470 \f7Display Number\fP:
473 The index of this particular server for the host on which the display is
476 \f7Connection Types\fP:
479 An array indicating the stream services accepted by the display. If the
480 high-order byte in a particular entry is zero, the low-order byte
481 corresponds to an X-protocol host family type.
483 \f7Connection Addresses\fP:
486 For each connection type in the previous array, the corresponding entry in
487 this array indicates the network address of the display device.
489 \f7Authentication Name\fP:
492 \f7Authentication Data\fP:
495 This specifies the authentication protocol that the display expects
496 the manager to validate itself with. The Authentication Data is
497 expected to contain data which the manager will interpret, modify
498 and use to authenticate itself.
500 \f7Authorization Names\fP:
503 This array specifies which types of authorization the display supports. The
504 manager may decide to reject displays with which it cannot perform
507 \f7Manufacturer Display ID\fP:
510 This field can be used by the manager to determine how to decrypt the
511 Authentication Data field in this packet. See the section below on
512 Manufacturer Display ID Format.
517 A \f8Request\fP packet is sent by a display to a specific host to request a
518 session id in preparation for a establishing a connection. If the manager
519 is willing to service a connection to this display, it should return an
520 \f8Accept\fP packet with a valid session id and should be ready for a
521 subsequent Manage request. Otherwise, it should return a \f8Decline\fP
526 \f8Accept\fP, \f8Decline\fP
532 Request not received by manager.
536 Display timeout waiting for response.
540 Display resends \f8Request\fP message.
545 _DtMessage received out of order by manager.
553 Each time a \f8Request\fP is sent, the manager sends the \f7Session ID\fP
554 associated with the next session in the \f8Acknowledge\fP. If that next
555 session is not yet started, the manager will simply resend with the same
556 \f7Session ID\fP. If the session is in progress, the manager will reply
557 with a new \f7Session ID\fP; in which case, the \f8Acknowledge\fP will be
558 discarded by the display.
562 Timeout/Retransmission policy:
564 Timeout after 2 seconds, exponential backoff to 32 seconds. After no more
565 than 126 seconds, give up and report an error to the user.
578 This identifies the session which can be started by the manager.
580 \f7Authentication Name\fP:
583 \f7Authentication Data\fP:
586 This data is sent back to the display to authenticate the manager.
587 If the Authentication Data is not the value expected by the display, it
588 should terminate the protocol at this point and display an error to the user.
590 \f7Authorization Name\fP:
593 \f7Authorization Data\fP:
596 This data is sent to the display to indicate the type of authorization the
597 manager will be using in the first XOpenDisplay request after the
598 Manage packet is received.
603 An \f8Accept\fP packet is sent by a manager in response to a \f8Request\fP
604 packet if the manager is willing to establish a connection for the display.
605 The \f7Session ID\fP is used to identify this connection from any preceding
606 ones and will be used by the display in its subsequent \f8Manage\fP packet.
607 The \f7Session ID\fP is a 32 bit number which is incremented each time an
608 \f8Accept\fP packet is sent as it must be reasonably unique over a long
611 If the authentication information is invalid, a \f8Decline\fP packet will be
612 returned with an appropriate \f7Status\fP message.
618 \f8Accept\fP or \f8Decline\fP not received by display.
622 Display timeout waiting for response to \f8Request\fP.
626 Display resends \f8Request\fP message.
631 _DtMessage received out of order by display.
635 Display receives \f8Accept\fP after \f8Manage\fP has been sent.
639 Display discards \f8Accept\fP messages after it has sent a \f8Manage\fP
644 Timeout/Retransmission policy:
646 Like all packets sent from the manager to the display, this packet should
647 never be retransmitted.
660 This is a human readable string indicating the reason for refusal of
663 \f7Authentication Name\fP:
666 \f7Authentication Data\fP:
669 This data is sent back to the display to authenticate the manager. If the
670 \f7Authentication Data\fP is not the value expected by the display, it
671 should terminate the protocol at this point and display an error to the user.
676 A \f8Decline\fP packet is sent by a manager in response to a \f8Request\fP
677 packet if the manager is unwilling to establish a connection for the
678 display. This is allowed even if the manager had responded \f8Willing\fP to
686 Timeout/Retransmission policy:
688 Like all packets sent from a manager to a display, this packet should never
702 This field should contain the non-zero session id returned
707 \f7Display Number\fP:
710 This field must match the value sent in the previous
717 This array specifies the class of the display. Please refer to the section
718 below (Display Class Format) which discusses the format of this field.
723 A \f8Manage\fP packet is sent by a display to ask the manager to begin a
724 session on the display. If the \f7Session ID\fP is correct the manager
725 should open a connection, otherwise it should respond with a \f8Refuse\fP or
730 X connection with correct auth info,
739 not received by manager.
743 Display timeout waiting for response.
754 \f8Manage\fP received out of order by manager.
758 session already in progress.
762 \f8Refuse\fP message is sent.
766 \f7Session ID\fP doesn't match next \f7Session ID\fP
770 \f8Refuse\fP message is sent.
775 Display cannot be opened on selected stream.
783 \f8Failed\fP message is sent including a human readable reason.
787 Timeout/Retransmission policy:
789 Timeout after 2 seconds, exponential backoff to 32 seconds. After no more
790 than 126 seconds, give up and report an error to the user.
802 This field should be set to the
811 A \f8Refuse\fP packet is sent by a manager when the \f7Session ID\fP
812 received in the \f8Manage\fP packet does not match the current \f7Session
813 ID\fP. The display should assume that it received an old \f8Accept\fP
814 packet and should resend its \f8Request\fP packet.
820 Error message is lost.
824 display times out waiting for OpenDisplay, \f8Refuse\fP or \f8Failed\fP.
828 display resends \f8Manage\fP message.
832 Timeout/Retransmission policy:
834 Like all packets sent from a manager to a display, this packet should never be
840 .RS Manager \(-> Display
847 This field should be set to the \f7Session ID\fP received in the
853 A human readable string indicating the reason for failure.
858 A \f8Failed\fP packet is sent by a manager when it has problems establishing
859 the initial X connection in response to the \f8Manage\fP packet.
863 Same as for \f8Refuse\fP.
870 When the session is over, the initial connection with the display (the one
871 which ack's the \f8Manage\fP packet) will be closed by the manager. At this
872 point, all other display connections should be closed by the display and the
873 display can request another session.
877 These state diagrams are designed to cover all actions of both
878 the display and the manager. Any packet which is received out-of-sequence
887 user-requested connect to one host \(-> \f6query\fP
890 user-requested connect to some host \(-> \f6broadcast\fP
893 user-requested connect to site host-list \(-> \f6indirect\fP
899 Send \f8Query\fP packet
901 \(-> \f6collect-query\fP
907 receive \f8Willing\fP \(-> \f6start-connection\fP
910 receive \f8Unwilling\fP \(-> \f6stop-connection\fP
913 timeout \(-> \f6query\fP
919 Send \f8BroadcastQuery\fP packet
921 \(-> \f6collect-broadcast-query\fP
925 \f6collect-broadcast-query\fP:
927 receive \f8Willing\fP \(-> \f6update-broadcast-willing\fP
930 user-requested connect to one host \(-> \f6start-connection\fP
933 timeout \(-> \f6broadcast\fP
937 \f6update-broadcast-willing\fP:
939 Add new host to the host list presented to the user.
941 \(-> \f6collect-broadcast-query\fP
947 Send \f8IndirectQuery\fP packet
949 \(-> \f6collect-indirect-query\fP
953 \f6collect-indirect-query\fP:
955 receive \f8Willing\fP \(-> \f6update-indirect-willing\fP
958 user-requested connect to one host \(-> \f6start-connection\fP
961 timeout \(-> \f6indirect\fP
965 \f6update-indirect-willing\fP:
967 Add new host to the host list presented to the user.
969 \(-> \f6collect-indirect-query\fP
973 \f6start-connection\fP:
975 Send \f8Request\fP packet
977 \(-> \f6await-request-response\fP
981 \f6await-request-response\fP:
983 receive \f8Accept\fP \(-> \f6manage\fP
986 receive \f8Decline\fP \(-> \f6stop-connection\fP
989 timeout \(-> \f6start-connection\fP
995 Save \f7Session ID\fP
997 Close all existing display connections.
999 Send \f8Manage\fP packet with \f7Session ID\fP
1001 \(-> \f6await-manage-response\fP
1005 \f6await-manage-response\fP:
1007 receive XOpenDisplay: \(-> \f6run-session\fP
1010 receive \f8Refuse\fP with matching \f7Session ID\fP \(-> \f6start-connection\fP
1013 receive \f8Failed\fP with matching \f7Session ID\fP \(-> \f6stop-connection\fP
1016 timeout \(-> \f6manage\fP
1020 \f6stop-connection\fP:
1022 Display cause of termination to user
1030 await close of first display connection
1032 \(-> \f6reset-display\fP
1036 \f6reset-display\fP:
1038 close all display connections
1051 receive \f8Query\fP \(-> \f6query-respond\fP
1054 receive \f8BroadcastQuery\fP \(-> \f6broadcast-respond\fP
1057 receive \f8IndirectQuery\fP \(-> \f6indirect-respond\fP
1060 receive \f8ForwardQuery\fP \(-> \f6forward-respond\fP
1063 receive \f8Request\fP \(-> \f6request-respond\fP
1066 receive \f8Manage\fP \(-> \f6manage\fP
1069 an active session terminates \(-> \f6finish-session\fP
1076 \f6query-respond\fP:
1078 if willing to manage \(-> \f6send-willing\fP
1081 \(-> \f6send-unwilling\fP
1085 \f6broadcast-respond\fP:
1087 if willing to manage \(-> \f6send-willing\fP
1094 \f6indirect-respond\fP:
1096 Send \f8ForwardQuery\fP packets to all managers on redirect list.
1098 if willing to manage \(-> \f6send-willing\fP
1105 \f6forward-respond\fP:
1107 Decode destination address, if willing to manage \(-> \f6send-willing\fP
1116 Send \f8Willing\fP packet
1122 \f6send-unwilling\fP:
1124 Send \f8Unwilling\fP packet
1130 \f6request-respond\fP:
1132 if manager is willing to allow a session on display \(-> \f6accept-session\fP
1135 \(-> \f6decline-session\fP
1139 \f6accept-session\fP:
1141 Generate \f7Session ID\fP. Save \f7Session ID\fP, display address and
1142 display number somewhere
1144 Send \f8Accept\fP packet
1150 \f6decline-session\fP:
1152 Send \f8Decline\fP packet
1160 If \f7Session ID\fP matches saved \f7Session ID\fP \(-> \f6run-session\fP
1182 Terminate any session in progress
1186 open display succeeds \(->
1197 send \f8Failed\fP packet
1203 \f6start-session\fP:
1211 \f6finish-session\fP:
1223 The version number in all packets will be 1.
1225 Packet opcodes are 16 bit integers.
1230 Packet Name Encoding
1247 Per packet information follows:
1251 \f8BroadcastQuery\fP
1255 These packets are identical except for the opcode field.
1259 Length Type Description
1261 2 CARD16 version number (always 1)
1262 2 CARD16 opcode (always \f8Query\fP, \f8BroadcastQuery\fP or \f8IndirectQuery\fP)
1264 1 CARD8 number of \f7Authentication Names\fP sent (m)
1265 1 CARD8 length of first \f7Authentication Name\fP (m\d\s-21\s+2\u)
1266 m\d\s-21\s+2\u CARD8 first \f7Authentication Name\fP
1267 \&... Other \f7Authentication Names\fP
1276 Length Type Description
1278 2 CARD16 version number (always 1)
1279 2 CARD16 opcode (always \f8ForwardQuery\fP)
1281 1 CARD8 length of \f7Client Address\fP (m)
1282 m CARD8 \f7Client Address\fP
1283 1 CARD8 length of \f7Client Port\fP (n)
1284 n CARD8 \f7Client Port\fP
1285 1 CARD8 number of \f7Authentication Names\fP sent (o)
1286 1 CARD8 length of first \f7Authentication Name\fP (o\d\s-21\s+2\u)
1287 o\d\s-21\s+2\u CARD8 first \f7Authentication Name\fP
1288 \&... Other \f7Authentication Names\fP
1297 Length Type Description
1299 2 CARD16 version number (always 1)
1300 2 CARD16 opcode (always \f8Willing\fP
1301 2 CARD16 length (2 + m + n + o)
1302 1 CARD8 Length of \f7Authentication Name\fP (m)
1303 m CARD8 \f7Authentication Name\fP
1304 1 CARD8 \f7Hostname\fP length (n)
1305 n CARD8 \f7Hostname\fP
1306 1 CARD8 \f7Status\fP length (o)
1307 o CARD8 \f7Status\fP
1316 Length Type Description
1318 2 CARD16 version number (always 1)
1319 2 CARD16 opcode (always \f8Unwilling\fP)
1320 2 CARD16 length (2 + m + n)
1321 1 CARD8 \f7Hostname\fP length (m)
1322 m CARD8 \f7Hostname\fP
1323 1 CARD8 \f7Status\fP length (n)
1324 n CARD8 \f7Status\fP
1333 Length Type Description
1335 2 CARD16 version number (always 1)
1336 2 CARD16 opcode (always \f8Request\fP)
1338 2 CARD16 \f7Display Number\fP
1339 1 CARD8 Count of \f7Connection Types\fP (m)
1340 2 \(mu m CARD16 \f7Connection Types\fP
1341 1 CARD8 Count of \f7Connection Addresses\fP (n)
1342 1 CARD8 Length of first \f7Connection Address\fP (n\s-2\d1\u\s+2)
1343 n\s-2\d1\u\s+2 CARD8 First \f7Connection Address\fP
1344 \&... Other connection addresses
1345 1 CARD8 Length of \f7Authentication Name\fP (o)
1346 o CARD8 \f7Authentication Name\fP
1347 1 CARD8 Length of \f7Authentication Data\fP (p)
1348 p CARD8 \f7Authentication Data\fP
1349 1 CARD8 Length of \f7Manufacturer Display ID\fP (q)
1350 q CARD8 \f7Manufacturer Display ID\fP
1359 Length Type Description
1361 2 CARD16 version number (always 1)
1362 2 CARD16 opcode (always \f8Accept\fP)
1363 2 CARD16 length (8 + n + m + o + p)
1364 4 CARD32 \f7Session ID\fP
1365 1 CARD8 Length of \f7Authentication Name\fP (n)
1366 n CARD8 \f7Authentication Name\fP
1367 1 CARD8 Length of \f7Authentication Data\fP (m)
1368 m CARD8 \f7Authentication Data\fP
1369 1 CARD8 Length of \f7Authorization Name\fP (o)
1370 o CARD8 \f7Authorization Name\fP
1371 1 CARD8 Length of \f7Authorization Data\fP (p)
1372 p CARD8 \f7Authorization Data\fP
1381 Length Type Description
1383 2 CARD16 version number (always 1)
1384 2 CARD16 opcode (always \f8Decline\fP)
1385 2 CARD16 length (3 + m + n + o)
1386 1 CARD8 Length of \f7Status\fP (m)
1387 m CARD8 \f7Status\fP
1388 1 CARD8 Length of \f7Authentication Name\fP (n)
1389 n CARD8 \f7Authentication Name\fP
1390 1 CARD8 Length of \f7Authentication Data\fP (o)
1391 o CARD8 \f7Authentication Data\fP
1400 Length Type Description
1402 2 CARD16 version number (always 1)
1403 2 CARD16 opcode (always \f8Manage\fP)
1404 2 CARD16 length (9 + m)
1405 4 CARD32 \f7Session ID\fP
1406 4 CARD32 \f7Display Number\fP
1407 1 CARD8 Length of \f7Display Class\fP (m)
1408 m CARD8 \f7Display Class\fP
1417 Length Type Description
1419 2 CARD16 version number (always 1)
1420 2 CARD16 opcode (always \f8Refuse\fP)
1422 4 CARD32 \f7Session ID\fP
1431 Length Type Description
1433 2 CARD16 version number (always 1)
1434 2 CARD16 opcode (always \f8Failed\fP)
1435 2 CARD16 length (5 + m)
1436 4 CARD32 \f7Session ID\fP
1437 1 CARD8 Length of \f7Status\fP (m)
1438 m CARD8 \f7Status\fP
1442 Display Class Format
1446 packet field is used by the display manager to collect common sorts of
1447 displays into manageable groups. This field is a string encoded of
1448 ISO-LATIN-1 characters in the following format:
1452 ManufacturerID-ModelNumber
1456 Both elements of this string must exclude characters of the set { \fB-\fP,
1457 \&\fB.\fP, \fB:\fP, \fB*\fP, \fB?\fP, \fI<space>\fP }. The ManufacturerID is a
1458 string which should be registered with the X Consortium. The ModelNumber is
1459 designed to identify characteristics of the display within the manufacturer's
1460 product line. This string should be documented in the users manual for the
1461 particular device. This string should probably not be specifiable by the
1462 display user to avoid unexpected configuration errors.
1464 Manufacturer Display ID Format
1466 To authenticate the manager, the display and manager will share a private
1467 key. The manager, then, must be able to discover which key to use for a
1468 particular device. The
1469 \f7Manufacturer Display ID\fP
1470 field is intended for this purpose. Typically, the manager host will
1471 contain a map between this number and the key. This field is intended to be
1472 unique per display, possibly the ethernet address of the display in the form:
1476 -Ethernet-8:0:2b:a:f:d2
1484 ManufacturerID-ModelNumber-SerialNumber
1487 where ManufacturerID, ModelNumber and SerialNumber are encoded using
1488 ISO-LATIN-1 characters, excluding { \fB-\fP,
1489 \&\fB.\fP, \fB*\fP, \fB?\fP, \fI<space>\fP }
1491 When the display is shipped to a customer, it should include both the
1492 \f7Manufacturer Display ID\fP
1493 and the private key in the documentation set. This information should not
1494 be modifiable by the display user.
1498 In an environment where authentication is not needed, XDMCP can disable
1499 authentication by having the display send empty \f7Authentication Name\fP
1500 and \f7Authentication Data\fP fields in the \f8Request\fP packet. In this
1501 case, the manager will not attempt to authenticate itself. Other
1502 authentication protocols may be developed, depending on local needs.
1504 In an unsecure environment, the display must be able to verify that the
1505 source of the various packets is a trusted manager. These packets will
1506 contain authentication information. As an example of such a system, the
1507 following discussion describes the "XDM-AUTHENTICATION-1" authentication
1508 system. This system uses a 56 bit shared private key, and 64 bits of
1509 authentication data. An associated example X authorization protocol
1510 "XDM-AUTHORIZATION-1" will also be discussed.
1514 The display and manager share a private key. This key could be programmed
1515 into the display by the manufacturer and shipped with the unit. It must not
1516 be available from the display itself, but should allow the value to be
1517 modified in some way. The system administrator would be responsible for
1518 managing a database of terminal keys.
1520 The display can generate random authentication numbers.
1522 Some definitions first:
1524 oc D cc sup kappa mark = "encryption of plain text " D " by key " kappa
1527 oc DELTA cc * sup kappa lineup = "decryption of crypto text " DELTA " with key " kappa
1530 { tau } lineup = "private key shared by display and manager"
1533 rho lineup = "64 bit random number generated by display"
1536 alpha lineup = "authentication data in XDMCP packets"
1539 sigma lineup = "per-session private key, generated by manager"
1542 beta lineup = "authorization data"
1545 Encryption will use the DES; blocks shorter than 64 bits will be zero-filled
1546 on the right to 64 bits. Blocks longer than 64 bits will use block chaining:
1548 oc { D } cc sup kappa lineup = oc { D sub 1 } cc sup kappa " "
1549 oc { D sub 2 } " " xor " " oc { D sub 1 } cc sup kappa cc sup kappa
1552 The display generates the first authentication data in the
1556 alpha sub roman Request mark = oc rho cc sup tau
1561 packet, the manager decrypts the initial message and returns
1562 @alpha sub roman Accept@:
1564 rho lineup = oc alpha sub roman Request cc * sup tau
1567 alpha sub roman Accept lineup = oc rho + 1 cc sup tau
1570 The \f8Accept\fP packet also contains the authorization intended for use by
1571 the X server. A description of authorization type ``XDM-AUTHORIZATION-1''
1574 The \f8Accept\fP packet contains the authorization name
1575 ``XDM-AUTHORIZATION-1''. The authorization data is the string:
1577 beta sub Accept mark = oc sigma cc sup tau
1580 To create authorization information for connection setup with the X server
1581 using the XDM-AUTHORIZATION-1 authorization protocol, the client computes the
1584 A mark = "X client host address (32 bits)"
1587 P lineup = "X client ``uniquifier''. Typically socket port id (16 bits)"
1590 T lineup = "Current time in seconds on client host (32 bits)"
1593 beta lineup = oc rho A P T cc sup sigma
1596 The result is 192 bits of authorization data, which is sent in the
1597 connection setup to the server. The server receives the packet, decrypts
1598 the contents. To accept the connection, the following must hold:
1600 @rho@ must match the value generated for the most recent XDMCP negotiation.
1602 @T@ must be within 1200 seconds of the internally stored time. If no time
1603 been received before, the current time is set to @T@.
1605 No packet containing the same triple (@A@, @P@, @T@) may have been received
1606 in the last 1200 seconds (20 minutes).
projects / oweals / cde.git / blob