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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

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 
> time.

*nod*

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