Replay cache avoidance

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Replay cache avoidance

Matt W. Benjamin-2
Hi,

----- "Nico Williams" <[hidden email]> wrote:

> I'd like to pick up and continue last week's #krbdev conversation
> about
> rcaches.
>
>    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.

Matt

--
Matt Benjamin
CohortFS, LLC.
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://cohortfs.com

tel.  734-761-4689
fax.  734-769-8938
cel.  734-216-5309
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Replay cache avoidance

Nico Williams
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
(see RFC4121).

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.)

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev