delim @@ define oc % "\fR{\fP" % define cc % "\fR}\fP" %
[1mX Display Manager Control Protocol[0m
[1mVersion 1.0[0m
[1mX Consortium Standard[0m
[1mX Version 11, Release 6.4[0m
Keith Packard
X Consortium
Laboratory for Computer Science
Massachusetts Institute of Technology
Copyright (C) 1989 X Consortium
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documenta-
tion files (the ``Software''), to deal in the Software with-
out restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to
whom the Software is furnished to do so, subject to the fol-
lowing conditions:
The above copyright notice and this permission notice shall
be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PUR-
POSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSOR-
TIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of the X Con-
sortium shall not be used in advertising or otherwise to
promote the sale, use or other dealings in this Software
without prior written authorization from the X Consortium.
[4mX[24m [4mWindow[24m [4mSystem[24m is a trademark of X Consortium, Inc.
XDMCP X Display Manager Control Protocol
[1m1. Purpose and Goals[0m
The purpose of the X Display Manager Control Protocol
(XDMCP) is to provide a uniform mechanism for an autonomous
display to request login service from a remote host. By
autonomous, we mean the display consists of hardware and
processes that are independent of any particular host where
login service is desired. (For example, the server cannot
simply be started by a sequence on the host.) An X terminal
(screen, keyboard, mouse, processor, network interface) is a
prime example of an autonomous display.
From the point of view of the end user, it is very important
to make autonomous displays as easy to use as traditional
hardwired character terminals. Specifically, you can typi-
cally just power on a hardwired terminal and be greeted with
a login prompt. The same should be possible with autonomous
displays. However, in a network environment with multiple
hosts, the end user may want to choose which host(s) to con-
nect to. In an environment with many displays and many
hosts, a site administrator may want to associate particular
collections of hosts with particular displays. We would
like to support the following options:
+o The display has a single, fixed host to which it should
connect. It should be possible to power on the display
and receive a login prompt, without user intervention.
+o Any one of several hosts on a network or subnetwork may
be acceptable for accepting login from the display.
(For example, the user's file systems can be mounted
onto any such host, providing comparable environments.)
It should be possible for the display to broadcast to
find such hosts and to have the display either automat-
ically choose a host or present the possible hosts to
the user for selection.
+o The display has a fixed set of hosts that it can con-
nect to. It should be possible for the display to have
that set stored in RAM, but it should also be possible
for a site administrator to be able to maintain host
sets for a large number of displays using a centralized
facility, without having to interact (physically or
electronically) with each individual display. Particu-
lar hosts should be allowed to refuse login service,
based on whatever local criteria are desired.
The control protocol should be designed in such a way that
it can be used over a reasonable variety of communication
transport layers. In fact, it is quite desirable if every
major network protocol family that supports the standard X
protocol is also capable of supporting XDMCP, because the
end result of XDMCP negotiation will be standard X protocol
connections to the display. However, because the number of
[1m1[0m
X Display Manager Control Protocol XDMCP
displays per host may be large, a connection-based protocol
appears less desirable than a connection-less protocol. For
this reason the protocol is designed to use datagram ser-
vices with the display responsible for sequencing and
retransmission.
To keep the burden on displays at a minimum (because display
cost is not a factor that can be ignored), it is desirable
that displays not be required to maintain permanent state
(across power cycles) for the purposes of the control proto-
col, and it is desirable to keep required state at a minimum
while the display is powered on.
Security is an important consideration and must be an inte-
gral part of the design. The important security goals in
the context of XDMCP are:
+o It should be possible for the display to verify that it
is communicating with a legitimate host login service.
Because the user will present credentials (for example,
password) to this service, it is important to avoid
spoof attacks.
+o It should be possible for the display and the login
service to negotiate the authorization mechanism to be
used for the standard X protocol.
+o It should be possible to provide the same level of
security in verifying the login service as is provided
by the negotiated authorization mechanism.
+o Because there are no firm standards yet in the area of
security, XDMCP must be flexible enough to accomodate a
variety of security mechanisms.
[1m2. Overview of the Protocol[0m
XDMCP is designed to provide authenticated access to display
management services for remote displays. A new network
server, called a [4mDisplay[24m [4mManager[24m, will use XDMCP to communi-
cate with displays to negotiate the startup of X sessions.
The protocol allows the display to authenticate the manager.
It also allows most of the configuration information to be
centralized with the manager and to ease the burden of sys-
tem administration in a large network of displays. The
essential goal is to provide plug-and-play services similar
to those provided in the familiar mainframe/terminal world.
Displays may be turned off by the user at any time. Any
existing session running on a display that has been turned
off must be identifiable. This is made possible by requir-
ing a three-way handshake to start a session. If the hand-
shake succeeds, any existing session is terminated immedi-
ately and a new session started. There is the problem (at
[1m2[0m
XDMCP X Display Manager Control Protocol
least with TCP) that connections may not be closed when the
display is turned off. In most environments, the manager
should reduce this problem by periodically XSync'ing on its
own connection, perhaps every five to ten minutes, and ter-
minating the session if its own connection ever closes.
Displays should not be required to retain permanent state
for purposes of the control protocol. One solution to pack-
ets received out of sequence would be to use monotonically
increasing message identifiers in each message to allow both
sides to ignore messages that arrive out-of-sequence. For
this to work, displays would at a minimum have to increment
a stable crash count each time they are powered on and use
that number as part of a larger sequence number. But if
displays cannot retain permanent state this cannot work.
Instead, the manager assumes the responsibility for perma-
nent state by generating unique numbers that identify a par-
ticular session and the protocol simply ignores packets that
correspond to an invalid session.
The Manager must not be responsible for packet reception.
To prevent the Manager from becoming stuck because of a hos-
tile display, no portion of the protocol requires the Man-
ager to retransmit a packet. Part of this means that any
valid packet that the Manager does receive must be acknowl-
edged in some way to prevent the display from continuously
resending packets. The display can keep the protocol run-
ning as it will always know when the Manager has received
(at least one copy of) a packet. On the Manager side, this
means that any packet may be received more than once (if the
response was lost) and duplicates must be ignored.
[1m3. Data Types[0m
XDMCP packets contain several types of data. Integer values
are always stored most significant byte first in the packet
(``Big Endian'' order). As XDMCP will not be used to trans-
port large quantities of data, this restriction will not
substantially hamper the efficiency of any implementation.
Also, no padding of any sort will occur within the packets.
lw(1.25i) lw(.75i) lw(3.5i). _
[1mType Name Length (Bytes) Description[0m
[1m_[0m
CARD8 1 A single byte unsigned integer
CARD16 2 Two byte unsigned integer CARD32 4 Four
byte unsigned integer ARRAY8 n+2 This is actually a
CARD16 followed by a collection of CARD8. The
value of the CARD16 field (n) specifies the number
of CARD8 values to follow ARRAY16 2*m+1 This
is a CARD8 (m) which specifies the number of
CARD16 values to follow ARRAY32 4*l+1 This is a CARD8
(l) which specifies the number of CARD32 values to
follow ARRAYofARRAY8 ? This is a CARD8 which specifies
[1m3[0m
X Display Manager Control Protocol XDMCP
lw(1.25i) lw(.75i) lw(3.5i). _
[1mType Name Length (Bytes) Description[0m
[1m_[0m
the number of ARRAY8 values to follow.
_
[1m4. Packet Format[0m
All XDMCP packets have the following information:
lw(1.25i) lw(.75i) lw(3.5i). _
[1mLength (Bytes) Field Type Description[0m
[1m_ [22m2 CARD16 version number 2 CARD16 opcode packet
header 2 CARD16 n = length of remaining data in bytes
n ??? packet-specific data
_
The fields are as follows:
+o Version number
This specifies the version of XDMCP that generated this
packet in case changes in this protocol are required.
Displays and managers may choose to support older ver-
sions for compatibility. This field will initially be
one (1).
+o Opcode
This specifies what step of the protocol this packet
represents and should contain one of the following val-
ues (encoding provided in section below): or
+o Length of data in bytes
This specifies the length of the information following
the first 6 bytes. Each packet-type has a different
format and will need to be separately length-checked
against this value. Because every data item has either
an explicit or implicit length, this can be easily
accomplished. Packets that have too little or too much
data should be ignored.
Packets should be checked to make sure that they satisfy the
following conditions:
1. They must contain valid opcodes.
2. The length of the remaining data should correspond to
the sum of the lengths of the individual remaining data
items.
[1m4[0m
XDMCP X Display Manager Control Protocol
3. The opcode should be expected (a finite state diagram
is given in a later section).
4. If the packet is of type or the Session ID should match
the value sent in the preceding packet.
[1m5. Protocol[0m
Each of the opcodes is described below. Because a given
packet type is only ever sent one way, each packet descrip-
tion below indicates the direction. Most of the packets
have additional information included beyond the description
above. The additional information is appended to the packet
header in the order described without padding, and the
length field is computed accordingly.
Display -> Manager
Additional Fields:
[4mAuthentication[24m [4mNames[24m: ARRAYofARRAY8
Specifies a list of authentication names that
the display supports. The manager will
choose one of these and return it in the
packet.
Semantics:
A packet is sent from the display to a specific
host to ask if that host is willing to provide
management services to this display. The host
should respond with if it is willing to service
the display or if it is not.
A packet is similar to the packet except that it
is intended to be received by all hosts on the
network (or subnetwork). However, unlike
requests, hosts that are not willing to service
the display should simply ignore requests.
An packet is sent to a well known manager that
forwards the request to a larger collection of
secondary managers using packets. In this way,
the collection of managers that respond can be
grouped on other than network boundaries; the use
of a central manager reduces system administrative
overhead. The primary manager may also send a
packet in response to this packet.
Each packet type has slightly different semantics:
+o The packet is destined only for a single
host. If the display is instructed to multi-
ple managers, it will send multiple packets.
The packet also demands a response from the
manager, either or
[1m5[0m
X Display Manager Control Protocol XDMCP
+o The packet is sent to many hosts. Each man-
ager that receives this packet will not
respond with an packet.
+o The packet is sent to only one manager with
the request that the request be forwarded to
a larger list of managers using packets.
This list is expected to be maintained at one
central site to reduce administrative over-
head. The function of this packet type is
similar to is not forwarded.
Valid Responses:
Problems/Solutions:
Problem:
Not all managers receive the query packet.
Indication:
None if or was sent, else failure to
receive
Solution:
Repeatedly send the packet while waiting
for user to choose a manager.
Timeout/Retransmission policy:
An exponential backoff algorithm should be used
here to reduce network load for long-standing idle
displays. Start at 2 seconds, back off by factors
of 2 to 32 seconds, and discontinue retransmit
after 126 seconds. The display should reset the
timeout when user-input is detected. In this way,
the display will wakeup when touched by the user.
Primary Manager -> Secondary Manager
Additional Fields:
[4mClient[24m [4mAddress[24m: ARRAY8
Specifies the network address of the client
display.
[4mClient[24m [4mPort[24m: ARRAY8
Specifies an identification of the client
task on the client display.
[4mAuthentication[24m [4mNames[24m: ARRAYofARRAY8
Is a duplicate of Authentication Names array
that was received in the packet.
Semantics:
When primary manager receives a packet, it is
responsible for sending packets to an appropriate
list of managers that can provide service to the
display using the same network type as the one the
original packet was received from. The Client
Address and Client Port fields must contain an
address that the secondary manager can use to
reach the display also using this same network.
Each secondary manager sends a packet to the dis-
play if it is willing to provide service.
[1m6[0m
XDMCP X Display Manager Control Protocol
packets are similar to packets in that managers
that are not willing to service particular dis-
plays should not send a packet.
Valid Responses:
Problems/Solutions:
Identical to
Timeout/Retransmission policy:
Like all packets sent from a manager, this packet
should never be retransmitted.
Manager -> Display
Additional Fields:
[4mAuthentication[24m [4mName[24m: ARRAY8
Specifies the authentication method, selected
from the list offered in the or packet that
the manger expects the display to use in the
subsequent packet. This choice should remain
as constant as feasible so that displays that
send multiple packets can use the Authentica-
tion Name from any packet that arrives.
The display is free to ignore managers that
request an insufficient level of authentica-
tion.
[4mHostname[24m: ARRAY8
Is a human readable string describing the
host from which the packet was sent. The
protocol specifies no interpretation of the
data in this field.
[4mStatus[24m: ARRAY8
Is a human readable string describing the
status of the host. This could include load
average/number of users connected or other
information. The protocol specifies no
interpretation of the data in this field.
Semantics:
A packet is sent by managers that may service con-
nections from this display. It is sent in
response to either a or but does not imply a com-
mitment to provide service (for example, it may
later decide that it has accepted enough connec-
tions already).
Problems/Solutions:
Problem:
not received by the display.
Indication:
None if or was sent, else failure to
receive
Solution:
The display should continue to send the
query until a response is received.
Timeout/Retransmission policy:
Like all packets sent from the manager to the dis-
play, this packet should never be retransmitted.
[1m7[0m
X Display Manager Control Protocol XDMCP
Manager -> Display
Additional Fields:
The Hostname and Status fields as in the packet.
The Status field should indicate to the user a
reason for the refusal of service.
Semantics:
An packet is sent by managers in response to
direct requests (as opposed to or requests) if the
manager will not accept requests for management.
This is typically sent by managers that wish to
only service particular displays or that handle a
limited number of displays at once.
Problems/Solutions:
Problem:
not received by the display.
Indication:
Display fails to receive
Solution:
The display should continue to send mes-
sages until a response is received.
Timeout/Retransmission policy:
Like all packets sent from the manager to the dis-
play, this packet should never be retransmitted.
Display -> Manager
Additional Fields:
[4mDisplay[24m [4mNumber[24m: CARD16
Specifies the index of this particular server
for the host on which the display is resi-
dent. This value will be zero for most
autonomous displays.
[4mConnection[24m [4mTypes[24m: ARRAY16
Specifies an array indicating the stream ser-
vices accepted by the display. If the high-
order byte in a particular entry is zero, the
low-order byte corresponds to an X-protocol
host family type.
[4mConnection[24m [4mAddresses[24m: ARRAYofARRAY8
For each connection type in the previous
array, the corresponding entry in this array
indicates the network address of the display
device.
[4mAuthentication[24m [4mName[24m: ARRAY8
[4mAuthentication[24m [4mData[24m: ARRAY8
Specifies the authentication protocol that
the display expects the manager to validate
itself with. The Authentication Data is
expected to contain data that the manager
will interpret, modify and use to authenti-
cate itself.
[4mAuthorization[24m [4mNames[24m: ARRAYofARRAY8
Specifies which types of authorization the
display supports. The manager may decide to
reject displays with which it cannot perform
[1m8[0m
XDMCP X Display Manager Control Protocol
authorization.
[4mManufacturer[24m [4mDisplay[24m [4mID[24m: ARRAY8
Can be used by the manager to determine how
to decrypt the Authentication Data field in
this packet. See the section below on Manu-
facturer Display ID Format.
Semantics:
A packet is sent by a display to a specific host
to request a session ID in preparation for a
establishing a connection. If the manager is
willing to service a connection to this display,
it should return an packet with a valid session ID
and should be ready for a subsequent request.
Otherwise, it should return a packet.
Valid Responses:
Problems/Solutions:
Problem:
Request not received by manager.
Indication:
Display timeout waiting for response.
Solution:
Display resends message.
Problem:
Message received out of order by manager.
Indication:
None.
Solution:
Each time a is sent, the manager sends
the Session ID associated with the next
session in the If that next session is
not yet started, the manager will simply
resend with the same Session ID. If the
session is in progress, the manager will
reply with a new Session ID; in which
case, the will be discarded by the dis-
play.
Timeout/Retransmission policy:
Timeout after 2 seconds, exponential backoff to 32
seconds. After no more than 126 seconds, give up
and report an error to the user.
Manager -> Display
Additional Fields:
[4mSession[24m [4mID[24m: CARD32
Identifies the session that can be started by
the manager.
[4mAuthentication[24m [4mName[24m: ARRAY8
[4mAuthentication[24m [4mData[24m: ARRAY8
Is the data sent back to the display to
authenticate the manager. If the Authentica-
tion Data is not the value expected by the
display, it should terminate the protocol at
this point and display an error to the user.
[4mAuthorization[24m [4mName[24m: ARRAY8
[1m9[0m
X Display Manager Control Protocol XDMCP
[4mAuthorization[24m [4mData[24m: ARRAY8
Is the data sent to the display to indicate
the type of authorization the manager will be
using in the first call to after the packet
is received.
Semantics:
An packet is sent by a manager in response to a
packet if the manager is willing to establish a
connection for the display. The Session ID is
used to identify this connection from any preced-
ing ones and will be used by the display in its
subsequent packet. The Session ID is a 32-bit
number that is incremented each time an packet is
sent as it must be unique over a reasonably long
period of time.
If the authentication information is invalid, a
packet will be returned with an appropriate mes-
sage.
Problems/Solutions:
Problem:
or not received by display.
Indication:
Display timeout waiting for response to
Solution:
Display resends message.
Problem:
Message received out of order by display.
Indication:
Display receives after has been sent.
Solution:
Display discards messages after it has
sent a message.
Timeout/Retransmission policy:
Like all packets sent from the manager to the dis-
play, this packet should never be retransmitted.
Manager -> Display
Additional Fields:
[4mStatus[24m: ARRAY8
Is a human readable string indicating the
reason for refusal of service.
[4mAuthentication[24m [4mName[24m: ARRAY8
[4mAuthentication[24m [4mData[24m: ARRAY8
Is the data sent back to the display to
authenticate the manager. If the Authentica-
tion Data is not the value expected by the
display, it should terminate the protocol at
this point and display an error to the user.
Semantics:
A packet is sent by a manager in response to a
packet if the manager is unwilling to establish a
connection for the display. This is allowed even
if the manager had responded to a previous query.
[1m10[0m
XDMCP X Display Manager Control Protocol
Problems/Solutions:
Same as for
Timeout/Retransmission policy:
Like all packets sent from a manager to a display,
this packet should never be retransmitted.
Display -> Manager
Additional Fields:
[4mSession[24m [4mID[24m: CARD32
Should contain the nonzero session ID
returned in the packet.
[4mDisplay[24m [4mNumber[24m: CARD16
Must match the value sent in the previous
packet.
[4mDisplay[24m [4mClass[24m: ARRAY8
Specifies the class of the display. See the
Display Class Format section, which discusses
the format of this field.
Semantics:
A packet is sent by a display to ask the manager
to begin a session on the display. If the Session
ID is correct the manager should open a connec-
tion; otherwise, it should respond with a or
packet, unless the Session ID matches a currently
running session or a session that has not yet suc-
cessfully opened the display but has not given up
the attempt. In this latter case, the packet
should be ignored. This will work as stream con-
nections give positive success indication to both
halves of the stream, and positive failure indica-
tion to the connection initiator (which will even-
tually generate a packet).
Valid Responses:
X connection with correct auth info,
Problems/Solutions:
Problem:
not received by manager.
Indication:
Display timeout waiting for response.
Solution:
Display resends message.
Problem:
received out of order by manager.
Indication:
Session already in progress with match-
ing Session ID.
Solution:
packet ignored.
Indication:
Session ID does not match next Session
ID.
Solution:
message is sent.
Problem:
[1m11[0m
X Display Manager Control Protocol XDMCP
Display cannot be opened on selected stream.
Indication:
Display connection setup fails.
Solution:
message is sent including a human read-
able reason.
Problem:
Display open does not succeed before a second
manage packet is received because of a time-
out occuring in the display.
Indication:
packet received with Session ID matching
the session attempting to connect to the
display.
Solution:
packet is ignored. As the stream con-
nection will either succeed, which will
result in an active session, or the
stream will eventually give up hope of
connecting and send a packet; no
response to this packet is necessary.
Timeout/Retransmission policy:
Timeout after 2 seconds, exponential backoff to 32
seconds. After no more than 126 seconds, give up
and report an error to the user.
Manager -> Display
Additional Fields:
[4mSession[24m [4mID[24m: CARD32
Should be set to the Session ID received in
the packet.
Semantics:
A packet is sent by a manager when the Session ID
received in the packet does not match the current
Session ID. The display should assume that it
received an old packet and should resend its
packet.
Problems/Solutions:
Problem:
Error message is lost.
Indication:
Display times out waiting for new con-
nection, or
Solution:
Display resends message.
Timeout/Retransmission policy:
Like all packets sent from a manager to a display,
this packet should never be retransmitted.
Manager -> Display
Additional Fields:
[4mSession[24m [4mID[24m: CARD32
Should be set to the Session ID received in
the packet.
[1m12[0m
XDMCP X Display Manager Control Protocol
[4mStatus[24m: ARRAY8
Is a human readable string indicating the
reason for failure.
Semantics:
A packet is sent by a manager when it has problems
establishing the initial X connection in response
to the packet.
Problems/Solutions
Same as for
Display -> Manager
Additional Fields:
[4mDisplay[24m [4mNumber[24m: CARD16
Set to the display index for the display
host.
[4mSession[24m [4mID[24m: CARD32
Should be set to the Session ID received in
the packet during the negotiation for the
current session.
Sematics:
A packet can be sent at any time during the ses-
sion by a display to discover if the manager is
running. The manager should respond with whenever
it receives this type of packet.
This allows the display to discover when the man-
ager host is no longer running. A display is not
required to send packets and, upon lack of receipt
of packets, is not required to perform any spe-
cific action.
The expected use of this packet is to terminate an
active session when the manager host or network
link fails. The display should keep track of the
time since any packet has been received from the
manager host and use packets when a substantial
time has elapsed since the most recent packet.
Valid Responses:
Problems/Solutions:
Problem:
Manager does not receive the packet or dis-
play does not receive the response.
Indication:
No packet is returned.
Solution:
Retransmit the packet with an exponen-
tial backoff; start at 2 seconds and
assume the host is not up after no less
than 30 seconds.
Manager -> Display
Additional Fields:
[4mSession[24m [4mRunning[24m: CARD8
Indicates that the session identified by
[1m13[0m
X Display Manager Control Protocol XDMCP
Session ID is currently active. The value is
zero if no session is active or one if a ses-
sion is active.
[4mSession[24m [4mID[24m: CARD32
Specifies the ID of the currently running
session; if any. When no session is active
this field should be zero.
Semantics:
An packet is sent in response to a request. If a
session is currently active on the display, the
manager includes the Session ID in the packet.
The display can use this information to determine
the status of the manager.
[1m6. Session Termination[0m
When the session is over, the initial connection with the
display (the one that acknowledges the packet) will be
closed by the manager. If only a single session was active
on the display, all other connections should be closed by
the display and the display should be reset. If multiple
sessions are active simultaneously and the display can iden-
tify which connections belong to the terminated sesssion,
those connections should be closed. Otherwise, all connec-
tions should be closed and the display reset only when all
sessions have been terminated (that is, all initial connec-
tions closed).
The session may also be terminated at any time by the dis-
play if the managing host no longer responds to packets.
The exact time-outs for sending packets is not specified in
this protocol as the trade off should not be fixed between
loading an otherwise idle system with spurious packets and
not noticing that the manager host is down for a long time.
[1m7. State Diagrams[0m
The following state diagrams are designed to cover all
actions of both the display and the manager. Any packet
that is received out-of-sequence will be ignored.
Display:
[4mstart[24m:
User-requested connect to one host -> [4mquery[0m
User-requested connect to some host -> [4mbroadcast[0m
User-requested connect to site host-list -> [4mindi-[0m
[4mrect[0m
[4mquery[24m:
Send packet
-> [4mcollect-query[0m
[1m14[0m
XDMCP X Display Manager Control Protocol
[4mcollect-query[24m:
Receive -> [4mstart-connection[0m
Receive -> [4mstop-connection[0m
Timeout -> [4mquery[0m
[4mbroadcast[24m:
Send packet
-> [4mcollect-broadcast-query[0m
[4mcollect-broadcast-query[24m:
Receive -> [4mupdate-broadcast-willing[0m
User-requested connect to one host -> [4mstart-con-[0m
[4mnection[0m
Timeout -> [4mbroadcast[0m
[4mupdate-broadcast-willing[24m:
Add new host to the host list presented to the
user
-> [4mcollect-broadcast-query[0m
[4mindirect[24m:
Send packet
-> [4mcollect-indirect-query[0m
[4mcollect-indirect-query[24m:
Receive -> [4mupdate-indirect-willing[0m
User-requested connect to one host -> [4mstart-con-[0m
[4mnection[0m
Timeout -> [4mindirect[0m
[4mupdate-indirect-willing[24m:
Add new host to the host list presented to the
user
-> [4mcollect-indirect-query[0m
[4mstart-connection[24m:
Send packet
-> [4mawait-request-response[0m
[4mawait-request-response[24m:
Receive -> [4mmanage[0m
Receive -> [4mstop-connection[0m
Timeout -> [4mstart-connection[0m
[1m15[0m
X Display Manager Control Protocol XDMCP
[4mmanage[24m:
Save Session ID
Send packet with Session ID
-> [4mawait-manage-response[0m
[4mawait-manage-response[24m:
Receive -> [4mrun-session[0m
Receive with matching Session ID -> [4mstart-connec-[0m
[4mtion[0m
Receive with matching Session ID -> [4mstop-connec-[0m
[4mtion[0m
Timeout -> [4mmanage[0m
[4mstop-connection[24m:
Display cause of termination to user
-> [4mstart[0m
[4mrun-session[24m:
Decide to send packet -> [4mkeep-alive[0m
Await close of first display connection
-> [4mreset-display[0m
[4mkeep-alive[24m:
Send packet with current Session ID
-> [4mawait-alive[0m
[4mawait-alive[24m:
Receive with matching Session ID -> [4mrun-session[0m
Receive with nonmatching Session ID or FALSE Ses-
sion Running -> [4mreset-display[0m
Final timeout without receiving packet -> [4mreset-[0m
[4mdisplay[0m
Timeout -> [4mkeep-alive[0m
[4mreset-display[24m:
(if possible) -> close all display connections
associated with this session
Last session -> close all display connections
-> [4mstart[0m
Manager:
[4midle[24m:
Receive -> [4mquery-respond[0m
Receive -> [4mbroadcast-respond[0m
Receive -> [4mindirect-respond[0m
Receive -> [4mforward-respond[0m
[1m16[0m
XDMCP X Display Manager Control Protocol
Receive -> [4mrequest-respond[0m
Receive -> [4mmanage[0m
An active session terminates -> [4mfinish-session[0m
Receive -> [4msend-alive[0m
-> [4midle[0m
[4mquery-respond[24m:
If willing to manage -> [4msend-willing[0m
-> [4msend-unwilling[0m
[4mbroadcast-respond[24m:
If willing to manage -> [4msend-willing[0m
-> [4midle[0m
[4mindirect-respond[24m:
Send packets to all managers on redirect list
If willing to manage -> [4msend-willing[0m
-> [4midle[0m
[4mforward-respond[24m:
Decode destination address, if willing to manage
-> [4msend-willing[0m
-> [4midle[0m
[4msend-willing[24m:
Send packet
-> [4midle[0m
[4msend-unwilling[24m:
Send packet
-> [4midle[0m
[4mrequest-respond[24m:
If manager is willing to allow a session on dis-
play -> [4maccept-session[0m
-> [4mdecline-session[0m
[4maccept-session[24m:
Generate Session ID and save Session ID, display
address, and display number somewhere
Send packet
-> [4midle[0m
[4mdecline-session[24m:
Send packet
[1m17[0m
X Display Manager Control Protocol XDMCP
-> [4midle[0m
[4mmanage[24m:
If Session ID matches saved Session ID -> [4mrun-ses-[0m
[4msion[0m
If Session ID matches Session ID of session in
process of starting up, or currently active ses-
sion -> [4midle[0m
-> [4mrefuse[0m
[4mrefuse[24m:
Send packet
-> [4midle[0m
[4mrun-session[24m:
Terminate any session in progress
Open display succeeds -> [4mstart-session[0m
-> [4mfailed[0m
[4mfailed[24m:
Send packet
-> [4midle[0m
[4mstart-session[24m:
Start a new session
-> [4midle[0m
[4mfinish-session[24m:
-> [4midle[0m
[4msend-alive[24m:
Send packet containing current status
-> [4midle[0m
[1m8. Protocol Encoding[0m
When XDMCP is implemented on top of the Internet User Data-
gram Protocol (UDP), port number 177 is to be used. The
version number in all packets will be 1. Packet opcodes are
16-bit integers.
l l. _
[1mPacket Name Encoding[0m
[1m_[0m
T{ T} T{ 1 T} T{ T} T{ 2 T} T{ T} T{ 3 T} T{
T} T{ 4 T} T{ T} T{ 5 T} T{ T} T{ 6 T} T{ T} T{
7 T} T{ T} T{ 8 T} T{ T} T{ 9 T} T{ T} T{ 10 T}
[1m18[0m
XDMCP X Display Manager Control Protocol
T{ T} T{ 11 T} T{ T} T{ 12 T} T{ T} T{ 13 T} T{
T} T{ 14 T}
_
Per packet information follows:
2 CARD16 version number (always 1)
2 CARD16 opcode (always Query, BroadcastQuery or
IndirectQuery) 2 CARD16 length 1 CARD8 num-
ber of Authentication Names sent (m) 2 CARD16 length
of first Authentication Name (m1) m1 CARD8 first
Authentication Name ... Other Authentication
Names Note that these three packets are identical except for
the opcode field.
2 CARD16 version number (always 1)
2 CARD16 opcode (always ForwardQuery)
2 CARD16 length 2 CARD16 length of Client
Address (m) m CARD8 Client Address
2 CARD16 length of Client Port (n)
n CARD8 Client Port 1 CARD8 number of
Authentication Names sent (o) 2 CARD16 length of
first Authentication Name (o1) o1 CARD8 first
Authentication Name ... Other Authentication
Names
2 CARD16 version number (always 1)
2 CARD16 opcode (always Willing)
2 CARD16 length (6 + m + n + o)
2 CARD16 Length of Authentication Name (m)
m CARD8 Authentication Name 2 CARD16 Host-
name length (n) n CARD8 Hostname
2 CARD16 Status length (o) o CARD8 Status
2 CARD16 version number (always 1)
2 CARD16 opcode (always Unwilling)
2 CARD16 length (4 + m + n) 2 CARD16 Host-
name length (m) m CARD8 Hostname
2 CARD16 Status length (n) n CARD8 Status
2 CARD16 version number (always 1)
2 CARD16 opcode (always Request)
2 CARD16 length 2 CARD16 Display Number
1 CARD8 Count of Connection Types (m) 2 x
m CARD16 Connection Types 1 CARD8 Count
of Connection Addresses (n) 2 CARD16 Length of first
Connection Address (n1) n1 CARD8 First Connection
Address ... Other connection addresses
2 CARD16 Length of Authentication Name (o)
o CARD8 Authentication Name 2 CARD16 Length
-----------
A previous version of this document incorrectly
reversed the opcodes of and
[1m19[0m
X Display Manager Control Protocol XDMCP
of Authentication Data (p) p CARD8 Authentication
Data 1 CARD8 Count of Authorization Names (q)
2 CARD16 Length of first Authorization Name (q1)
q1 CARD8 First Authorization Name
... Other authorization names
2 CARD16 Length of Manufacturer Display ID (r)
r CARD8 Manufacturer Display ID
2 CARD16 version number (always 1)
2 CARD16 opcode (always Accept)
2 CARD16 length (12 + n + m + o + p)
4 CARD32 Session ID 2 CARD16 Length of
Authentication Name (n) n CARD8 Authentication Name
2 CARD16 Length of Authentication Data (m)
m CARD8 Authentication Data 2 CARD16 Length
of Authorization Name (o) o CARD8 Authorization
Name 2 CARD16 Length of Authorization Data (p)
p CARD8 Authorization Data
2 CARD16 version number (always 1)
2 CARD16 opcode (always Decline)
2 CARD16 length (6 + m + n + o)
2 CARD16 Length of Status (m) m CARD8 Sta-
tus 2 CARD16 Length of Authentication Name (n)
n CARD8 Authentication Name 2 CARD16 Length
of Authentication Data (o) o CARD8 Authentication
Data
2 CARD16 version number (always 1)
2 CARD16 opcode (always Manage)
2 CARD16 length (8 + m) 4 CARD32 Session ID
2 CARD16 Display Number 2 CARD16 Length of
Display Class (m) m CARD8 Display Class
2 CARD16 version number (always 1)
2 CARD16 opcode (always Refuse)
2 CARD16 length (4) 4 CARD32 Session ID
2 CARD16 version number (always 1)
2 CARD16 opcode (always Failed)
2 CARD16 length (6 + m) 4 CARD32 Session ID
2 CARD16 Length of Status (m) m CARD8 Sta-
tus
2 CARD16 version number (always 1)
2 CARD16 opcode (always KeepAlive)
2 CARD16 length (6) 2 CARD16 Display Number
4 CARD32 Session ID
2 CARD16 version number (always 1)
2 CARD16 opcode (always Alive)
2 CARD16 length (5) 1 CARD8 Session Running
(0: not running 1: running) 4 CARD32 Session ID (0:
not running)
[1m20[0m
XDMCP X Display Manager Control Protocol
[1m9. Display Class Format[0m
The Display Class field of the packet is used by the display
manager to collect common sorts of displays into manageable
groups. This field is a string encoded of ISO-LATIN-1 char-
acters in the following format:
[4mManufacturerID[24m-[4mModelNumber[0m
Both elements of this string must exclude characters of the
set { [1m-[22m, [1m.[22m, [1m:[22m, [1m*[22m, [1m?[22m, [4m<space>[24m }. The ManufacturerID is a
string that should be registered with the X Consortium. The
ModelNumber is designed to identify characteristics of the
display within the manufacturer's product line. This string
should be documented in the users manual for the particular
device and should probably not be specifiable by the dis-
play user to avoid unexpected configuration errors.
[1m10. Manufacturer Display ID Format[0m
To authenticate the manager, the display and manager will
share a private key. The manager, then, must be able to
discover which key to use for a particular device. The Man-
ufacturer Display ID field of the packet is intended for
this purpose. Typically, the manager host will contain a
map between this number and the key. This field is intended
to be unique per display, possibly the ethernet address of
the display in the form:
-Ethernet-8:0:2b:a:f:d2
It can also be a string of the form:
[4mManufacturerID[24m-[4mModelNumber[24m-[4mSerialNumber[0m
The ManufacturerID, ModelNumber and SerialNumber are encoded
using ISO-LATIN-1 characters, excluding { [1m-[22m, [1m.[22m, [1m*[22m, [1m?[22m,
[4m<space>[24m }
When the display is shipped to a customer, it should include
both the Manufacturer Display ID and the private key in the
documentation set. This information should not be modifi-
able by the display user.
[1m11. Authentication[0m
In an environment where authentication is not needed, XDMCP
can disable authentication by having the display send empty
Authentication Name and Authentication Data fields in the
packet. In this case, the manager will not attempt to
authenticate itself. Other authentication protocols may be
developed, depending on local needs.
[1m21[0m
X Display Manager Control Protocol XDMCP
In an unsecure environment, the display must be able to ver-
ify that the source of the various packets is a trusted man-
ager. These packets will contain authentication informa-
tion. As an example of such a system, the following discus-
sion describes the "XDM-AUTHENTICATION-1" authentication
system. This system uses a 56-bit shared private key, and
64 bits of authentication data. An associated example X
authorization protocol "XDM-AUTHORIZATION-1" will also be
discussed. The 56-bit key is represented as a 64-bit number
in network order (big endian). This means that the first
octet in the representation will be zero. When incrementing
a 64-bit value, the 8 octets of data will be interpreted in
network order (big endian). That is, the last octet will be
incremented, subsequent carries propogate towards the first
octet.
+o Assumptions
1. The display and manager share a private key. This
key could be programmed into the display by the
manufacturer and shipped with the unit. It must
not be available from the display itself, but
should allow the value to be modified in some way.
The system administrator would be responsible for
managing a database of terminal keys.
2. The display can generate random authentication
numbers.
Some definitions first:
oc D cc sup kappa mark = "encryption of plain text " D " by key " kappa
oc DELTA cc * sup kappa lineup = "decryption of crypto text " DELTA " with key " kappa
{ tau } lineup = "private key shared by display and manager"
rho lineup = "64 bit random number generated by display"
alpha lineup = "authentication data in XDMCP packets"
sigma lineup = "per-session private key, generated by manager"
beta lineup = "authorization data"
Encryption will use the DES; blocks shorter than 64 bits
will be zero-filled on the right to 64 bits. Blocks longer
[1m22[0m
XDMCP X Display Manager Control Protocol
than 64 bits will use block chaining:
oc { D } cc sup kappa lineup = oc { D sub 1 } cc sup kappa " "
oc { D sub 2 } " " xor " " oc { D sub 1 } cc sup kappa cc sup kappa
The display generates the first authentication data in the
packet:
alpha sub roman Request mark = oc rho cc sup tau
For the packet, the manager decrypts the initial message and
returns @alpha sub roman Accept@:
rho lineup = oc alpha sub roman Request cc * sup tau
alpha sub roman Accept lineup = oc rho + 1 cc sup tau
The packet also contains the authorization intended for use
by the X server. A description of authorization type ``XDM-
AUTHORIZATION-1'' follows.
The packet contains the authorization name ``XDM-AUTHORIZA-
TION-1''. The authorization data is the string:
beta sub Accept mark = oc sigma cc sup tau
To create authorization information for connection setup
with the X server using the XDM-AUTHORIZATION-1 authoriza-
tion protocol, the client computes the following:
N mark = "X client identifier"
T lineup = "Current time in seconds on client host (32 bits)"
beta lineup = oc rho N T cc sup sigma
For TCP connections @N@ is 48 bits long and contains the
32-bit IP address of the client host followed by the 16-bit
port number of the client socket. Formats for other connec-
tions must be registered. The resulting value, @beta@, is
192 bits of authorization data that is sent in the connec-
tion setup to the server. The server receives the packet,
decrypts the contents. To accept the connection, the fol-
lowing must hold:
[1m23[0m
X Display Manager Control Protocol XDMCP
+o @rho@ must match the value generated for the most
recent XDMCP negotiation.
+o @T@ must be within 1200 seconds of the internally
stored time. If no time been received before, the cur-
rent time is set to @T@.
+o No packet containing the same pair (@N@, @T@) can have
been received in the last 1200 seconds (20 minutes).
[1m24[0m
XDMCP X Display Manager Control Protocol
[1mTable of Contents[0m
1. Purpose and Goals . . . . . . . . . . . . . . . 1
2. Overview of the Protocol . . . . . . . . . . . . 2
3. Data Types . . . . . . . . . . . . . . . . . . . 3
4. Packet Format . . . . . . . . . . . . . . . . . 4
5. Protocol . . . . . . . . . . . . . . . . . . . . 5
6. Session Termination . . . . . . . . . . . . . . 14
7. State Diagrams . . . . . . . . . . . . . . . . . 14
8. Protocol Encoding . . . . . . . . . . . . . . . 18
9. Display Class Format . . . . . . . . . . . . . . 21
10. Manufacturer Display ID Format . . . . . . . . 21
11. Authentication . . . . . . . . . . . . . . . . 21
[1m25[0m
