Re: [kitten] Kerberos extra round trips I-D revised

[Nico Williams <[e-mail]>]

On Tue, Nov 11, 2014 at 01:50:22PM -0500, Greg Hudson wrote:

FYI, I had a separate replay cache avoidance I-D that I'm looking to
abandon and replace with this one.  I didn't adopt all of the content of
that older I-D.

> Replay caches help in two cases:
> 
> 1. They provide minimal protection when a krb5 exchange takes place over
> an unprotected channel and is used for authentication only, with no use
> of the resulting key.  This protection is minimal [...]

This affects SSHv2 in particular because it shares a service name with
things like rsh/rlogin/telnet, and those aren't always configured to
protect the entirety of their sessions.

It also affects every service in environments where every host-based
service shares a single long-term key on the same host.

It might be nice to simply make this go away by using 1.5rt for the AP
exchange wherever possible.

> 2. They prevent an entire session from being replayed, causing a
> properly authenticated request to be processed twice within the replay
> window.  This is not a concern when an acceptor subkey is used.  (I
> assume that legitimate initiators don't use prot-ready messages or send
> wrap tokens using the initiator subkey.  I think in practice RFC 4121
> implementations don't set the prot-ready flag and initiators never use
> the initiator subkey.)

PROT_READY is nice to have, but only for data that is not too sensitive.
E.g., if the first message sent will be something like "list new
messages", then that's OK, but if it's going to be "list activity in
bank account #..." then it may not be.

> A krb5 acceptor implementation generally does not know whether the
> application protocol will use the context key or whether there is a
> different case 1 acceptor using the same long-term acceptor keys.

That and the above point about multiple host-based services sharing a
single long-term key on any given host in some environments.

> Because of this, it is intrinsically difficult for an implementation to
> know that it is safe not to use a replay cache for case 1.

Yes.

> The extra round trips draft allows the acceptor to ask an initiator to
> encrypt a nonce, which would defeat a replay attack if everyone had to
> do it.  However:
> 
> * There is an easy downgrade attack on the extra round trip.  Until
> client implementations are ubiquitous enough for acceptors to turn off
> support for basic RFC 4121, an attacker can simply suppress the extra
> round trip.

Speaking of which, I'd meant to also have an authz-data element for
indicating willingness to use extra round trips.

> * The first authenticator must still be added to the replay cache if it
> might be used for a case 1 acceptor--and if this acceptor would be a
> case 1 acceptor without the extra round trip, allowing basic RFC 4121
> means it is still a case 1 acceptor.

See above comment about authz-data.

> So this doesn't really seem to give us replay cache avoidance until
> basic RFC 4121 can be turned off.

Or, rather, until all mechanism acceptor implementations on a host can
be upgraded.

> * Section 2.2.1 states that after a recoverable error, a fifth token is
> not required because of the nonce in the second token.  I am not sure
> this is true--the nonce in the second token was not necessarily
> encrypted; if it wasn't, an attacker could feed it to a legitimate
> initiator in a separate exchange.

The nonce should be tied to a single partially-established security
context.  It should not be accepted on other new contexts.

> * For pedagogical purposes, section 4 should probably be explicit about
> what the initiator does in response to a KRB-ERROR2 with a KDC_ERR_NONE
> code.

OK.

Nico
--