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

Nicolas Williams wrote:
> 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?

That's pretty much how I remember it.

		Mike