home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / kerberos / 836 < prev    next >
Encoding:
Text File  |  1992-11-06  |  2.8 KB  |  61 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!elroy.jpl.nasa.gov!ames!agate!stanford.edu!SOCRATES.MIT.EDU!bf4grjc
  3. From: bf4grjc@SOCRATES.MIT.EDU (Ravi Ganesan (301) 595-8439)
  4. Subject: Re: Local password validation (was: kerberizing xlock)
  5. Message-ID: <9211051900.AA01169@ramanujam.bell-atl.com>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. References: <9211051538.AA12053@portnoy.MIT.EDU>
  9. Date: Thu, 5 Nov 1992 19:00:50 GMT
  10. Lines: 49
  11.  
  12.  
  13. Barry,
  14.  
  15. > We have now come full circle.  Notice that the subject line in this
  16. > message contains "was: kerberizing xlock."  This entire conversation
  17. > began because people were discussing using Kerberos for local password
  18. > authentication, when it was not designed for that purpose.  
  19. > 
  20. > With public workstations (like those you described, and those at MIT's
  21. > Athena) the spoofability of public workstations is irrelevant.
  22. > However, when people start talking about using Kerberos for xlock, it
  23. > is clear that they *do* care about an imposter gaining access to a
  24. > workstation (particularly given that another user's credentials are
  25. > already available there).  In that case, the spoofing issue becomes
  26. > highly relevant.
  27. > 
  28. > So now, I think, the point has been made and everyone understands the
  29. > issues better.  That is, after all, part of the purpose of this
  30. > mailing list. :-)
  31. > 
  32. As per my earlier note (perhaps sent only to you), I just want to re-emphasize 
  33. the ground realities of maintaining multiple 'systems' for network 
  34. authentication and host authentication - kerberos WILL end up being used for 
  35. both, and subtelities about which environment it was designed for (anonymous
  36. workstations - MIT Athena) is nice to know, but is of little pracitcal 
  37. consequence. 
  38.  
  39. I feel that getting a ticket and then getting a service ticket and using that 
  40. service - under the condition the service is on the same machine, is a 
  41. theoretically messy, but practically convenient solution. (To recap a 
  42. hyper-kludgy hyper-quick and hyper-dirty way of doing this would be to 
  43. replace login with a combination of a kinit, a chown on the ticket, and then 
  44. a quick rlogin into the same machine. Naturally in practice you would set 
  45. up a dummy server that does something trivial like retun a YES/No 
  46. repsonse to your login program.
  47.  
  48. Ravi
  49. -- 
  50.  
  51.  
  52. *******************************************************************************
  53.  
  54. Ravi Ganesan                            e-mail: ravi@socrates.bell-atl.com
  55. IS SAS Corporate Network Planning       v-mail: (301) 595-8439
  56. Bell Atlantic                           Fax:    (301) 595-1341
  57.  
  58. Note: If your e-mail reply to me bounces, try sending it explicitly to 
  59. ravi@socrates.bell-atl.com instead of using the 'reply' feature.
  60. ******************************************************************************
  61.