X Display Manager Control Protocol

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 fork/exec 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 typically 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 connect 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:

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 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 services 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 protocol, 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 integral part of the design. The important security goals in the context of XDMCP are:

XDMCP is designed to provide authenticated access to display management services for remote displays. A new network server, called a \fIDisplay Manager\fP, will use XDMCP to communicate 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 system 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 requiring a three-way handshake to start a session. If the handshake succeeds, any existing session is terminated immediately and a new session started. There is the problem (at 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 terminating 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 packets 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 permanent state by generating unique numbers that identify a particular 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 hostile display, no portion of the protocol requires the Manager to retransmit a packet. Part of this means that any valid packet that the Manager does receive must be acknowledged in some way to prevent the display from continuously resending packets. The display can keep the protocol running 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.

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 transport 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.

All XDMCP packets have the following information:

The fields are as follows:

Packets should be checked to make sure that they satisfy the following conditions:

Each of the opcodes is described below. Because a given packet type is only ever sent one way, each packet description 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.

When the session is over, the initial connection with the display (the one that acknowledges the Manage 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 identify which connections belong to the terminated sesssion, those connections should be closed. Otherwise, all connections should be closed and the display reset only when all sessions have been terminated (that is, all initial connections closed).

The session may also be terminated at any time by the display if the managing host no longer responds to KeepAlive packets. The exact time-outs for sending KeepAlive packets is not specified in this protocol as the trade off should not be fixed between loading an otherwise idle system with spurious KeepAlive packets and not noticing that the manager host is down for a long time.

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:

Manager:

When XDMCP is implemented on top of the Internet User Datagram Protocol (UDP), port number 177 is to be used. When using UDP over IPv4, Broadcast Query packets are sent via UDP broadcast. When using UDP over IPv6, Broadcast Query packets are sent via multicast, either to an address in the IANA registered XDMCP multicast address range of FF0X:0:0:0:0:0:0:12B (where the X is replaced by a valid scope id) or to a locally assigned multicast address. The version number in all packets will be 1. Packet opcodes are 16-bit integers.

Per packet information follows:

Query, BroadcastQuery, IndirectQuery

     2     CARD16     version number (always 1)
     2     CARD16     opcode (always Query, BroadcastQuery or IndirectQuery)
     2     CARD16     length
     1     CARD8      number 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.

ForwardQuery
     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

Willing
     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     Hostname length (n)
     n     CARD8      Hostname
     2     CARD16     Status length (o)
     o     CARD8      Status

Unwilling
     2     CARD16     version number (always 1)
     2     CARD16     opcode (always Unwilling)
     2     CARD16     length (4 + m + n)
     2     CARD16     Hostname length (m)
     m     CARD8      Hostname
     2     CARD16     Status length (n)
     n     CARD8      Status

Request
     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)
     2xm   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 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

Accept
     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

Decline
     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      Status
     2     CARD16     Length of Authentication Name (n)
     n     CARD8      Authentication Name
     2     CARD16     Length of Authentication Data (o)
     o     CARD8      Authentication Data

Manage
     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

Refuse
     2     CARD16     version number (always 1)
     2     CARD16     opcode (always Refuse)
     2     CARD16     length (4)
     4     CARD32     Session ID

Failed
     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      Status

KeepAlive
     2     CARD16     version number (always 1)
     2     CARD16     opcode (always KeepAlive)
     2     CARD16     length (6)
     2     CARD16     Display Number
     4     CARD32     Session ID

Alive
     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)

The Display Class field of the Manage 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 characters in the following format:

ManufacturerID-ModelNumber

Both elements of this string must exclude characters of the set { -, ., :, *, ?, <space> }. 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 display user to avoid unexpected configuration errors.

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 Manufacturer Display ID field of the Request 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:

ManufacturerID-ModelNumber-SerialNumber

The ManufacturerID, ModelNumber and SerialNumber are encoded using ISO-LATIN-1 characters, excluding { -, ., *, ?, <space> }

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 modifiable by the display user.

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 Request packet. In this case, the manager will not attempt to authenticate itself. Other authentication protocols may be developed, depending on local needs.

In an unsecure environment, the display must be able to verify that the source of the various packets is a trusted manager. These packets will contain authentication information. As an example of such a system, the following discussion 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.

Assumptions:

Some definitions first:

Encryption will use the Data Encryption Standard (DES, FIPS 46-3); blocks shorter than 64 bits will be zero-filled on the right to 64 bits. Blocks longer than 64 bits will use block chaining:

{D}^κ = {D₁}^κ {D₂ xor {D₁}^κ}^κ

The display generates the first authentication data in the Request packet:

α_Request = {ρ}^τ

For the Accept packet, the manager decrypts the initial message and returns α_Accept:

ρ = {α_Request}*^τ

α_Accept = { ρ + 1}^τ

The Accept packet also contains the authorization intended for use by the X server. A description of authorization type "XDM-AUTHORIZATION-1" follows.

The Accept packet contains the authorization name "XDM-AUTHORIZATION-1". The authorization data is the string:

β_Accept = {σ}^τ

To create authorization information for connection setup with the X server using the XDM-AUTHORIZATION-1 authorization protocol, the client computes the following:

N = X client identifier

T = Current time in seconds on client host (32 bits)

β = {ρNT}^σ

For TCP connections N is 48 bits long and contains the 32-bit IPv4 address of the client host followed by the 16-bit port number of the client socket. Formats for other connections must be registered. The resulting value, β, is 192 bits of authorization data that is sent in the connection setup to the server. The server receives the packet, decrypts the contents. To accept the connection, the following must hold: