





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 ob-
taining a copy of  this  software  and  associated  documentation
files  (the  ``Software''),  to  deal in the Software without re-
striction, 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  Soft-
ware is furnished to do so, subject to the following 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 PURPOSE AND NONIN-
FRINGEMENT.  IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION  OF  CON-
TRACT,  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  Consortium
shall  not  be  used  in  advertising or otherwise to promote the
sale, use or other dealings in this Software without prior  writ-
ten 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  re-
quest  login  service from a remote host.  By autonomous, we mean
the display consists of hardware and processes that are  indepen-
dent 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, net-
work 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  asso-
ciate  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 con-
     nect.  It should be possible to power on the display and re-
     ceive 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 exam-
     ple,  the  user's  file systems can be mounted onto any such
     host, providing comparable environments.)  It should be pos-
     sible for the display to broadcast to find such hosts and to
     have the display  either  automatically  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 connect to.
     It  should  be  possible  for  the  display to have that set
     stored in RAM, but it should also be possible for a site ad-
     ministrator 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.   Particular 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 lay-
ers.   In fact, it is quite desirable if every major network pro-
tocol family that supports the standard X protocol is also  capa-
ble of supporting XDMCP, because the end result of XDMCP negotia-
tion  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 connec-
tion-less protocol.  For this reason the protocol is designed  to
use datagram services with the display responsible for sequencing



                                [1m1[0m





X Display Manager Control Protocol                          XDMCP


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 dis-
plays not be required to maintain permanent state  (across  power
cycles)  for  the purposes of the control protocol, and it is de-
sirable 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:

+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 negoti-
     ated authorization mechanism.

+o    Because there are no firm standards yet in the area of secu-
     rity,  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 man-
agement services for remote  displays.   A  new  network  server,
called a [4mDisplay[24m [4mManager[24m, will use XDMCP to communicate with dis-
plays  to  negotiate the startup of X sessions.  The protocol al-
lows 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 ex-
isting  session  is  terminated  immediately  and  a  new session
started.  There is the problem (at least with TCP)  that  connec-
tions  may not be closed when the display is turned off.  In most
environments, the manager should reduce this problem by  periodi-
cally  XSync'ing on its own connection, perhaps every five to ten
minutes, and terminating the session if its own  connection  ever
closes.



                                [1m2[0m





XDMCP                         X Display Manager Control Protocol


Displays  should  not  be  required to retain permanent state for
purposes of the control protocol.  One solution  to  packets  re-
ceived  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 responsibil-
ity for permanent state by generating unique numbers  that  iden-
tify 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 dis-
play, no portion of the protocol requires the Manager to retrans-
mit 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.

[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  transport  large
quantities  of data, this restriction will not substantially ham-
per 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  AR-
RAY16   2*m+1     This   is  a  CARD8  (m)  which  specifies  the
          number    of    CARD16    values    to    follow    AR-
RAY32   4*l+1     This   is  a  CARD8  (l)  which  specifies  the
          number  of   CARD32   values   to   follow   ARRAYofAR-
RAY8  ?    This  is  a CARD8 which specifies 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).  _



                                [1m3[0m





X Display Manager Control Protocol                          XDMCP


[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.   Dis-
     plays  and managers may choose to support older versions for
     compatibility.  This field will initially be one (1).

+o    Opcode

     This specifies what step of the protocol this packet  repre-
     sents and should contain one of the following values (encod-
     ing 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 fol-
lowing 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.

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 description below in-
dicates the direction.  Most of the packets have  additional  in-
formation  included beyond the description above.  The additional
information is appended to the packet header  in  the  order  de-
scribed without padding, and the length field is computed accord-
ingly.



                                [1m4[0m





XDMCP                         X Display Manager Control Protocol


     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 ser-
          vices 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 in-
          tended 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  man-
          agers  using  packets.   In this way, the collection of
          managers that respond can be grouped on other than net-
          work 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 multiple managers, it
               will send multiple packets.  The packet  also  de-
               mands a response from the manager, either or

          +o    The  packet  is  sent to many hosts.  Each manager
               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  ex-
               pected to be maintained at one central site to re-
               duce  administrative  overhead.   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



                                [1m5[0m





X Display Manager Control Protocol                          XDMCP


          reduce  network  load  for long-standing idle displays.
          Start at 2 seconds, back off by factors of 2 to 32 sec-
          onds, 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  dis-
               play.
          [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 responsi-
          ble  for sending packets to an appropriate list of man-
          agers 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  man-
          ager  can use to reach the display also using this same
          network.  Each secondary manager sends a packet to  the
          display if it is willing to provide service.

          packets  are  similar  to packets in that managers that
          are not willing to service particular  displays  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 pack-
               ets  can  use  the  Authentication  Name  from any
               packet that arrives.

               The display is free to ignore  managers  that  re-
               quest an insufficient level of authentication.
          [4mHostname[24m: ARRAY8
               Is  a  human  readable  string describing the host



                                [1m6[0m





XDMCP                         X Display Manager Control Protocol


               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/num-
               ber  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 connec-
          tions from this display.  It is sent in response to ei-
          ther a or but does not imply a  commitment  to  provide
          service  (for  example, it may later decide that it has
          accepted enough connections 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  display,
          this packet should never be retransmitted.

     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 re-
          quests  (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  messages
                    until a response is received.
     Timeout/Retransmission policy:
          Like  all packets sent from the manager to the display,
          this packet should never be retransmitted.

     Display -> Manager
     Additional Fields:
          [4mDisplay[24m [4mNumber[24m: CARD16



                                [1m7[0m





X Display Manager Control Protocol                          XDMCP


               Specifies the index of this particular server  for
               the  host  on which the display is resident.  This
               value will be zero for most autonomous displays.
          [4mConnection[24m [4mTypes[24m: ARRAY16
               Specifies an array indicating the stream  services
               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 con-
               tain  data that the manager will interpret, modify
               and use to authenticate itself.
          [4mAuthorization[24m [4mNames[24m: ARRAYofARRAY8
               Specifies which types of authorization the display
               supports.  The manager may decide to  reject  dis-
               plays with which it cannot perform authorization.
          [4mManufacturer[24m [4mDisplay[24m [4mID[24m: ARRAY8
               Can be used by the manager to determine how to de-
               crypt   the  Authentication  Data  field  in  this
               packet.  See the  section  below  on  Manufacturer
               Display ID Format.
     Semantics:
          A packet is sent by a display to a specific host to re-
          quest  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  sub-
          sequent 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



                                [1m8[0m





XDMCP                         X Display Manager Control Protocol


                    Session  ID;  in which case, the will be dis-
                    carded by the display.
     Timeout/Retransmission policy:
          Timeout after 2 seconds, exponential backoff to 32 sec-
          onds.  After no more than 126 seconds, give up and  re-
          port 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  authenti-
               cate  the  manager.  If the Authentication 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
          [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 preceding 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 message.
     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  display,
          this packet should never be retransmitted.




                                [1m9[0m





X Display Manager Control Protocol                          XDMCP


     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  authenti-
               cate  the  manager.  If the Authentication 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.
     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  Dis-
               play  Class  Format  section,  which discusses the
               format of this field.
     Semantics:
          A packet is sent by a display to ask the manager to be-
          gin a session on the display.  If  the  Session  ID  is
          correct  the  manager  should open a connection; other-
          wise, it should respond with a or  packet,  unless  the
          Session  ID  matches  a  currently running session or a
          session that has not yet successfully opened  the  dis-
          play  but has not given up the attempt.  In this latter
          case, the packet should be ignored.  This will work  as
          stream  connections give positive success indication to
          both halves of the stream, and positive failure indica-
          tion to the connection initiator (which will eventually
          generate a packet).
     Valid Responses:
          X connection with correct auth info,
     Problems/Solutions:
          Problem:
               not received by manager.
               Indication:
                    Display timeout waiting for response.



                                [1m10[0m





XDMCP                         X Display Manager Control Protocol


               Solution:
                    Display resends message.
          Problem:
               received out of order by manager.
               Indication:
                    Session already  in  progress  with  matching
                    Session ID.
               Solution:
                    packet ignored.
               Indication:
                    Session ID does not match next Session ID.
               Solution:
                    message is sent.
          Problem:
               Display cannot be opened on selected stream.
               Indication:
                    Display connection setup fails.
               Solution:
                    message  is  sent  including a human readable
                    reason.
          Problem:
               Display open does not succeed before a second man-
               age packet is received because of a timeout occur-
               ing 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 connection
                    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 sec-
          onds.   After no more than 126 seconds, give up and re-
          port 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 re-
          ceived 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 connection,
                    or



                                [1m11[0m





X Display Manager Control Protocol                          XDMCP


               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.
          [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 es-
          tablishing 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 ses-
               sion.
     Sematics:
          A packet can be sent at any time during the session  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 manager
          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 specific action.

          The expected use of this packet is to terminate an  ac-
          tive  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  display
               does not receive the response.
               Indication:
                    No packet is returned.
               Solution:



                                [1m12[0m





XDMCP                         X Display Manager Control Protocol


                    Retransmit  the  packet  with  an exponential
                    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 Session
               ID is currently active.  The value is zero  if  no
               session is active or one if a session 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  ses-
          sion  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 man-
ager.   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 ter-
minated 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  connec-
tions closed).

The  session may also be terminated at any time by the display 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 -> [4mindirect[0m



                                [1m13[0m





X Display Manager Control Protocol                          XDMCP


     [4mquery[24m:
          Send packet
          -> [4mcollect-query[0m


     [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-connection[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-connection[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





                                [1m14[0m





XDMCP                         X Display Manager Control Protocol


     [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-connection[0m
          Receive with matching Session ID -> [4mstop-connection[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 Session
          Running -> [4mreset-display[0m
          Final timeout without receiving packet -> [4mreset-display[0m
          Timeout -> [4mkeep-alive[0m


     [4mreset-display[24m:
          (if possible) -> close all display connections  associ-
          ated 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
          Receive -> [4mrequest-respond[0m
          Receive -> [4mmanage[0m
          An active session terminates -> [4mfinish-session[0m



                                [1m15[0m





X Display Manager Control Protocol                          XDMCP


          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 display  ->
          [4maccept-session[0m
          -> [4mdecline-session[0m


     [4maccept-session[24m:
          Generate  Session  ID  and save Session ID, display ad-
          dress, and display number somewhere
          Send packet
          -> [4midle[0m


     [4mdecline-session[24m:
          Send packet
          -> [4midle[0m





                                [1m16[0m





XDMCP                         X Display Manager Control Protocol


     [4mmanage[24m:
          If Session ID matches saved Session ID -> [4mrun-session[0m
          If Session ID matches Session ID of session in  process
          of starting up, or currently active session -> [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 Datagram
Protocol (UDP), port number 177 is to be used.  The version  num-
ber  in  all  packets will be 1.  Packet opcodes are 16-bit inte-
gers.

     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} T{ T}   T{ 11
     T} T{ T}   T{ 12 T} T{ T}   T{ 13 T} T{ T}   T{ 14 T}
     _






                                [1m17[0m





X Display Manager Control Protocol                          XDMCP


Per packet information follows:

  2    CARD16    version  number  (always 1)   2    CARD16    op-
code   (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.

  2    CARD16    version  number  (always 1)   2    CARD16    op-
code      (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    op-
code (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

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

  2    CARD16    version  number  (always 1)   2    CARD16    op-
code       (always        Request)          2    CARD16    length
  2    CARD16    Display Number   1    CARD8     Count of Connec-
tion   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     of     Authentication     Data    (p)
  p    CARD8     Authentication  Data    1    CARD8     Count  of
Authorization  Names  (q)   2    CARD16    Length of first Autho-
rization  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    op-
code (always Accept)   2    CARD16    length (12 + n + m + o + p)
  4    CARD32    Session    ID       2    CARD16    Length     of
-----------
   A previous version of this document incorrectly  reversed
the opcodes of and



                                [1m18[0m





XDMCP                         X Display Manager Control Protocol


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    op-
code  (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

  2    CARD16    version  number  (always 1)   2    CARD16    op-
code   (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    op-
code     (always     Refuse)       2    CARD16    length      (4)
  4    CARD32    Session ID

  2    CARD16    version  number  (always 1)   2    CARD16    op-
code   (always   Failed)     2    CARD16    length   (6   +    m)
  4    CARD32    Session ID   2    CARD16    Length of Status (m)
  m    CARD8     Status

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

  2    CARD16    version  number  (always 1)   2    CARD16    op-
code     (always     Alive)        2    CARD16    length      (5)
  1    CARD8     Session  Running  (0:  not  running  1: running)
  4    CARD32    Session ID (0: not running)

[1m9.  Display Class Format[0m

The Display Class field of the packet is used by the display man-
ager to collect common sorts of displays into manageable  groups.
This  field  is a string encoded of ISO-LATIN-1 characters 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  display  user  to  avoid  unexpected



                                [1m19[0m





X Display Manager Control Protocol                          XDMCP


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 Manufacturer 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 us-
ing 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 documenta-
tion set.  This information should not be modifiable by the  dis-
play user.

[1m11.  Authentication[0m

In  an  environment where authentication is not needed, XDMCP can
disable authentication by having the display send empty Authenti-
cation 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 lo-
cal 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 ex-
ample 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-AUTHORIZA-
TION-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  incre-
menting  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



                                [1m20[0m





XDMCP                         X Display Manager Control Protocol


          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  adminis-
          trator  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 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 re-
turns @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-AUTHO-
RIZATION-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 authorization protocol,



                                [1m21[0m





X Display Manager Control Protocol                          XDMCP


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 connections must be reg-
istered.  The resulting value, @beta@, is 192 bits of  authoriza-
tion  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:

+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 current 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).
































                                [1m22[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 . . . . . . . . . . . . . . . . . . . .   3
     5. Protocol  . . . . . . . . . . . . . . . . . . . . . .   4
     6. Session Termination . . . . . . . . . . . . . . . . .  13
     7. State Diagrams  . . . . . . . . . . . . . . . . . . .  13
     8. Protocol Encoding . . . . . . . . . . . . . . . . . .  17
     9. Display Class Format  . . . . . . . . . . . . . . . .  19
     10. Manufacturer Display ID Format . . . . . . . . . . .  20
     11. Authentication . . . . . . . . . . . . . . . . . . .  20










































                                [1m23[0m


