





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 au-
tonomous,  we mean the display consists of hardware and pro-
cesses that are independent of any particular host where lo-
gin  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 re-
transmission.

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 se-
     curity 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  es-
sential 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 ex-
isting 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



                              [1m2[0m





XDMCP                    X Display Manager Control Protocol


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  connec-
tion, 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 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  ac-
     complished.   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  re-
          quests,  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  re-
               spond 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 re-
                    ceive
               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 af-
          ter  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  re-
          sponsible  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 Ad-
          dress  and  Client Port fields must contain an ad-
          dress that the secondary manager 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.





                              [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  in-
               terpretation 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  re-
          sponse to either a or but does not imply a commit-
          ment to provide service (for example, it may later
          decide that it has accepted enough connections al-
          ready).
     Problems/Solutions:
          Problem:
               not received by the display.
               Indication:
                    None if or was sent, else failure to re-
                    ceive
               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 di-
          rect 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  au-
               tonomous 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 ar-
               ray, 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  ex-
               pected  to contain data that the manager will
               interpret, modify and use to authenticate it-
               self.
          [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  es-
          tablishing  a connection.  If the manager is will-
          ing 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  au-
               thenticate  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  au-
               thenticate  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  re-
               turned 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 re-
                    sponse 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 re-
          ceived 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.
          [4mStatus[24m: ARRAY8



                             [1m12[0m





XDMCP                    X Display Manager Control Protocol


               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 as-
                    sume 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 Ses-
               sion ID is currently active.   The  value  is



                             [1m13[0m





X Display Manager Control Protocol                     XDMCP


               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 ac-
tions 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 as-
          sociated 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 In-
directQuery)   2    CARD16    length   1    CARD8     number
of Authentication Names sent (m)   2    CARD16    length  of
first  Authentication  Name  (m1)   m1   CARD8     first Au-
thentication  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 Au-
thentication Names sent (o)   2    CARD16    length of first
Authentication  Name (o1)   o1   CARD8     first Authentica-
tion 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
of Authentication Data  (p)    p    CARD8     Authentication
-----------
   A previous version of this document incorrectly
reversed the opcodes of and



                             [1m19[0m





X Display Manager Control Protocol                     XDMCP


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 Au-
thentication 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  au-
thenticate  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 au-
thorization protocol "XDM-AUTHORIZATION-1" will also be dis-
cussed.  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 re-
     cent 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


