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

Re: Calling the question: derived vs. explicit IV

   Date: Wed, 6 Aug 97 13:57:43 GMT
   From: "William Allen Simpson" <wsimpson@greendragon.com>

   > In addition the handling of sequence number wrapping means that there is
   > yet another compatibility issue.  This can be solved having the ESP
   > engine know something about whether the key management was manually done
   > or not.  However, that's an abstraction violation, and it certainly adds
   > to the complexity of the implementation simply to have this
   > "compatibility".

   Please indicate where RFC-1829 supports "sequence number wrapping"?

RFC-1829 doesn't.  However, new implementations --- the ones which we
are trying to get out the door and shipping quickly --- will have to
deal with sequence number wrapping if we're worried about RFC-1829
compatibility, since for manual keying your draft specifies that the
sequence number starts at some random point (and wraps), whereas for
automatic keying, the sequence number starts at zero, and doesn't wrap.

   > No so.  The fielded units do not support key management.  The assumption
   > which I'm making here is that manual keying will continue to use RFC
   > 1829.

   Are you saying that there will be two (or more) supported domains of
   interpretation, one for manual keying and another for Oakley/ISAKMP?

DOI is a ISAKMP term.  As such, it doesn't make sense for manual keying.

   Are you saying that it will be the official policy of the IETF that
   RFC-1829 and its successors will advance to Internet Standard as the
   method to use for manual keying?

That depends on whether there is any vendor and market interest in
manual keying and backwards compatibility with the old boxes.  I have
been told that most vendors what to get away from manual keying as fast
as they can.  If there's no interest in manual keying, then we can let
RFC-1829 either (a) not advance, or (b) go to historic.  That however,
is not a matter that this working group needs to decide now.

   >     5) Any change to explicit must show GREATER cryptographic strength.
   >
   >        Derived has been show to give somewhat stronger protection of the
   >        first block than explicit.  Estimates are from 2**7 to 2**16
   >        depending on environment.
   >
   > Not true.  We will be using an MAC to protect the packets against other
   > attacks; this means that your posited attack of being able to modify the
   > first block is simply not an issue.

   Is a MAC required or optional?

The MAC is optional; however, if it isn't there, then obviously data
integrity wasn't required or important.  If data integrity is a
requirement, then you should be using a MAC.

							- Ted
References: