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

RE: Derived versus Explicit IV




>Ted is somewhat confused.
>
>The mandatory to implement _manually_ configured algorithm is
>ciph-des-derived.

No, Bill, you are confused.  The mandatory cipher algorithm mentioned is
a relic from the days when we only had one DES transform.  Now that we
have different flavours of DES transforms (thanks to you), the mandatory
cipher algorithm needs to be more clearly defined.  This is why the
point was raised in the first place.

> 1) There are no vendors shipping anything else.

RFC1829 allows for both a derived IV and an explicit IV.

But are you saying that these vendors who have already shipped RFC1829
compliant products do not wish to upgrade their product to the newer
IPSec standard?
>
> 2) There is no technical rationale supporting a change to an explicit IV.

Why are we changing to explicit IV when we have been there all along?
Through all of the changes that have taken place for ESP and AH, I don't
remember not having explicit IV in my code.  The 32-bit IV derived to
64-bits was a hack for the sake of alignment.

> 3) There is no increase in cryptographic strength with an explicit IV.

So why should we change to derived IV then?

> 4) A change to explicit IV would "obsolete" thousands of fielded units,
>    and create a user support nightmare.

We had made the decision to obsolete RFC1829 a long time ago.

>However, there was a "gentlemans' agreement" that ISAKMP could negotiate
>an explicit IV for single DES when it was so configured.  And some
>vendors (but not all) at the ANX workshops tested such a configuration.

At the last ANX bakeoff, no one tested such an attribute, since your
DERIVED IV ESP algorithms did not yet exist.

>To quote Moskowitz on another list, with respect to ISAKMP:
>    Date: Thu, 03 Jul 1997 10:20:45 -0400
>    From: Robert Moskowitz <rgm3@chrysler.com>
>    As co-chair I state that we will give the workgroup a reasonable
>    (end-of-july) time to determine a direction, if not, the market decides
>    this one.

What planet are you on?  All of the developers that spoke up clearly
stated that they did not wish to implement yet another useless
negotiation attribute. 

>Unfortunately, Bob forgot to tell the WG he had made this direction.
>
>Another "gentlemans' agreement" was that only 3des-derived would be
>published as output of this WG, since nobody had documented or tested
>explicit IV for 3DES, and at least 2 vendors had shipped derived IV
>based on RFC-1851.

RFC1851 states that it can have either an explicit IV or a derived IV.
draft-ietf-ipsec-esp-3des-md5 uses an EXPLICIT IV or a CONSTANT IV.

In fact after going through all of the ESP transform/algorithm drafts
that I could find, I found that all of them could handle EXPLICIT IV
(except your new drafts).  Some also handled a CONSTANT IV, while the
older ones also handled a DERIVED IV.  

Vendor's who released implementations on draft documents or on RFCs that
have been obsoleted obviously realized that the protocol would change
and they would have to upgrade their IPSec implementation.

DERIVED IV is something that you brought back from the dead after your
lengthy absence from the IPSec wg.  All of the ESP drafts had already
moved on and evolved.  Why are you trying to de-evolve the IPSec
protocols back to 1996 ?