home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / kerberos / 845 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.9 KB  |  60 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!think.com!ames!agate!stanford.edu!APOLLO.HP.COM!pato
  3. From: pato@APOLLO.HP.COM (Joe Pato)
  4. Subject: Re: Local password validation (was: kerberizing xlock)
  5. Message-ID: <9211061842.AA20985@Athena.MIT.EDU>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. Date: Fri, 6 Nov 1992 18:36:27 GMT
  9. Lines: 49
  10.  
  11. In-Reply-To: bcn@ISI.EDU (Clifford Neuman), thu, 5 nov 92 18:04:35
  12.  
  13.     Also, there is no need to actually contact the local verification
  14.     service out of band.  The verification can be done entirely by the
  15.     login program.  
  16.     
  17.     What you would do is initially request a ticket for the verification
  18.     service, use that ticket to construct an authenticator, then
  19.     immediately verify the ticket and authenticator from within the login
  20.     program using the "local verification" services key which is
  21.     presumably available to the login program since it runs as root.
  22.     
  23.     You could simplify this even further if you were willing to write your
  24.     own code to do the verification, instead of using the code in the
  25.     Kerberos library.  To do this, you would:
  26.     
  27. The OSF DCE Security library, leveraging Kerberos V5) provides this capability.
  28. The sec_login_validate_and_cert_ident will both validate the user's password
  29. (and obtain the user's TGT) and certify that the KDC is legitimate.   It
  30. obtains a ticket to the local machine principal and verifies that the KDC
  31. shares a key with the machine.  This call must be made by a privileged process
  32. that has access to the machine principal's key (the system login code
  33. qualifies)  Unprivileged processes may make a simillar call that communicates
  34. with a local privileged service that has access to the local machine
  35. principal's key.
  36.  
  37. An unprivileged call sec_login_validate_identity exists for applications that
  38. do not care to certify the KDC.
  39.  
  40. This approach for local authentication validation is not weaker[1] than
  41. conventional local authentication.  In any case the mechanism requires the
  42. local machine to be resistent to attack.  In this model, the local machine
  43. principal's key must be protected, in the conventional unix case the
  44. /etc/passwd file must be protected from modification.  In either case breaking
  45. local protections will compromise the authentication path.
  46.  
  47. [1] Using the network KDC for user authentication is weaker than a purely local
  48. authentication path in the sense that the machine is now subject to attacks
  49. both locally and at the KDC machine.  It also subjects the local machine to
  50. attacks on the network authentication protocol.  Assuming that the protocol is
  51. strong and that the KDC is appropriately protected, then the problem reduces to
  52. the issue of protection of local data.
  53.  
  54.                     -- Joe Pato
  55.                        Distributed Computing Program / East
  56.                        Hewlett-Packard Company
  57.                        pato@apollo.hp.com
  58.  
  59. -------
  60.