Re: Slicing and dicing

[Daniel Harkins <[e-mail]>]

  Steve,

  If a negotiated algorithm has a weak key and the check is not done then
there will be no rejection and hence no need for ISAKMP to support this
sort of notification. If the check is done then both sides will arrive at
the same conclusion and throw the thing away. Again, no need for such a
notification. If we decide to make things really ugly and allow a side to 
just decide to do a weak key check (did someone say "replay"?) then it can 
use a DELETE message to inform the other party that it didn't really like 
that SA and not to use it. (This can be used for other generic and probably 
more likely situations such as a malloc failing that results in the inability 
of KM to add the SA).

  Hence, there is no need for this. Of course, ISAKMP is sufficiently 
general that you can do this sort of thing in your implementation by using 
a private use notify number. That's the whole point. 

  It is possible, though, to add a new notify type and it's even possible 
to add a new negotiable attribute to say whether you do weak key checks and
also to add another payload in which you can specify the weak keys you 
check (with an algorithm field and a number of keys field). That way each 
side will have all the information on hand in case a weak key is found. But 
that is featureitis, a form of protocol cancer. 

  This whole discussion is evident of the problem of the IPSec WG. A question
is raised about confusing language in a draft-- do you check bytes 1-8 or
8-15 if bytes 0-7 are weak-- which then morphs into a discussion about whether
a popular book is wrong which morphs into statistical analysis of how often
weak keys are found which morphs into adding another feature into a protocol!

  We should all be ashamed. (And that's not neither the royal, medical, nor
law enfocement "we". I'm taking a heaping helping of blame).

  Dan.

> 	That defers the question of what to do for DES in CBC mode to the
> algorithm document itself.  Based on the current discussion, it looks like
> people are willing to just punt on this case, but I would likle to see a
> requirement in ISAKMP to support the generic rejection facility.  Is it
> reasonable to provide an error indication to the other end indicating the
> reason for the rejection, just in case implementations don't agree on the
> rejection (or at least for audit trail purposes)?