I'd like to pick up and continue last week's #krbdev conversation about
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 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
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.
On Mon, Sep 1, 2014 at 8:24 PM, Matt W. Benjamin <[hidden email]> wrote:
>> For example, NFS is such a protocol. There's no need to use an
>> rcache for the NFS service.
> Thank you for the confirmation. This has come up as an an issue for us with MIT Krb5.
Although you need to beware of a subtlety I only mentioned in passing:
you need to be using a "newer" enctype, which means AES or Camellia
For enctypes prior to RFC4121 there's no requirement that the
initiator use the sub-session key asserted by the acceptor. (I forget
if RC4 does it always, and what the interop matrix looks like for
3DES. 1DES, of course, is out.)