[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: 'Kerberized Internet Negotiation of Keys (KINK)' to Proposed Standard (fwd)
On Tue, Nov 29, 2005 at 03:57:40PM -0500, Chaskiel M Grundman wrote:
> --On Tuesday, November 29, 2005 12:41:38 -0600 Nicolas Williams
> <Nicolas.Williams@xxxxxxx> wrote:
> > - Sub-session key generation.
> > [...]
> kink actually proscribes the use of sub-session keys:
> 4 KINK Message Format[....]
> o Cksum (variable) -- Kerberos keyed checksum over the entire
> message excluding the Cksum field itself.[...] The key used
> MUST be the session key in the ticket.
> 7 ISAKMP Key Derivation [....]
> o SKEYID_d is the session key in the Kerberos service ticket from
> the AP-REQ. Note that subkeys are not used in KINK and MUST be
> ignored if received.
> This issue has been discussed in the past (multiple times even), and
> bringing it up again will probably not result in anything other than wasted
> 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?