home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / kerberos / 849 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.1 KB  |  61 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!news
  3. From: mit-eddie!harvard!scubed!flamingo.SanDiego.NCR.COM!donnh
  4. Subject: safe message problem: HP to 486
  5. Message-ID: <9211041932.aa01027@eddie.mit.edu>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. Date: Thu, 5 Nov 1992 00:07:44 GMT
  9. Lines: 50
  10.  
  11.  
  12. This is probably old news but here goes ...
  13.  
  14. We're trying to inteoperate between our i486 machine running a port of
  15. Kerberos 4.9 and an HP-9000 system running version 4.? (don't know the
  16. exact version). When receiving "safe" messages sent by the HP
  17. system, we fail comparing the checksums and reject the message. 
  18.  
  19. The 4.9 source tries to account for the different machine
  20. architectures by invoking swap_u_16() on one of the checksums before
  21. comparing the received checksum with that generated by des_quad_cksum
  22. on our side.  However, swap_u_16() swaps the ENTIRE 16 bytes as
  23. follows:
  24.    original bytes: 000102030405060708090a0b0c0d0e0f
  25.    after swap:     0f0e0d0c0b0a09080706050403020100
  26.  
  27. Unfortunately des_quad checksum() on the 486 returns:
  28.                    03020100070605040b0a09080f0d0e0c
  29. If one swaps the bytes in EACH long independently you get:
  30.                    000102030405060708090a0b0c0d0e0f
  31. Which is the same value as the checksum sent in the message!
  32.  
  33. It looks like the call to swap_u_16() should be changed to 4 calls to
  34. swap_u_long(), or swap_u_16() be changed to handle swapping within the
  35. long integers that make up the checksum. Alternatively swapping could
  36. be removed from rd_safe and des_quad_checksum changed to create a
  37. machine independent 16 or 32 byte value.
  38.  
  39. If this is a known bug is there a standard fix? I also assume that
  40. private message handling is impacted, but I haven't looked into it
  41. yet.
  42.  
  43. By the way the machine definitions for the 486 are:
  44.  
  45. #define BITS32
  46. #define BIG
  47. #define LSBFIRST
  48.  
  49. Any help would be appreciated.
  50.  
  51. Thanks in advance.
  52.  
  53. -- 
  54. Donn Holtzman                    Donn.Holtzman@SanDiegoCA.NCR.COM
  55. NCR LCPD-San Diego, MS 1240
  56. 16550 W. Bernardo Drive
  57. San Diego, CA 92127
  58.  
  59. Telephone: (619)485-3396        FAX: (619)485-2598
  60. VoicePlus: 440-3396
  61.