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

"KAMADA Ken'ichi" <[email protected]> Wed, 30 Nov 2005 11:42:00 +0900
Newsgroups gmane.ietf.kink,gmane.ietf.krb-wg
Message-ID <20051130114200EX%[email protected]>
At Tue, 29 Nov 2005 15:39:04 -0600,
Nicolas Williams <[email protected]> wrote:
> 
> > I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is 
> > used, only that it
> > "is encrypted using the encryption algorithm specified by the etype of the 
> > session key"
> 
> Hmmm, mumble, mumble, reflection attacks, mumble, mumble.
> 
> Shouldn't KINK derive separate keys for each direction for the "cksum"
> and KINK_ENCRYPT payload fields?  Or is there inherent protection from
> reflection attacks in the actual message flow?

The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP) with the
Cksum field.
I thought it is enough to prevent reflection.  Isn't it?

-- 
KAMADA Ken'ichi <[email protected]>