Re: Last Call: 'Kerberized Internet Negotiation of Keys (KINK)' to Proposed Standard (fwd)

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Wed, Nov 30, 2005 at 11:07:35AM -0600, Nicolas Williams wrote:
> So the only place that KINK gets replay protection for free from
> Kerberos V is in the AP exchange.  So, how exactly does KINK get "replay
> protection of key management messages," a goal stated in the first
> paragraph of the introduction?  Did I miss something?

Yes, I missed something: every KINK message has an AP-REQ or AP-REP (or
KRB-ERROR).

The KINK "checksum" field and KINK_ENCRYPT payload use keys derived from
the session key of the Ticket, which would normally mean that Ticket
reuse implies key reuse which brings replay protection into question.
But the presence of an AP-REQ or AP-REP in the KINK message that is part
of the checksum input means that key reuse is not enough to lead to
replays, and the presence of timestamps in the Authenticator and AP-REP
enc part means that the inputs to the checksum cannot be replayed unless
time goes backwards, and the requirement that the AP-REP timestamps
match the AP-REQ timestamps provides replay protection to the client.

This also answers my question about reflection attacks.

Is this analysis correct?

Nico
--