diff -urwb X11R6.6/xc/doc/specs/XDMCP/xdmcp.ms release1/cvs-ro/xc/doc/specs/XDMCP/xdmcp.ms --- X11R6.6/xc/doc/specs/XDMCP/xdmcp.ms Thu Aug 17 12:42:20 2000 +++ release1/cvs-ro/xc/doc/specs/XDMCP/xdmcp.ms Sat Dec 6 05:22:41 2003 @@ -1,5 +1,7 @@ .\" Use eqn, tbl, and -ms +.\" $XdotOrg: xc/doc/specs/XDMCP/xdmcp.ms,v 1.1.4.2 2003/12/06 13:22:41 kaleb Exp $ .\" $Xorg: xdmcp.ms,v 1.3 2000/08/17 19:42:20 cpqbld Exp $ +.\" $XFree86: xc/doc/specs/XDMCP/xdmcp.ms,v 1.3 2003/11/22 04:50:59 dawes Exp $ .EQ delim @@ define oc % "\\fR{\\fP" % @@ -16,11 +18,11 @@ .ce 7 \s+2\fBX Display Manager Control Protocol\fP\s-2 -\s+1\fBVersion 1.0 +\s+1\fBVersion 1.1 DRAFT -X Consortium Standard +X.Org Standard -X Version 11, Release 6.4\fP\s-1 +X Version 11, Release 6.7\fP\s-1 .sp 4 .ce 5 \s-1Keith Packard @@ -32,7 +34,7 @@ .br \& .sp 15 -Copyright \(co 1989 X Consortium +Copyright \(co 1989, 2002 The Open Group .sp 3 .LP Permission is hereby granted, free of charge, to any person obtaining a copy @@ -48,16 +50,16 @@ 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 -X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +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. .LP -Except as contained in this notice, the name of the X Consortium shall not be +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 X Consortium. +in this Software without prior written authorization from The Open Group. .LP .sp 3 -\fIX Window System\fP is a trademark of X Consortium, Inc. +\fIX Window System\fP is a trademark of The Open Group. .de PT .ie o .tl 'XDMCP''X Display Manager Control Protocol ' .el .tl 'X Display Manager Control Protocol ''XDMCP' @@ -1691,8 +1693,12 @@ .XE .LP When XDMCP is implemented on top of the Internet User Datagram Protocol (UDP), -port number 177 is to be used. -The version number in all packets will be 1. +port number 177 is to be used. When using UDP over IPv4, Broadcast Query +packets are sent via UDP broadcast. When using UDP over IPv6, Broadcast Query +packets are sent via multicast, either to an address in the IANA registered +XDMCP multicast address range of FF0\fIX\fP:0:0:0:0:0:0:12B +(where the \fIX\fP is replaced by a valid scope id) or to a locally assigned +multicast address. The version number in all packets will be 1. Packet opcodes are 16-bit integers. .RS .TS @@ -2051,10 +2057,13 @@ In an unsecure environment, the display must be able to verify that the source of the various packets is a trusted manager. These packets will contain authentication information. As an example of such a system, the -following discussion describes the "XDM-AUTHENTICATION-1" authentication -system. This system uses a 56-bit shared private key, and 64 bits of -authentication data. An associated example X authorization protocol -"XDM-AUTHORIZATION-1" will also be discussed. The 56-bit key is represented +following discussion describes the "XDM-AUTHENTICATION-1" and +"XDM-AUTHENTICATION-2" authentication systems. The "XDM-AUTHENTICATION-1" +system uses a 56-bit shared private key, and 64 bits of +authentication data. "XDM-AUTHENTICATION-2" uses a 256 bit shared private key, +and 256 bits of authentication data. Associated example X authorization +protocol "XDM-AUTHORIZATION-1" and "XDM-AUTHORIZATION-2" will also be +discussed. The 56-bit key is represented as a 64-bit number in network order (big endian). This means that the first octet in the representation will be zero. When incrementing a 64-bit value, the 8 octets of data will be interpreted in network order (big endian). @@ -2096,13 +2105,19 @@ beta lineup = "authorization data" .EN .LP -Encryption will use the DES; blocks shorter than 64 bits will be zero-filled -on the right to 64 bits. Blocks longer than 64 bits will use block chaining: +"XDM-AUTHENTICATION-1" encryption will use the Data Encryption Standard (DES, +FIPS 46-3); blocks shorter than 64 bits will be zero-filled on the right to +64 bits. Blocks longer than 64 bits will use block chaining: .EQ 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 .EN .LP +"XDM-AUTHENTICATION-2" encryption will use the Advanced Encryption Standard +(AES, FIPS-197); blocks shorter than 128 bits will be zero-filled on the right +to 128 bits. Blocks longer than 128 bits will use block chaining as shown +above. +.LP The display generates the first authentication data in the .PN Request packet: @@ -2148,7 +2163,7 @@ beta lineup = oc rho N T cc sup sigma .EN .LP -For TCP connections @N@ is 48 bits long and contains the 32-bit IP address of +For TCP connections @N@ is 48 bits long and contains the 32-bit IPv4 address of the client host followed by the 16-bit port number of the client socket. Formats for other connections must be registered. The resulting value, @beta@, is 192 bits of authorization data that is sent @@ -2162,6 +2177,15 @@ .IP \(bu 5 No packet containing the same pair (@N@, @T@) can have been received in the last 1200 seconds (20 minutes). +.LP +``XDM-AUTHORIZATION-2'' is identical to ``XDM-AUTHORIZATION-1'', except that +for TCP connections @N@ is 256 bits long and contains the 128 bit +IPv6 address of the client host followed by the 16 bit port number of the +client socket, with the remainder filled with zeros, and @T@ is extended to +64-bits. IPv4 addresses are represented as IPv4-mapped IPv6 addresses, with +an 80-bit prefix of zero bits, followed by a 16-byte value of 0xFFFF, +followed by the IPv4 address value, as defined in IETF RFC 2373. Formats for +other connections must be registered. .bp .EH '''' .OH ''''