home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / windows / x / 20746 < prev    next >
Encoding:
Text File  |  1993-01-05  |  3.4 KB  |  70 lines

  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!UB.com!quack!mrapple
  3. From: mrapple@quack.sac.ca.us (Nick Sayer)
  4. Subject: How do I generate valid XDM-AUTHORIZATION-1 ?
  5. Message-ID: <fXxsqnx@quack.sac.ca.us>
  6. Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
  7. Date: 5 Jan 1993 01:54:23 UTC
  8. Lines: 60
  9.  
  10. Once again, X11R5, SunOS 4.1.3, ELC.
  11.  
  12. Through a little trial and lots of error, I've managed to get xdm to use
  13. XDM-AUTHORIZATION-1 with my X terminal (an Xkernel sun3. I had to set
  14. up a keyFile and add a -cookie argument to the sun3's Xsun).
  15. Now for my ELC itself. If I attempt to create a random hex string
  16. (like an MIT-MAGIC-COOKIE-1) and call that an XDM-AUTHORIZATION-1,
  17. it fails (Xlib's 'not authorized' error). If I run xdm on the console
  18. frame buffer, it will generate an auth file with BOTH
  19. MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1. Which is fine. If I
  20. remove the xauth file and recreate it with just the XDM-AUTHORIZATION-1
  21. lines XDM generated, that's fine too. If I then save one of these auth
  22. cookies XDM generated, then manually start Xsun up with -auth pointing to
  23. a file with the previously generated (by xdm) XDM-AUTHORIZATION-1,
  24. that works. If I try to set up an xauth file with an XDM-AUTHORIZATION-1
  25. made originally for any other server, that doesn't work.
  26.  
  27. So there appears to be some component of the XDM-AUTHORIZATION-1
  28. widget that is dependent on the display ID. This is contrary to
  29. the Xsecurity man page:
  30.  
  31.      XDM-AUTHORIZATION-1
  32.           For sites in the US, Release  5  contains  a  DES-based
  33.           access  control  mechanism  called XDM-AUTHORIZATION-1.
  34.           It is similar in usage to MIT-MAGIC-COOKIE-1 in that  a
  35.           key  is  stored  in  the .Xauthority file and is shared
  36.           with the X server.  However, this key consists  of  two
  37.           parts - a 56 bit DES encryption key and 64 bits of ran-
  38.           dom data used as the authenticator.
  39.  
  40.           When connecting to the X server, the  application  gen-
  41.           erates  192  bits of data by combining the current time
  42.           in seconds (since 00:00 1/1/1970  GMT)  along  with  48
  43.           bits  of  "identifier".   For  TCP/IP  connections, the
  44.           identifier is the address plus port number;  for  local
  45.           connections  it is the process ID and 32 bits to form a
  46.           unique id (in case multiple  connections  to  the  same
  47.           server  are  made from a single process).  This 192 bit
  48.           packet is then encrypted using the DES key and sent  to
  49.           the  X server, which is able to verify if the requestor
  50.           is authorized to connect by decrypting  with  the  same
  51.           DES key and validating the authenticator and additional
  52.           data.  This system is useful in many environments where
  53.           host-based  access  control  is inappropriate and where
  54.           network security cannot be ensured.
  55.  
  56. It doesn't say anything special about one half of the key (56 bits really,
  57. but the last byte is ignored), and the other half is totally random.
  58.  
  59. So, how do I generate valid XDM-AUTHORIZATION-1 keys for use in
  60. conjunction with xinit?
  61.  
  62. By the way, is there a way around the -cookie / keyFile business to get
  63. xdm to use XDM-AUTHORIZATION-1 with an XDMCP display?
  64.  
  65. -- 
  66. Nick Sayer <mrapple@quack.sac.ca.us> | "Do you have to keep tapping like that,
  67. N6QQQ @ N0ARY.#NOCAL.CA.USA.NOAM     | you bloated sack of protoplasm?!"
  68. +1 408 249 9630, log in as 'guest'   | 
  69. PGP 2.1 public key on request        |              -- Captain Hoek
  70.