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