[2357] in Kerberos
Re: Local password validation (was: kerberizing xlock)
daemon@ATHENA.MIT.EDU (Joe Pato)
Sat Nov 7 04:12:28 1992
From: pato@APOLLO.HP.COM (Joe Pato)
Date: Fri, 6 Nov 92 13:36:27 EST
To: bcn@ISI.EDU (Clifford Neuman)
Cc: bf4grjc@socrates.MIT.EDU, bjaspan@Athena.MIT.EDU, kerberos@Athena.MIT.EDU
In-Reply-To: bcn@ISI.EDU (Clifford Neuman), thu, 5 nov 92 18:04:35
Also, there is no need to actually contact the local verification
service out of band. The verification can be done entirely by the
login program.
What you would do is initially request a ticket for the verification
service, use that ticket to construct an authenticator, then
immediately verify the ticket and authenticator from within the login
program using the "local verification" services key which is
presumably available to the login program since it runs as root.
You could simplify this even further if you were willing to write your
own code to do the verification, instead of using the code in the
Kerberos library. To do this, you would:
The OSF DCE Security library, leveraging Kerberos V5) provides this capability.
The sec_login_validate_and_cert_ident will both validate the user's password
(and obtain the user's TGT) and certify that the KDC is legitimate. It
obtains a ticket to the local machine principal and verifies that the KDC
shares a key with the machine. This call must be made by a privileged process
that has access to the machine principal's key (the system login code
qualifies) Unprivileged processes may make a simillar call that communicates
with a local privileged service that has access to the local machine
principal's key.
An unprivileged call sec_login_validate_identity exists for applications that
do not care to certify the KDC.
This approach for local authentication validation is not weaker[1] than
conventional local authentication. In any case the mechanism requires the
local machine to be resistent to attack. In this model, the local machine
principal's key must be protected, in the conventional unix case the
/etc/passwd file must be protected from modification. In either case breaking
local protections will compromise the authentication path.
[1] Using the network KDC for user authentication is weaker than a purely local
authentication path in the sense that the machine is now subject to attacks
both locally and at the KDC machine. It also subjects the local machine to
attacks on the network authentication protocol. Assuming that the protocol is
strong and that the KDC is appropriately protected, then the problem reduces to
the issue of protection of local data.
-- Joe Pato
Distributed Computing Program / East
Hewlett-Packard Company
pato@apollo.hp.com
-------
