RX Kerberos 5 security class requirements of Kerberos library
Douglas E. Engert
deengert at anl.gov
Wed Jan 3 14:17:11 EST 2007
Nicolas Williams wrote:
> On Wed, Jan 03, 2007 at 12:00:53PM -0500, Jeffrey Altman wrote:
>> Nicolas Williams wrote:
>>> Well, no, I'm saying that for localauth AFS should use OS facilities,
>>> not Kerberos or any other security mechanism. And I'm saying that a
>>> Kerberos-based PSK mechanism should be more general if there will be one
>>> at all.
>>>> We can enforce the localauth case by how the client keytab is used.
>> The API will check that there exists a client keytab entry for the
>> specified client principal.
> But the API can't check that the key is correct without a trip to the
>> This way the function can only be used for localauth and cannot be used
>> to specify an
>> arbitrary client name to the service whose key is in the service keytab.
> Sorry, I find this lame. And I still have yet to hear what is so wrong
> with using OS facilities for local auth.
There might be a misconception as to what AFS means by the -localauth
parameter. It means get a token (i.e. k4 ticket) using the local KeyFile.
This token can then be used against another server. With AFS
all the servers have a copy of the KeyFile, or with K5 it would be a
For example as root without an AFS token running on server1 the command:
/usr/afs/bin/bos restart -server server2 -all -localauth
will restart the AFS procceses on server2.
Without the -localuath, server2 returns:
bos: you are not authorized for this operation ...
Its not clear if the "OS facilities for local auth" you are referring
to could handle this across two servers.
> krbdev mailing list krbdev at mit.edu
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the krbdev