RX Kerberos 5 security class requirements of Kerberos library

[Sam Hartman]

>>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:

    Marcus> Sam Hartman <hartmans at mit.edu> writes:
    >> >>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:
    >> 
    Marcus> I hope that answer's Sam's concerns regarding not going
    Marcus> through the KDC for this code path.
    >>  Not entirely.  I definitely think that when there is a KDC
    >> available that you should use it.  I'm willing to accept that
    >> you might want a fallback for talking to local services when
    >> you have a key and no network.
    >> 
    >> --Sam

    Marcus> Ok.  Let's talk about that.  How does the AFS
    Marcus> "server-side" client code know when the KDC is up?  

As I mentioned yesterday, this is not an AFS issue.  You're asking for
a feature from the Kerberos implementation; it's quite clear that it
is as useful (or useless) to AFS as it is to other servers that have a
client running on the server side.  The Kerberos implementation is in
a much better position to know if a KDC is available than the AFS
implementation.  The Kerberos implementation is in a much better
position to know what local Kerberos policy is than the AFS
implementation.  I'm proposing that AFS ask Kerberos for a service
ticket; Kerberos is good at getting those.  AFS tells Kerberos that it
has access to the server key and Kerberos should take advantage of
that fact if it is useful.  AFS clearly expects as high availability
as possible and expects minimum latency.

Today, I'm proposing that we implement that request from AFS by
generating a ticket in the client library.  But we're not making an
API guarantee to do that.  We could just as easily implement the API
by always going to the KDC; we'd decrease availability, it would be
kind of pointless but we could do it.  In the future, we may change
the implementation to be more complicated than just always printing a ticket.  We may try the KDC first, caching network timeouts.
We may have a configuration option that forces you to always go to the KDC.
We may use a local KDC if there is one.

If a Kerberos implementer ships a version of this API that you as a
AFS server admin don't like, then don't use their Kerberos
implementation.  I fully realize that a number of people will want to
just locally generate tickets.
So, MIT Kerberos will support that.
Today, that is going to be the only implementation.
In the future, that may or may not be the default but it will definitely be a configuration option.

We will almost certainly not default to just talk to the KDC and fail
if we cannot do that.  We probably will not default to talking to the
KDC unless we have a good mechanism to avoid delays on each request if
the KDC is consistently down.

    Marcus> What value is the KDC going to add in participating in
    Marcus> this process?  

The KDC is responsible for logging.  The KDC is responsible for
populating tickets with certain authorization data.

    Marcus> What use is another AFS server going to put
    Marcus> in whatever might be provided by the KDC that couldn't be
    Marcus> constructed directly by the remote server?  

The server(again, thinking of this as an AFS problem is the wrong
approach) may not have access to the data necessary to construct
authorization data.  The server may not be able to do transited realm
checking.

    Marcus> How can that
    Marcus> AFS server know that any such added data was in fact
    Marcus> authentic secure data added by the KDC and not just
    Marcus> something made up by another server with access to the
    Marcus> service key?  I can think of a lot of interesting things
    Marcus> that might be 

First, note that logging and authorization data have significant value
even if the client is trusted.  But if the server doesn't fully want
to trust someone with its key then it can expect attributes signed
with a public key inserted by the KDC.  That seems like a bad
deployment model but is possible.

    Marcus> done by some future KDC (though not very
    Marcus> many that present KDC's do) -- but I can't think of any
    Marcus> that are relevant to -localauth.

Yes, but as a Kerberos implementer, it's my job to provide correct
functionality.  And so I need to keep the option to go to the KDC and
in cases where I'm not sure I can construct things locally I should go
to the KDC.

    Marcus> Just to make life a bit interesting: here's something else
    Marcus> to consider.  For AFS, the most *useful* value the KDC
    Marcus> could add in the future would be to do an AFS "GetCPS"
    Marcus> call and fill in a list of groups that the user belongs
    Marcus> to, and construct an AFS PAC in the ticket it returns.
    Marcus> That means talking to ptserver in order to do this.  How
    Marcus> should this interact with "bos start <host> ptserver
    Marcus> -localauth"?

Several possibilities.  Use a different service principal for
ptserver; don't populate its tickets with gecps.  Provide padata for a
client to request that the KDC not contact the ptserver.  Have the
client provide a signed ptserver blob as encrypted authorization data
so the client can make a decision about whether getcps is useful.
Have the KDC not contact the ptserver if no instances are up.  Print
the ticket directly, possibly using a plugin to populate the getcps
data--after all you're on the same machine.


    Marcus> Some other cases besides "key and no network" are "network
    Marcus> and no kdc" and "partitioned network".  These might occur
    Marcus> during either planned (installation, routine maintenance)
    Marcus> or unplanned (something gets sick) activities.

Agreed.
I think that what I'm proposing works with them too.