How to prevent hosts (clients) with no keytab from obtaining tickets

[Ken Raeburn]

On Nov 28, 2007, at 13:33, Steven Miller wrote:
> I've set verify_ap_req_nofail in krb5.conf and hosts
> without a keytab can still connect and obtain tickets.
> Am I misunderstanding what this option does?

It has nothing to do with getting tickets, as such, but figuring out  
whether to trust them.

An attacker on the net can send a fake KDC reply encrypted using a  
password known to an attacker sitting at the keyboard -- and here I  
don't mean "keyboard" literally; it could be a remote login attempt,  
if a password prompt is given -- and decrypting it proves nothing  
about the validity of the KDC, it only proves that the supposed KDC  
and the user getting the password challenge both know the same  
password.  Successfully running "kinit" means about as much security- 
wise as creating a file /tmp/krb5cc_12345 with some random junk in  
it, unless you've got some exceptional circumstances, like maybe a  
local KDC and no active network interface.

The verify_init_creds routine attempts to figure out if the tickets  
are from a legitimate KDC, by using them to authenticate to the local  
"host" service (with an "ap_req" message), and using a local keytab  
to decrypt them; if it succeeds, the user has authenticated via the  
real KDC, and if it fails, something went wrong.  That could be an  
attack, or a network problem in the second exchange, or a missing  
keytab file on a misconfigured server, or perhaps other issues.

In some environments (like MIT's Athena, and perhaps your  
environment), many random client workstations are set up without  
keytab files (and without any interesting local secrets to protect,  
like users' files or email, which are all accessed through an  
authenticated network service) and without remote login access, so  
the login password prompt is more about automatically setting up the  
user's single-sign-on access, and maybe presenting a small barrier to  
someone walking in off the street, than trying to protect an  
unprivileged computer with no interesting secrets that the supposed  
attacker already has physical access to.  (The pros and cons of such  
an environment, and the threat models that permit or prohibit such  
things, can be debated elsewhere.)  So the verify_ap_req_nofail  
option (which can be overridden in the application, if desired) lets  
you specify whether the keytab entry not existing (presumably because  
the machine isn't configured for one, and not because the service is  
registered but the keytab is missing or corrupted) should be  
considered an error or not.

Note that programs like kinit, which don't give any privileges the  
user doesn't already have, have no reason to use verify_init_creds  
(and, without root access to read the keytab, can't use it properly  
anyways).  And of course random network services that get sent  
credentials from the client always do their verification using  
keytabs.  It's only in programs that ask for passwords *and* give  
some kind of access (like allowing logins on machines with state to  
be protected) that need to make these sorts of checks.

Ken