RX Kerberos 5 security class requirements of Kerberos library

[Sam Hartman]

>>>>> "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
first.

I think such an API would be a good thing and I think we should work
on one.

The simplest approach is a gic_cred option that gives the keytab of
the service.

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.

--Sam