[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: change in isakmp/oakley

  Hugo,

> >   Is the (non)mixing of Ni and Nr in encryption mode authentication broken
> > or does it just reenforce the brokenness of certain (as yet unnamed) prfs?
> 
> It may be closer to the latter, but still a MUST to fix.
> You have no "right" to give future implementations a rope to
> hung themselves..
> 
> We have put a lot of effort to have the protocol as robust as 
> possible. Security is not only resistance to known attacks,
> but resistance to tomorrow's attacker as well. And the specifications
> should be complete enough to provide robustness "against"
> tomorrow's implementers too.

  You're suggesting making this this modification to prevent a future prf,
that shortens its key if the key is too big, from resulting in a weakening of
the protocol. Since we're talking about hypothetical functions what about
a prf which uses a shorter key than it's output and also truncates its key.
We already have a prf which uses a larger key than it produces as output
(3DES-CBC-MAC) and since we're dealing in hypotheticals I don't think I'm out
in left field on this. 

  To prevent a weakening of the protocol and still accomodate these prfs 
should every instance of prf generation hash the key? For instance, SKEYID_d 
is created like so:

	SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
where
	SKEYID = prf( some authentication specific stuff here )

Now your concern about key truncation in the prf, taken a step further to 
accomodate those prfs which use a shorter key than their output, would 
lead us to the following:

	SKEYID_d = prf(hash(SKEYID | something), g^xy | CKY-I | CKY-R | 0)

to allow for proper mixing of the key before hashing. 

  I hope you see the tremendous rewrite necessary to accomodate future,
prfs which, in my opinion are already broken because they truncate the key.
In 100% of the cases (I feel confident in saying that because I don't think
anyone would use a prf which truncates the key) there will be unnecessary
hashing of keys before sending them to the prf (which in the case of HMAC
does hashing anyway if the key is "too big"). 

  You've said that the protocol isn't broken but should be changed to 
accomodate broken prfs. In spite of your insistance I'm going to respectfully
decline your suggestion. There's been several emails to the list (I'd kinda
hoped for more) and I've received private ones which I will share with you
if you like (and the author doesn't mind) and they're all of the mind to
just leave the document the way it is.

  I'll add verbage noting known security problems with prfs which truncate
their key but we already allow people to shoot themselves in the foot (they
can negotiate ROT-13, or-- this is coming on April 1st, 1998-- the new,
triple-ROT-13 with derived IV) and 2 bullet holes in a foot are just as 
painful as 1.

  regards,

    Dan.
References: