Subject: Re: KINK issues

From: Ken Raeburn <[email-masked]>
Date: 07 Aug 2001 01:23:01 +0100

>    Actually, the current draft doesn't need fine control
>    at all. It's directly feeding the authctx->keyblock->contents
>    into the IKE key derivation as a substitute for the IKE
>    main mode SKEYID. This is very straightforward.

>    The current approach doesn't use the subkey at all,
>    favoring the IKE nonces Ni, Nr instead.

Yes, this looks fine.

>    Yes, I agree. The Packetcable IPsec and SNMP keying used
>    the subkey and it would have probably been a lot more 
>    straightforward if there were an RFC to point to which
>    has been well thought out rather than having to roll
>    your own and wonder whether it was secure. I know that
>    we spent a *lot* of time talking about key derivation
>    considerations.

Yep... one of these days....

>    OK. Like I said, it wasn't clear when I was implementing
>    this with the MIT code what I should do for the IV. Maybe
>    a mention in the spec that "if an initialization vector is
>    required for the cipher, the initialization vector must be
>    randomly chosen by the KINK encyption routine and added
>    in a cipher depended way to the ciphertext"?

Kerberos doesn't carry along the IV with encrypted data.  For CBC mode
ciphers, it uses an IV which is usually fixed, and prepends a random
confounder to the plaintext; the effect is similar to sending along
the encrypted IV with the ciphertext.  Future cryptosystems would do
the same, or something similar, to frustrate an attacker.  So
specifying the IV shouldn't be necessary if you're using the Kerberos
encryption schemes; why do you want to add it?  (It's also unlikely
that kerberos-revisions will allow arbitrary specification of the IV.)

---

From: Michael Thomas <[email-masked]>
Date: Tue, 7 Aug 2001 05:53:36 -0700 (PDT)

> that kerberos-revisions will allow arbitrary specification of the IV.)

   Great. I just saw what appeared to be an extra 8 bytes
   which was clearly not padding and wasn't quite sure what it
   was (iv/confounder). I'm mainly being pedantic here in case
   somebody who didn't grab the MIT (or other Kerberos) source
   and wanted to apply the encryption algorithm would understand
   how to interpret the spec correctly. I think what I'm going
   to do is hunt down the correct section in 1510 and add a 
   reference which should settle this once and for all.

	     Mike