Comments about the test

Category

Commentaries

This test verifies that NUT ignores the ESP packet of invalid padding.

The test results WARN because NUT accepts the ESP packet of invalid padding, the ESP packet is encrypted with DES-CBC and padding bytes are all zero. The padding bytes for DES-CBC MUST be increasing sequence numbers, and it SHOULD be inspected by NUT.

References

RFC 2406

2.4  Padding (for Encryption)

   If Padding bytes are needed but the encryption algorithm does not
   specify the padding contents, then the following default processing
   MUST be used.  The Padding bytes are initialized with a series of
   (unsigned, 1-byte) integer values.  The first padding byte appended
   to the plaintext is numbered 1, with subsequent padding bytes making
   up a monotonically increasing sequence: 1, 2, 3, ...  When this
   padding scheme is employed, the receiver SHOULD inspect the Padding
   field.  (This scheme was selected because of its relative simplicity,
   ease of implementation in hardware, and because it offers limited
   protection against certain forms of "cut and paste" attacks in the
   absence of other integrity measures, if the receiver checks the
   padding values upon decryption.)

3.4.5  Packet Decryption

       1. decrypts the ESP Payload Data, Padding, Pad Length, and Next
          Header using the key, encryption algorithm, algorithm mode,
          and cryptographic synchronization data (if any), indicated by
          the SA.
               - If explicit cryptographic synchronization data, e.g.,
                 an IV, is indicated, it is taken from the Payload
                 field and input to the decryption algorithm as per the
                 algorithm specification.
               - If implicit cryptographic synchronization data, e.g.,
                 an IV, is indicated, a local version of the IV is
                 constructed and input to the decryption algorithm as
                 per the algorithm specification.
       2. processes any padding as specified in the encryption
          algorithm specification.  If the default padding scheme (see
          Section 2.4) has been employed, the receiver SHOULD inspect
          the Padding field before removing the padding prior to
          passing the decrypted data to the next layer.
       3. reconstructs the original IP datagram from:
               - for transport mode -- original IP header plus the
                 original upper layer protocol information in the ESP
                 Payload field
               - for tunnel mode -- tunnel IP header + the entire IP
                 datagram in the ESP Payload field.


RFC 2451

2.4 Block Size and Padding

   All of the algorithms described in this document use a block size of
   eight octets (64 bits).

   Padding is used to align the payload type and pad length octets as
   specified in [Kent98].  Padding must be sufficient to align the data
   to be encrypted to an eight octet (64 bit) boundary.

5. References

   [Kent98]    Kent, S. and R. Atkinson, "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998.

Notes

Implementors information