Replay cache avoidance

[Nico Williams]

I'd like to pick up and continue last week's #krbdev conversation about
rcaches.

I'll start several sub-threads.  This one will be about the most
important sub-topic: rcache avoidance.

We can avoid needing an rcache when:

 - We know that the application protocol is such that it doesn't need
   it, meaning:

    - it does mutual authentication

    - the server asserts a sub-session key that the client must use

    - the client must use that sub-session key before anything else
      happens in the protocol and before the server takes any actions.

   (We also need a strong service name to ticket binding in the case of
    multiple service principals for the same hostname sharing the same
    keys.)

   For example, NFS is such a protocol.  There's no need to use an
   rcache for the NFS service.

   SSHv2 is also such a protocol, but because it shares a service
   principal name (and keys) with other application protocols that do
   need a replay cache (e.g., rsh), a Kerberos service implementation
   needs more information before eliding the replay cache.

 - We can force more than one round trip, which requires a protocol
   extension.  More on this separately.

We should think of ways that a service / acceptor application can
provide the information we need to determine whether we need a ccache.
If in.rshd starts after sshd, the latter should automatically start
using an rcache.

Alternatively we could just leave it to local configuration.  This is
easier.  I.e., if one does not run in.rshd, in.rlogind, or in.telnetd in
weak configurations, then often there's no need for an rcache at all,
and it can just be disabled.

Replay cache avoidance is mostly a local matter, therefore progress can
be made without involving the IETF in any way.

The multi-round-trip extension is very useful for different reasons, so
we should pursue it anyways.

A usable rcache does open a number of possibilities though, which will
also be covered separately.

Nico
--