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

[Greg Hudson <[e-mail]>]

Here are further thoughts on replay cache avoidance as it affects this
draft.

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 because a replay
attack assumes an active attacker, who could perhaps suppress the
original exchange, beat the original exchange with the replay, or
compromise the channel after authentication.  It is not totally
unreasonable to abandon case 1 as hopeless, but for the purpose of this
message I will assume we still care about it.

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

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

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.

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

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

Specific notes:

* The MUST in section 4 is not necessary for interoperability or
security, and as such ought to be a SHOULD.

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

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