RX Kerberos 5 security class requirements of Kerberos library
hartmans at MIT.EDU
Tue Jan 2 14:38:35 EST 2007
>>>>> "Derrick" == Derrick J Brashear <shadow at dementia.org> writes:
Derrick> On Tue, 2 Jan 2007, Sam Hartman wrote:
Jeffrey> Without krb5_generate_creds_with_keytab there are two
Jeffrey> alternatives that AFS can pursue:
Jeffrey> (1) AFS can use the keytab entry to query the KDC for a
Jeffrey> ticket for itself. Doing so removes the ability of
Jeffrey> multiple AFS services on the same machine to communicate
Jeffrey> when the network connection goes down unless there is a
Jeffrey> KDC instance on the machine.
>> I think that this is a far better design for AFS.
Derrick> Convincing people to put a KDC on every machine? Assuming
Derrick> I believed it was a good idea, could existing propagation
Derrick> schemes even reasonable handle that? Telling people "your
Derrick> server which is geographically isolated cannot have even
Derrick> basic maintenance performed on it if you are
Derrick> network-isolated" isn't particularly desirable, and I'd
Derrick> not consider it viable.
What's absolutely clear to me is that this is not an AFS issue.
Either we want to have an API that is designed to get credentials for
local maintinance or we do not. That API should not be afs specific
and if we have it, it needs to be something we're happy for other
services to use.
I've been thinking about this some and it seems like if the API
contract is that we'll go and use the appropriate mechanism to get
credentials knowing that we have a key for the service. If you're in
an environment where authorization data is needed, you may need to go
to a KDC. If you have been configured you may prefer to go to a kdc
I think such an API would be a good thing and I think we should work
The simplest approach is a gic_cred option that gives the keytab of
That's a simple API, but is probably hardish to implement. So, I'd be
happy with a convenience API that took two keytabs--one for the client
and one for the server.
The initial implementation would
* Confirm there is a client principal key in the client keytab.
* Print up tickets for the service principal using the service keytab.
IN the future the API might support more complicated configurations including going to the KDC when appropriate.
More information about the krbdev