home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / isis / 231 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.9 KB  |  71 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: Re: Security in ISIS
  5. Message-ID: <1992Aug31.185652.21586@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. References: <barry.715250287@citr.uq.oz.au>
  8. Date: Mon, 31 Aug 1992 18:56:52 GMT
  9. Lines: 60
  10.  
  11. In article <barry.715250287@citr.uq.oz.au> barry@citr.uq.oz.au (Barry Kitson) writes:
  12. >Hi all,
  13. >
  14. >    Thanks for your previous response (Ken) but it's only
  15. >encouraging me :^)
  16.  
  17. Actually, thats what the user group is for!
  18.  
  19. >
  20. >    How well is security handled by Isis?  I know about the
  21. >authentication necessary for joining, or becoming a client of
  22. >a group (presenting "credentials"), and about the remote 
  23. >execution password requirements (a la UNIX), but are there any
  24. >other useful security mechanisms built in?  Does Isis do anything
  25. >to protect the RPCs from being replayed or edited?  
  26.  
  27. Now:
  28.   The current ISIS system is pretty weak; you would need to use Kerberos
  29.   (or DCE, which can be used with ISIS) and invoke Kerberos routines to
  30.   encrypt messages and generate signatures; the group join and client
  31.   interfaces in ISIS give you a chance to send in "credentials" which
  32.   the group can check and reject.
  33.  
  34.   ISIS also has a way to filter messages so that only messages from
  35.   acceptable sources are delivered.
  36.  
  37.   ISIS does not prevent you from replaying or editing messages, but
  38.   in practice it would be very hard to forge message origin information
  39.   or to "pun" by slipping messages into an ISIS message stream -- ISIS
  40.   has a great deal of channel state and messages that surprise it get
  41.   discarded.  Still, this is far from a security environment...
  42.  
  43. Future:
  44.  
  45.   Mike Reiter has written two TR's on a new, rigorous security architecture
  46.   that he is implementing as part of a new ISIS system being developed at
  47.   Cornell.  Mike's stuff is genuinely secure and goes well beyond this
  48.   set of current options.  Mike gets email as reiter@cs.cornell.edu.
  49.   The TR's are:
  50.  
  51. 92-1287* &\parbox[t]{5in}{How to Securely Replicate Services.  Michael
  52. Reiter and Kenneth Birman.  June 1992.}
  53.  
  54. 92-1269* &\parbox[t]{5in}{Integrating Security in a Group Oriented
  55. Distributed System (replaces 1239).  Michael Reiter, Kenneth Birman,
  56. and Li Gong.  February 1992}
  57.  
  58.   Mike's architecture covers all your objectives, could live within
  59.   an orange-book style multi-level security system, and does some nice
  60.   things to achieve fault-tolerance and security both at once...
  61. >
  62. >    Also, is there any time service available on Isis?
  63.  
  64. No, we leave this to the OSF and UI Atlas people... Sounds like you need
  65. DCE; then you can ask "can ISIS be used within DCE" and we can reply "sure".
  66. (This is no problem...)
  67. -- 
  68. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  69. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  70. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  71.