RX Kerberos 5 security class requirements of Kerberos library

[Marcus Watts]

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

Ok.  Let's talk about that.  How does the AFS "server-side" client code
know when the KDC is up?  What value is the KDC going to add in
participating in this process?  What use is another AFS server going to
put in whatever might be provided by the KDC that couldn't be
constructed directly by the remote server?  How can that AFS server
know that any such added data was in fact authentic secure data added
by the KDC and not just something made up by another server with access
to the service key?  I can think of a lot of interesting things that
might be done by some future KDC (though not very many that present
KDC's do) -- but I can't think of any that are relevant to -localauth.

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

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

					-Marcus