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:39:04PM -0600, Nicolas Williams wrote:
> On Tue, Nov 29, 2005 at 03:57:40PM -0500, Chaskiel M Grundman 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?

Well, I also note stuff like: "[The XID] is not used for replay
protection because that functionality is provided by Kerberos."

But KINK isn't using KRB-SAFE or KRB-PRIV, it's using raw KCRYPTO!

So the only place that KINK gets replay protection for free from
Kerberos V is in the AP exchange.  So, how exactly does KINK get "replay
protection of key management messages," a goal stated in the first
paragraph of the introduction?  Did I miss something?


Another problem is that there seems to be no way of tying a particular
KINK message, making use of a Kerberos V key, to a given AP exchange/
Ticket.  This might be fine for a KE that follows the IKEv1/RFC2401
model, but it seems to me that it isn't fine in an IKEv2/RFC2401bis
world.



Nico
--