RX Kerberos 5 security class requirements of Kerberos library

[Douglas E. Engert]

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
> KDC.
> 
>> 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 
keytab.

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
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444