From b24af6c6af003368ebb5c3e042db0ab7a295d89e Mon Sep 17 00:00:00 2001 From: marha Date: Sun, 19 Dec 2010 17:44:53 +0000 Subject: libXext libXdmcp pixman git update 29/12/2010 --- libXdmcp/doc/xdmcp.xml | 111 +++++++++++++++++++++++++++---------------------- 1 file changed, 61 insertions(+), 50 deletions(-) (limited to 'libXdmcp') diff --git a/libXdmcp/doc/xdmcp.xml b/libXdmcp/doc/xdmcp.xml index 2b08ed7a7..c8797742d 100644 --- a/libXdmcp/doc/xdmcp.xml +++ b/libXdmcp/doc/xdmcp.xml @@ -1,6 +1,21 @@ + "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ + +D"> +N"> +T"> +Δ"> +α"> +β"> +κ"> +ρ"> +σ"> +τ"> +]> @@ -19,8 +34,8 @@ Massachusetts Institute of Technology - 1989The Open Group - 2004The Open Group + 19892004 + The Open Group X Version 11, Release 6.8 @@ -59,9 +74,7 @@ in this Software without prior written authorization from The Open Group. - -TITLE - + Purpose and Goals @@ -179,9 +192,9 @@ XDMCP must be flexible enough to accomodate a variety of security mechanisms. - + - + Overview of the Protocol @@ -235,9 +248,9 @@ 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. - + - + Data Types @@ -315,9 +328,9 @@ number of ARRAY8 values to follow. - + - + Packet Format @@ -450,9 +463,9 @@ the Session ID should match the value sent in the preceding - + - + Protocol @@ -2805,9 +2818,9 @@ determine the status of the manager. - + - + Session Termination When the session is over, the initial connection with the display (the one @@ -2835,9 +2848,9 @@ should not be fixed between loading an otherwise idle system with spurious KeepAlive packets and not noticing that the manager host is down for a long time. - + - + State Diagrams @@ -3355,9 +3368,9 @@ Send Alive packet containing current status - + - + Protocol Encoding When XDMCP is implemented on top of the Internet User Datagram Protocol (UDP), @@ -3617,9 +3630,9 @@ Note that these three packets are identical except for the opcode field. 1 CARD8 Session Running (0: not running 1: running) 4 CARD32 Session ID (0: not running) - + - + Display Class Format @@ -3652,9 +3665,9 @@ This string should be documented in the users manual for the particular device and should probably not be specifiable by the display user to avoid unexpected configuration errors. - + - + Manufacturer Display ID Format @@ -3699,9 +3712,9 @@ Manufacturer Display ID and the private key in the documentation set. This information should not be modifiable by the display user. - + - + Authentication @@ -3761,37 +3774,37 @@ Some definitions first: -{D}= encryption of plain text D by key κ +{&variable.D;}&variable.kappa; = encryption of plain text D by key &variable.kappa; -{Δ}*κ = decryption of crypto text Δ with key κ +{&variable.Delta;}*&variable.kappa; = decryption of crypto text &variable.Delta; with key &variable.kappa; -τ = private key shared by display and manager +&variable.tau; = private key shared by display and manager -ρ = 64 bit random number generated by display +&variable.rho; = 64 bit random number generated by display -α = authentication data in XDMCP packets +&variable.alpha; = authentication data in XDMCP packets -σ = per-session private key, generated by manager +&variable.sigma; = per-session private key, generated by manager -β = authorization data +&variable.beta; = authorization data @@ -3802,7 +3815,7 @@ shorter than 64 bits will be zero-filled on the right to 64 bits. Blocks longer than 64 bits will use block chaining: -{D}κ = {D1 }κ {D2 xor {D1 }κ }κ +{&variable.D;}&variable.kappa; = {&variable.D;1}&variable.kappa; {&variable.D;2 xor {&variable.D;1}&variable.kappa;}&variable.kappa; @@ -3812,23 +3825,22 @@ packet: -αRequest = {ρ}τ - +&variable.alpha;Request = {&variable.rho;}&variable.tau; For the Accept packet, the manager decrypts the initial message and returns -αAccept: +&variable.alpha;Accept: -ρ = {α Request } *τ +&variable.rho; = {&variable.alpha;Request}*&variable.tau; -α Accept = { ρ + 1}τ +&variable.alpha;Accept = { &variable.rho; + 1}&variable.tau; @@ -3844,7 +3856,7 @@ packet contains the authorization name "XDM-AUTHORIZATION-1". The authorization data is the string: -β Accept = {σ}τ +&variable.beta;Accept = {&variable.sigma;}&variable.tau; @@ -3853,20 +3865,20 @@ using the XDM-AUTHORIZATION-1 authorization protocol, the client computes the following: -N mark = "X client identifier" +&variable.N; = X client identifier -T lineup = "Current time in seconds on client host (32 bits)" +&variable.T; = Current time in seconds on client host (32 bits) -β = {ρNT}σ +&variable.beta; = {&variable.rho;&variable.N;&variable.T;}&variable.sigma; -For TCP connections @N@ is 48 bits long and contains the 32-bit IPv4 address of +For TCP connections &variable.N; is 48 bits long and contains the 32-bit IPv4 address of the client host followed by the 16-bit port number of the client socket. Formats for other connections must be registered. -The resulting value, β, is 192 bits of authorization data that is sent +The resulting value, &variable.beta;, is 192 bits of authorization data that is sent in the connection setup to the server. The server receives the packet, decrypts the contents. To accept the connection, the following must hold: @@ -3874,22 +3886,21 @@ decrypts the contents. To accept the connection, the following must hold: -ρ must match the value generated for the most recent XDMCP negotiation. +&variable.rho; must match the value generated for the most recent XDMCP negotiation. -T must be within 1200 seconds of the internally stored time. If no time -been received before, the current time is set to @T@. +&variable.T; must be within 1200 seconds of the internally stored time. If no time +been received before, the current time is set to &variable.T;. -No packet containing the same pair (N, T) can have been received +No packet containing the same pair (&variable.N;, &variable.T;) can have been received in the last 1200 seconds (20 minutes). - -- cgit v1.2.3