home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / kerberos / 589 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.1 KB
  1. Xref: sparky comp.protocols.kerberos:589 comp.unix.ultrix:6233
  2. Path: sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!amber!cavedog.athena.lkg.dec.com!mamros
  3. From: mamros@athena.lkg.dec.com (Shawn Mamros)
  4. Newsgroups: comp.protocols.kerberos,comp.unix.ultrix
  5. Subject: Re: is kadmind exportable as a binary? if so, begging letter.
  6. Message-ID: <716243@athena.lkg.dec.com>
  7. Date: 13 Aug 92 23:18:43 GMT
  8. References: <ggm.713673084@brolga>
  9. Sender: mamros@cavedog.athena.lkg.dec.com (Shawn Mamros)
  10. Reply-To: mamros@athena.lkg.dec.com (Shawn Mamros)
  11. Organization: Digital Equipment Corporation
  12. Lines: 33
  13.  
  14.  
  15. ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
  16. >    I suspect that DEC's product actually does something less than
  17. >    full encyption of the packet, but there don't seem to be
  18. >    halfway house #ifdefs in the V4 bones code to cope with this.
  19.  
  20. This is not true.  From experience, I can tell you that code compiled with
  21. the MIT libkrb.a and libdes.a is compatible with code compiled with the
  22. ULTRIX versions of those libraries.  The only difference is that the
  23. ULTRIX libraries don't have any routines which allow encryption of raw data -
  24. any functions or programs which need to encrypt/decrypt have the algorithm
  25. in-lined into them.  The algorithm itself is the same.
  26.  
  27. As far as the Kerberos daemon itself is concerned, there are only a few
  28. lines different between the MIT code and the ULTRIX code, none of which
  29. have to do with encryption.
  30.  
  31. As an experiment, I tried just now running an ULTRIX Kerberos daemon with
  32. an MIT kadmind, and the MIT kadmin client.  Worked fine here.
  33.  
  34. My guess is that there's something different between your DES routines
  35. and the ones MIT used.
  36.  
  37. With regards to the exportability issue, from what I've seen getting export
  38. permission is not difficult providing you can prove that what you ship
  39. doesn't allow encryption of random data streams.  Encryption for the purposes
  40. of authentication is OK; "encryption for encryption's sake" is not.
  41.  
  42. Disclaimer: I'm not speaking as any sort of "official representative", merely
  43. as one who has access to both ULTRIX and MIT sources.
  44.  
  45. -Shawn Mamros
  46. E-mail to: mamros@athena.lkg.dec.com
  47.