X Display Manager Control Protocol

Version 1.1 DRAFT

X.Org Standard

X Version 11, Release 6.7

Keith Packard

X Consortium Laboratory for Computer Science Massachusetts Institute of Technology

Copyright © 1989, 2002 The Open Group

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ‘‘Software’’), to deal in the Software without 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 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 NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP 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 Open Group 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 Open Group.

X Window System is a trademark of The Open Group.

XDMCP X Display Manager Control Protocol

1. Purpose and GoalsThe purpose of the X Display Manager Control Protocol(XDMCP) is to provide a uniform mechanism for an autonomousdisplay to request login service from a remote host. Byautonomous, we mean the display consists of hardware andprocesses that are independent of any particular host wherelogin service is desired. (For example, the server cannotsimply be started by a fork/exec sequence on the host.) AnX terminal (screen, keyboard, mouse, processor, networkinterface) is a prime example of an autonomous display.From the point of view of the end user, it is very importantto make autonomous displays as easy to use as traditionalhardwired character terminals. Specifically, you cantypically just power on a hardwired terminal and be greetedwith a login prompt. The same should be possible withautonomous displays. However, in a network environment withmultiple hosts, the end user may want to choose whichhost(s) to connect to. In an environment with many displaysand many hosts, a site administrator may want to associateparticular collections of hosts with particular displays.We would like to support the following options:• The display has a single, fixed host to which it shouldconnect. It should be possible to power on the displayand receive a login prompt, without user intervention.• Any one of several hosts on a network or subnetwork maybe acceptable for accepting login from the display.(For example, the user’s file systems can be mountedonto any such host, providing comparable environments.)It should be possible for the display to broadcast tofind such hosts and to have the display eitherautomatically choose a host or present the possiblehosts to the user for selection.• The display has a fixed set of hosts that it canconnect to. It should be possible for the display tohave that set stored in RAM, but it should also bepossible for a site administrator to be able tomaintain host sets for a large number of displays usinga centralized facility, without having to interact(physically or electronically) with each individualdisplay. Particular hosts should be allowed to refuselogin service, based on whatever local criteria aredesired.The control protocol should be designed in such a way thatit can be used over a reasonable variety of communicationtransport layers. In fact, it is quite desirable if everymajor network protocol family that supports the standard Xprotocol is also capable of supporting XDMCP, because theend result of XDMCP negotiation will be standard X protocolconnections to the display. However, because the number ofdisplays per host may be large, a connection-based protocolappears less desirable than a connection-less protocol. Forthis reason the protocol is designed to use datagramservices with the display responsible for sequencing andretransmission.To keep the burden on displays at a minimum (because displaycost is not a factor that can be ignored), it is desirablethat displays not be required to maintain permanent state(across power cycles) for the purposes of the controlprotocol, and it is desirable to keep required state at aminimum while the display is powered on.Security is an important consideration and must be anintegral part of the design. The important security goalsin the context of XDMCP are:• It should be possible for the display to verify that itis communicating with a legitimate host login service.Because the user will present credentials (for example,password) to this service, it is important to avoidspoof attacks.• It should be possible for the display and the loginservice to negotiate the authorization mechanism to beused for the standard X protocol.• It should be possible to provide the same level ofsecurity in verifying the login service as is providedby the negotiated authorization mechanism.• Because there are no firm standards yet in the area ofsecurity, XDMCP must be flexible enough to accomodate avariety of security mechanisms.2. Overview of the ProtocolXDMCP is designed to provide authenticated access to displaymanagement services for remote displays. A new networkserver, called a Display Manager, will use XDMCP tocommunicate with displays to negotiate the startup of Xsessions. The protocol allows the display to authenticatethe manager. It also allows most of the configurationinformation to be centralized with the manager and to easethe burden of system administration in a large network ofdisplays. The essential goal is to provide plug-and-playservices similar to those provided in the familiarmainframe/terminal world.Displays may be turned off by the user at any time. Anyexisting session running on a display that has been turnedoff must be identifiable. This is made possible byrequiring a three-way handshake to start a session. If thehandshake succeeds, any existing session is terminatedimmediately and a new session started. There is the problem(at least with TCP) that connections may not be closed whenthe display is turned off. In most environments, themanager should reduce this problem by periodically XSync’ingon its own connection, perhaps every five to ten minutes,and terminating the session if its own connection evercloses.Displays should not be required to retain permanent statefor purposes of the control protocol. One solution topackets received out of sequence would be to usemonotonically increasing message identifiers in each messageto allow both sides to ignore messages that arriveout-of-sequence. For this to work, displays would at aminimum have to increment a stable crash count each timethey are powered on and use that number as part of a largersequence number. But if displays cannot retain permanentstate this cannot work. Instead, the manager assumes theresponsibility for permanent state by generating uniquenumbers that identify a particular session and the protocolsimply ignores packets that correspond to an invalidsession.The Manager must not be responsible for packet reception.To prevent the Manager from becoming stuck because of ahostile display, no portion of the protocol requires theManager to retransmit a packet. Part of this means that anyvalid packet that the Manager does receive must beacknowledged in some way to prevent the display fromcontinuously resending packets. The display can keep theprotocol running as it will always know when the Manager hasreceived (at least one copy of) a packet. On the Managerside, this means that any packet may be received more thanonce (if the response was lost) and duplicates must beignored.3. Data TypesXDMCP packets contain several types of data. Integer valuesare always stored most significant byte first in the packet(‘‘Big Endian’’ order). As XDMCP will not be used totransport large quantities of data, this restriction willnot substantially hamper the efficiency of anyimplementation. Also, no padding of any sort will occurwithin the packets.4. Packet FormatAll XDMCP packets have the following information:The fields are as follows:• Version numberThis specifies the version of XDMCP that generated thispacket in case changes in this protocol are required.Displays and managers may choose to support olderversions for compatibility. This field will initiallybe one (1).• OpcodeThis specifies what step of the protocol this packetrepresents and should contain one of the followingvalues (encoding provided in section below):BroadcastQuery, Query, IndirectQuery, ForwardQuery,Willing, Unwilling, Request, Accept, Decline, Manage,Refuse, Failed, KeepAlive, or Alive.• Length of data in bytesThis specifies the length of the information followingthe first 6 bytes. Each packet-type has a differentformat and will need to be separately length-checkedagainst this value. Because every data item has eitheran explicit or implicit length, this can be easilyaccomplished. Packets that have too little or too muchdata should be ignored.Packets should be checked to make sure that they satisfy thefollowing conditions:1. They must contain valid opcodes.2. The length of the remaining data should correspond tothe sum of the lengths of the individual remaining dataitems.3. The opcode should be expected (a finite state diagramis given in a later section).4. If the packet is of type Manage or Refuse, the SessionID should match the value sent in the preceding Acceptpacket.5. ProtocolEach of the opcodes is described below. Because a givenpacket type is only ever sent one way, each packetdescription below indicates the direction. Most of thepackets have additional information included beyond thedescription above. The additional information is appendedto the packet header in the order described without padding,and the length field is computed accordingly.QueryBroadcastQueryIndirectQueryDisplay → ManagerAdditional Fields:Authentication Names: ARRAYofARRAY8Specifies a list of authentication names thatthe display supports. The manager willchoose one of these and return it in theWilling packet.Semantics:A Query packet is sent from the display to aspecific host to ask if that host is willing toprovide management services to this display. Thehost should respond with Willing if it is willingto service the display or Unwilling if it is not.A BroadcastQuery packet is similar to the Querypacket except that it is intended to be receivedby all hosts on the network (or subnetwork).However, unlike Query requests, hosts that are notwilling to service the display should simplyignore BroadcastQuery requests.An IndirectQuery packet is sent to a well knownmanager that forwards the request to a largercollection of secondary managers usingForwardQuery packets. In this way, the collectionof managers that respond can be grouped on otherthan network boundaries; the use of a centralmanager reduces system administrative overhead.The primary manager may also send a Willing packetin response to this packet.Each packet type has slightly different semantics:• The Query packet is destined only for asingle host. If the display is instructed toQuery multiple managers, it will sendmultiple Query packets. The Query packetalso demands a response from the manager,either Willing or Unwilling.• The BroadcastQuery packet is sent to manyhosts. Each manager that receives thispacket will not respond with an Unwillingpacket.• The IndirectQuery packet is sent to only onemanager with the request that the request beforwarded to a larger list of managers usingForwardQuery packets. This list is expectedto be maintained at one central site toreduce administrative overhead. The functionof this packet type is similar toBroadcastQueryexcept BroadcastQuery is notforwarded.Valid Responses:Willing, UnwillingProblems/Solutions:Problem:Not all managers receive the query packet.Indication:None if BroadcastQuery or IndirectQuerywas sent, else failure to receiveWilling.Solution:Repeatedly send the packet while waitingfor user to choose a manager.Timeout/Retransmission policy:An exponential backoff algorithm should be usedhere to reduce network load for long-standing idledisplays. Start at 2 seconds, back off by factorsof 2 to 32 seconds, and discontinue retransmitafter 126 seconds. The display should reset thetimeout when user-input is detected. In this way,the display will wakeup when touched by the user.ForwardQueryPrimary Manager → Secondary ManagerAdditional Fields:Client Address: ARRAY8Specifies the network address of the clientdisplay.Client Port: ARRAY8Specifies an identification of the clienttask on the client display.Authentication Names: ARRAYofARRAY8Is a duplicate of Authentication Names arraythat was received in the IndirectQuerypacket.Semantics:When primary manager receives a IndirectQuerypacket, it is responsible for sending ForwardQuerypackets to an appropriate list of managers thatcan provide service to the display using the samenetwork type as the one the original IndirectQuerypacket was received from. The Client Address andClient Port fields must contain an address thatthe secondary manager can use to reach the displayalso using this same network. Each secondarymanager sends a Willing packet to the display ifit is willing to provide service.ForwardQuery packets are similar to BroadcastQuerypackets in that managers that are not willing toservice particular displays should not send aUnwilling packet.Valid Responses:WillingProblems/Solutions:Identical to BroadcastQueryTimeout/Retransmission policy:Like all packets sent from a manager, this packetshould never be retransmitted.WillingManager → DisplayAdditional Fields:Authentication Name: ARRAY8Specifies the authentication method, selectedfrom the list offered in the Query,BroadcastQuery, or IndirectQuery packet thatthe manger expects the display to use in thesubsequent Request packet. This choiceshould remain as constant as feasible so thatdisplays that send multiple Query packets canuse the Authentication Name from any Willingpacket that arrives.The display is free to ignore managers thatrequest an insufficient level ofauthentication.Hostname: ARRAY8Is a human readable string describing thehost from which the packet was sent. Theprotocol specifies no interpretation of thedata in this field.Status: ARRAY8Is a human readable string describing thestatus of the host. This could include loadaverage/number of users connected or otherinformation. The protocol specifies nointerpretation of the data in this field.Semantics:A Willing packet is sent by managers that mayservice connections from this display. It is sentin response to either a Query, BroadcastQuery, orForwardQuery but does not imply a commitment toprovide service (for example, it may later decidethat it has accepted enough connections already).Problems/Solutions:Problem:Willing not received by the display.Indication:None if BroadcastQuery or IndirectQuerywas sent, else failure to receiveWilling.Solution:The display should continue to send thequery until a response is received.Timeout/Retransmission policy:Like all packets sent from the manager to thedisplay, this packet should never beretransmitted.UnwillingManager → DisplayAdditional Fields:The Hostname and Status fields as in the Willingpacket. The Status field should indicate to theuser a reason for the refusal of service.Semantics:An Unwilling packet is sent by managers inresponse to direct Query requests (as opposed toBroadcastQuery or IndirectQuery requests) if themanager will not accept requests for management.This is typically sent by managers that wish toonly service particular displays or that handle alimited number of displays at once.Problems/Solutions:Problem:Unwilling not received by the display.Indication:Display fails to receive Unwilling.Solution:The display should continue to sendQuery messages until a response isreceived.Timeout/Retransmission policy:Like all packets sent from the manager to thedisplay, this packet should never beretransmitted.RequestDisplay → ManagerAdditional Fields:Display Number: CARD16Specifies the index of this particular serverfor the host on which the display isresident. This value will be zero for mostautonomous displays.Connection Types: ARRAY16Specifies an array indicating the streamservices accepted by the display. If thehigh-order byte in a particular entry iszero, the low-order byte corresponds to anX-protocol host family type.Connection Addresses: ARRAYofARRAY8For each connection type in the previousarray, the corresponding entry in this arrayindicates the network address of the displaydevice.Authentication Name: ARRAY8Authentication Data: ARRAY8Specifies the authentication protocol thatthe display expects the manager to validateitself with. The Authentication Data isexpected to contain data that the managerwill interpret, modify and use toauthenticate itself.Authorization Names: ARRAYofARRAY8Specifies which types of authorization thedisplay supports. The manager may decide toreject displays with which it cannot performauthorization.Manufacturer Display ID: ARRAY8Can be used by the manager to determine howto decrypt the Authentication Data field inthis packet. See the section below onManufacturer Display ID Format.Semantics:A Request packet is sent by a display to aspecific host to request a session ID inpreparation for a establishing a connection. Ifthe manager is willing to service a connection tothis display, it should return an Accept packetwith a valid session ID and should be ready for asubsequent Manage request. Otherwise, it shouldreturn a Decline packet.Valid Responses:Accept, DeclineProblems/Solutions:Problem:Request not received by manager.Indication:Display timeout waiting for response.Solution:Display resends Request message.Problem:Message received out of order by manager.Indication:None.Solution:Each time a Request is sent, the managersends the Session ID associated with thenext session in the Accept. If thatnext session is not yet started, themanager will simply resend with the sameSession ID. If the session is inprogress, the manager will reply with anew Session ID; in which case, theAccept will be discarded by the display.Timeout/Retransmission policy:Timeout after 2 seconds, exponential backoff to 32seconds. After no more than 126 seconds, give upand report an error to the user.AcceptManager → DisplayAdditional Fields:Session ID: CARD32Identifies the session that can be started bythe manager.Authentication Name: ARRAY8Authentication Data: ARRAY8Is the data sent back to the display toauthenticate the manager. If theAuthentication Data is not the value expectedby the display, it should terminate theprotocol at this point and display an errorto the user.Authorization Name: ARRAY8Authorization Data: ARRAY8Is the data sent to the display to indicatethe type of authorization the manager will beusing in the first call to XOpenDisplay afterthe Manage packet is received.Semantics:An Accept packet is sent by a manager in responseto a Request packet if the manager is willing toestablish a connection for the display. TheSession ID is used to identify this connectionfrom any preceding ones and will be used by thedisplay in its subsequent Manage packet. TheSession ID is a 32-bit number that is incrementedeach time an Accept packet is sent as it must beunique over a reasonably long period of time.If the authentication information is invalid, aDecline packet will be returned with anappropriate Status message.Problems/Solutions:Problem:Accept or Decline not received by display.Indication:Display timeout waiting for response toRequest.Solution:Display resends Request message.Problem:Message received out of order by display.Indication:Display receives Accept after Manage hasbeen sent.Solution:Display discards Accept messages afterit has sent a Manage message.Timeout/Retransmission policy:Like all packets sent from the manager to thedisplay, this packet should never beretransmitted.DeclineManager → DisplayAdditional Fields:Status: ARRAY8Is a human readable string indicating thereason for refusal of service.Authentication Name: ARRAY8Authentication Data: ARRAY8Is the data sent back to the display toauthenticate the manager. If theAuthentication Data is not the value expectedby the display, it should terminate theprotocol at this point and display an errorto the user.Semantics:A Decline packet is sent by a manager in responseto a Request packet if the manager is unwilling toestablish a connection for the display. This isallowed even if the manager had responded Willingto a previous query.Problems/Solutions:Same as for Accept.Timeout/Retransmission policy:Like all packets sent from a manager to a display,this packet should never be retransmitted.ManageDisplay → ManagerAdditional Fields:Session ID: CARD32Should contain the nonzero session IDreturned in the Accept packet.Display Number: CARD16Must match the value sent in the previousRequest packet.Display Class: ARRAY8Specifies the class of the display. See theDisplay Class Format section, which discussesthe format of this field.Semantics:A Manage packet is sent by a display to ask themanager to begin a session on the display. If theSession ID is correct the manager should open aconnection; otherwise, it should respond with aRefuse or Failed packet, unless the Session IDmatches a currently running session or a sessionthat has not yet successfully opened the displaybut has not given up the attempt. In this lattercase, the Manage packet should be ignored. Thiswill work as stream connections give positivesuccess indication to both halves of the stream,and positive failure indication to the connectioninitiator (which will eventually generate a Failedpacket).Valid Responses:X connection with correct auth info, Refuse,Failed.Problems/Solutions:Problem:Manage not received by manager.Indication:Display timeout waiting for response.Solution:Display resends Manage message.Problem:Manage received out of order by manager.Indication:Session already in progress withmatching Session ID.Solution:Manage packet ignored.Indication:Session ID does not match next SessionID.Solution:Refuse message is sent.Problem:Display cannot be opened on selected stream.Indication:Display connection setup fails.Solution:Failed message is sent including a humanreadable reason.Problem:Display open does not succeed before a secondmanage packet is received because of atimeout occuring in the display.Indication:Manage packet received with Session IDmatching the session attempting toconnect to the display.Solution:Manage packet is ignored. As the streamconnection will either succeed, whichwill result in an active session, or thestream will eventually give up hope ofconnecting and send a Failed packet; noresponse to this Manage packet isnecessary.Timeout/Retransmission policy:Timeout after 2 seconds, exponential backoff to 32seconds. After no more than 126 seconds, give upand report an error to the user.RefuseManager → DisplayAdditional Fields:Session ID: CARD32Should be set to the Session ID received inthe Manage packet.Semantics:A Refuse packet is sent by a manager when theSession ID received in the Manage packet does notmatch the current Session ID. The display shouldassume that it received an old Accept packet andshould resend its Request packet.Problems/Solutions:Problem:Error message is lost.Indication:Display times out waiting for newconnection, Refuse or Failed.Solution:Display resends Manage message.Timeout/Retransmission policy:Like all packets sent from a manager to a display,this packet should never be retransmitted.FailedManager → DisplayAdditional Fields:Session ID: CARD32Should be set to the Session ID received inthe Manage packet.Status: ARRAY8Is a human readable string indicating thereason for failure.Semantics:A Failed packet is sent by a manager when it hasproblems establishing the initial X connection inresponse to the Manage packet.Problems/SolutionsSame as for Refuse.KeepAliveDisplay → ManagerAdditional Fields:Display Number: CARD16Set to the display index for the displayhost.Session ID: CARD32Should be set to the Session ID received inthe Manage packet during the negotiation forthe current session.Sematics:A KeepAlive packet can be sent at any time duringthe session by a display to discover if themanager is running. The manager should respondwith Alive whenever it receives this type ofpacket.This allows the display to discover when themanager host is no longer running. A display isnot required to send KeepAlive packets and, uponlack of receipt of Alive packets, is not requiredto perform any specific action.The expected use of this packet is to terminate anactive session when the manager host or networklink fails. The display should keep track of thetime since any packet has been received from themanager host and use KeepAlive packets when asubstantial time has elapsed since the most recentpacket.Valid Responses:AliveProblems/Solutions:Problem:Manager does not receive the packet ordisplay does not receive the response.Indication:No Alive packet is returned.Solution:Retransmit the packet with anexponential backoff; start at 2 secondsand assume the host is not up after noless than 30 seconds.AliveManager → DisplayAdditional Fields:Session Running: CARD8Indicates that the session identified bySession ID is currently active. The value iszero if no session is active or one if asession is active.Session ID: CARD32Specifies the ID of the currently runningsession; if any. When no session is activethis field should be zero.Semantics:An Alive packet is sent in response to a KeepAliverequest. If a session is currently active on thedisplay, the manager includes the Session ID inthe packet. The display can use this informationto determine the status of the manager.6. Session TerminationWhen the session is over, the initial connection with thedisplay (the one that acknowledges the Manage packet) willbe closed by the manager. If only a single session wasactive on the display, all other connections should beclosed by the display and the display should be reset. Ifmultiple sessions are active simultaneously and the displaycan identify which connections belong to the terminatedsesssion, those connections should be closed. Otherwise,all connections should be closed and the display reset onlywhen all sessions have been terminated (that is, all initialconnections closed).The session may also be terminated at any time by thedisplay if the managing host no longer responds to KeepAlivepackets. The exact time-outs for sending KeepAlive packetsis not specified in this protocol as the trade off shouldnot be fixed between loading an otherwise idle system withspurious KeepAlive packets and not noticing that the managerhost is down for a long time.7. State DiagramsThe following state diagrams are designed to cover allactions of both the display and the manager. Any packetthat is received out-of-sequence will be ignored.Display:start:User-requested connect to one host → queryUser-requested connect to some host → broadcastUser-requested connect to site host-list →indirectquery:Send Query packet→ collect-querycollect-query:Receive Willing → start-connectionReceive Unwilling → stop-connectionTimeout → querybroadcast:Send BroadcastQuery packet→ collect-broadcast-querycollect-broadcast-query:Receive Willing → update-broadcast-willingUser-requested connect to one host →start-connectionTimeout → broadcastupdate-broadcast-willing:Add new host to the host list presented to theuser→ collect-broadcast-queryindirect:Send IndirectQuery packet→ collect-indirect-querycollect-indirect-query:Receive Willing → update-indirect-willingUser-requested connect to one host →start-connectionTimeout → indirectupdate-indirect-willing:Add new host to the host list presented to theuser→ collect-indirect-querystart-connection:Send Request packet→ await-request-responseawait-request-response:Receive Accept → manageReceive Decline → stop-connectionTimeout → start-connectionmanage:Save Session IDSend Manage packet with Session ID→ await-manage-responseawait-manage-response:Receive XOpenDisplay: → run-sessionReceive Refuse with matching Session ID →start-connectionReceive Failed with matching Session ID →stop-connectionTimeout → managestop-connection:Display cause of termination to user→ startrun-session:Decide to send KeepAlive packet → keep-aliveAwait close of first display connection→ reset-displaykeep-alive:Send KeepAlive packet with current Session ID→ await-aliveawait-alive:Receive Alive with matching Session ID →run-sessionReceive Alive with nonmatching Session ID or FALSESession Running → reset-displayFinal timeout without receiving Alive packet →reset-displayTimeout → keep-alivereset-display:(if possible) → close all display connectionsassociated with this sessionLast session → close all display connections→ startManager:idle:Receive Query → query-respondReceive BroadcastQuery → broadcast-respondReceive IndirectQuery → indirect-respondReceive ForwardQuery → forward-respondReceive Request → request-respondReceive Manage → manageAn active session terminates → finish-sessionReceive KeepAlive → send-alive→ idlequery-respond:If willing to manage → send-willing→ send-unwillingbroadcast-respond:If willing to manage → send-willing→ idleindirect-respond:Send ForwardQuery packets to all managers onredirect listIf willing to manage → send-willing→ idleforward-respond:Decode destination address, if willing to manage →send-willing→ idlesend-willing:Send Willing packet→ idlesend-unwilling:Send Unwilling packet→ idlerequest-respond:If manager is willing to allow a session ondisplay → accept-session→ decline-sessionaccept-session:Generate Session ID and save Session ID, displayaddress, and display number somewhereSend Accept packet→ idledecline-session:Send Decline packet→ idlemanage:If Session ID matches saved Session ID →run-sessionIf Session ID matches Session ID of session inprocess of starting up, or currently activesession → idle→ refuserefuse:Send Refuse packet→ idlerun-session:Terminate any session in progressXOpenDisplayOpen display succeeds → start-session→ failedfailed:Send Failed packet→ idlestart-session:Start a new session→ idlefinish-session:XCloseDisplay→ idlesend-alive:Send Alive packet containing current status→ idle8. Protocol EncodingWhen XDMCP is implemented on top of the Internet UserDatagram Protocol (UDP), port number 177 is to be used. Whenusing UDP over IPv4, Broadcast Query packets are sent viaUDP broadcast. When using UDP over IPv6, Broadcast Querypackets are sent via multicast, either to an address in theIANA registered XDMCP multicast address range ofFF0X:0:0:0:0:0:0:12B (where the X is replaced by a validscope id) or to a locally assigned multicast address. Theversion number in all packets will be 1. Packet opcodes are16-bit integers.Per packet information follows:QueryBroadcastQueryIndirectQuery2 CARD16 version number (always 1)2 CARD16 opcode (always Query, BroadcastQuery or IndirectQuery)2 CARD16 length1 CARD8 number of Authentication Names sent (m)2 CARD16 length of first Authentication Name (m1)m1 CARD8 first Authentication Name... Other Authentication NamesNote that these three packets are identical except for theopcode field.ForwardQuery2 CARD16 version number (always 1)2 CARD16 opcode (always ForwardQuery)2 CARD16 length2 CARD16 length of Client Address (m)m CARD8 Client Address2 CARD16 length of Client Port (n)n CARD8 Client Port1 CARD8 number of Authentication Names sent (o)2 CARD16 length of first Authentication Name (o1)o1 CARD8 first Authentication Name... Other Authentication NamesWilling2 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 Name2 CARD16 Hostname length (n)n CARD8 Hostname2 CARD16 Status length (o)o CARD8 StatusUnwilling2 CARD16 version number (always 1)2 CARD16 opcode (always Unwilling)2 CARD16 length (4 + m + n)2 CARD16 Hostname length (m)m CARD8 Hostname2 CARD16 Status length (n)n CARD8 StatusRequest2 CARD16 version number (always 1)2 CARD16 opcode (always Request)2 CARD16 length2 CARD16 Display Number1 CARD8 Count of Connection Types (m)2 × m CARD16 Connection Types1 CARD8 Count of Connection Addresses (n)2 CARD16 Length of first Connection Address (n1)n1 CARD8 First Connection Address... Other connection addresses2 CARD16 Length of Authentication Name (o)o CARD8 Authentication Name2 CARD16 Length of Authentication Data (p)p CARD8 Authentication Data1 CARD8 Count of Authorization Names (q)2 CARD16 Length of first Authorization Name (q1)q1 CARD8 First Authorization Name... Other authorization names2 CARD16 Length of Manufacturer Display ID (r)r CARD8 Manufacturer Display IDAccept2 CARD16 version number (always 1)2 CARD16 opcode (always Accept)2 CARD16 length (12 + n + m + o + p)4 CARD32 Session ID2 CARD16 Length of Authentication Name (n)n CARD8 Authentication Name2 CARD16 Length of Authentication Data (m)m CARD8 Authentication Data2 CARD16 Length of Authorization Name (o)o CARD8 Authorization Name2 CARD16 Length of Authorization Data (p)p CARD8 Authorization DataDecline2 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 Status2 CARD16 Length of Authentication Name (n)n CARD8 Authentication Name2 CARD16 Length of Authentication Data (o)o CARD8 Authentication DataManage2 CARD16 version number (always 1)2 CARD16 opcode (always Manage)2 CARD16 length (8 + m)4 CARD32 Session ID2 CARD16 Display Number2 CARD16 Length of Display Class (m)m CARD8 Display ClassRefuse2 CARD16 version number (always 1)2 CARD16 opcode (always Refuse)2 CARD16 length (4)4 CARD32 Session IDFailed2 CARD16 version number (always 1)2 CARD16 opcode (always Failed)2 CARD16 length (6 + m)4 CARD32 Session ID2 CARD16 Length of Status (m)m CARD8 StatusKeepAlive2 CARD16 version number (always 1)2 CARD16 opcode (always KeepAlive)2 CARD16 length (6)2 CARD16 Display Number4 CARD32 Session IDAlive2 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)9. Display Class FormatThe Display Class field of the Manage packet is used by thedisplay manager to collect common sorts of displays intomanageable groups. This field is a string encoded ofISO-LATIN-1 characters in the following format:ManufacturerID-ModelNumberBoth elements of this string must exclude characters of theset { -, ., :, *, ?, <space> }. The ManufacturerID is astring that should be registered with the X Consortium. TheModelNumber is designed to identify characteristics of thedisplay within the manufacturer’s product line. This stringshould be documented in the users manual for the particulardevice and should probably not be specifiable by thedisplay user to avoid unexpected configuration errors.10. Manufacturer Display ID FormatTo authenticate the manager, the display and manager willshare a private key. The manager, then, must be able todiscover which key to use for a particular device. TheManufacturer Display ID field of the Request packet isintended for this purpose. Typically, the manager host willcontain a map between this number and the key. This fieldis intended to be unique per display, possibly the ethernetaddress of the display in the form:-Ethernet-8:0:2b:a:f:d2It can also be a string of the form:ManufacturerID-ModelNumber-SerialNumberThe ManufacturerID, ModelNumber and SerialNumber are encodedusing ISO-LATIN-1 characters, excluding { -, ., *, ?,<space> }When the display is shipped to a customer, it should includeboth the Manufacturer Display ID and the private key in thedocumentation set. This information should not bemodifiable by the display user.11. AuthenticationIn an environment where authentication is not needed, XDMCPcan disable authentication by having the display send emptyAuthentication Name and Authentication Data fields in theRequest packet. In this case, the manager will not attemptto authenticate itself. Other authentication protocols maybe developed, depending on local needs.In an unsecure environment, the display must be able toverify that the source of the various packets is a trustedmanager. These packets will contain authenticationinformation. As an example of such a system, the followingdiscussion describes the "XDM-AUTHENTICATION-1" and"XDM-AUTHENTICATION-2" authentication systems. The"XDM-AUTHENTICATION-1" system uses a 56-bit shared privatekey, and 64 bits of authentication data."XDM-AUTHENTICATION-2" uses a 256 bit shared private key,and 256 bits of authentication data. Associated example Xauthorization protocol "XDM-AUTHORIZATION-1" and"XDM-AUTHORIZATION-2" will also be discussed. The 56-bit keyis represented as a 64-bit number in network order (bigendian). This means that the first octet in therepresentation will be zero. When incrementing a 64-bitvalue, the 8 octets of data will be interpreted in networkorder (big endian). That is, the last octet will beincremented, subsequent carries propogate towards the firstoctet.• Assumptions1. The display and manager share a private key. Thiskey could be programmed into the display by themanufacturer and shipped with the unit. It mustnot be available from the display itself, butshould allow the value to be modified in some way.The system administrator would be responsible formanaging a database of terminal keys.2. The display can generate random authenticationnumbers.Some definitions first:"XDM-AUTHENTICATION-1" encryption will use the DataEncryption Standard (DES, FIPS 46-3); blocks shorter than 64bits will be zero-filled on the right to 64 bits. Blockslonger than 64 bits will use block chaining:"XDM-AUTHENTICATION-2" encryption will use the AdvancedEncryption Standard (AES, FIPS-197); blocks shorter than128 bits will be zero-filled on the right to 128 bits.Blocks longer than 128 bits will use block chaining as shownabove.The display generates the first authentication data in theRequest packet:For the Accept packet, the manager decrypts the initialmessage and returns αAccept:The Accept packet also contains the authorization intendedfor use by the X server. A description of authorizationtype ‘‘XDM-AUTHORIZATION-1’’ follows.The Accept packet contains the authorization name‘‘XDM-AUTHORIZATION-1’’. The authorization data is thestring:To create authorization information for connection setupwith the X server using the XDM-AUTHORIZATION-1authorization protocol, the client computes the following:For TCP connections N is 48 bits long and contains the32-bit IPv4 address of the client host followed by the16-bit port number of the client socket. Formats for otherconnections must be registered. The resulting value, β, is192 bits of authorization data that is sent in theconnection setup to the server. The server receives thepacket, decrypts the contents. To accept the connection,the following must hold:• ρ must match the value generated for the most recentXDMCP negotiation.• T must be within 1200 seconds of the internally storedtime. If no time been received before, the currenttime is set to T.• No packet containing the same pair (N, T) can have beenreceived in the last 1200 seconds (20 minutes).‘‘XDM-AUTHORIZATION-2’’ is identical to‘‘XDM-AUTHORIZATION-1’’, except that for TCP connections Nis 256 bits long and contains the 128 bit IPv6 address ofthe client host followed by the 16 bit port number of theclient socket, with the remainder filled with zeros, and Tis extended to 64-bits. IPv4 addresses are represented asIPv4-mapped IPv6 addresses, with an 80-bit prefix of zerobits, followed by a 16-byte value of 0xFFFF, followed by theIPv4 address value, as defined in IETF RFC 2373. Formats forother connections must be registered.1

X Display Manager Control Protocol XDMCP

Table of Contents

. . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . .
1

. . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . .
1

2