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

Re: [Ottawa bakeoff feedback] problem with ESP Padding

 How about using PKCS #5 style padding, which says:

The message M and a padding string PS shall be formatted into an octet
string EB, the encryption block.

EB = M || PS . (1)

The padding string PS shall consist of 8 - (||M|| mod 8) octets all having
value 8 - (||M|| mod 8). (This makes the length of the encryption block EB a
multiple of eight octets.) In other words, the encryption block EB satisfies
one of the following statements:

EB = M || 01 — if ||M|| mod 8 = 7 ;
EB = M || 02 02 — if ||M|| mod 8 = 6 ;
×
×
×
EB = M || 08 08 08 08 08 08 08 08 — if ||M|| mod 8 = 0 .

Note. The encryption block can be parsed unambiguously since every
encryption block ends with a padding string and no padding string is a
suffix of another.

-----Original Message-----
From: Rodney Thayer <rodney@sabletech.com>
To: ipsec@tis.com <ipsec@tis.com>
Date: Wednesday, September 24, 1997 2:23 PM
Subject: [Ottawa bakeoff feedback] problem with ESP Padding



>Here at the Ottawa ANX workshop we have found a problem with the definition
>of Padding in the ESP document.  We found this problem:
>
>The text in sections 2.4 and 2.5 of draft-ietf-ipsec-esp-v2-00.txt
>discusses Padding and Pad Length.  We found that people (including myself)
>interpreted this like this:
>
>Given a block that ends in 'xx xx', to form the tail end of the ESP
>message, you would get
>
>   xx xx [Padding=1 2 3 4] [PadLth=4] [NxtProt=4]
>
>Note this has the padding stuff being 1..2..3..4..4.  That last 4 is the
>Pad Length.  It is the length of the "Padding field", the field BEFORE the
>Pad Length.  The "1.2.3.4" is the Pad (value).  It is sort of
>self-describing.  (The NxtProt is the Next Protocol, e.g. a 4 for IP.)
>
>This is wrong.  It doesn't work for hardware vendors.  It does not meet the
>requirement for self-describing padding, as hardware vendors requested and
>in the style of PPP.
>
>Here is what we should do:
>
>Given a block that ends in 'xx xx', the tail of the ESP message would be
>  xx xx [Padding=1 2 3 4]+[PadLth=5] [NxtProt=4]
>This changes the Pad Length field to mean "the length of the padding field,
>counting the length byte itself".  Note that since the Pad Length is
>mandatory, the minimum value for this is a 1.  This has the padding stuff
>being 1..2..3..4..5.
>
>I propose the draft text change.  I propose that section 2.5 now on page 7
>change to this:
>
>"2.5 Pad Length
>
>The Pad Length field indicates the number of pad bytes in the message,
>including itself.  The
>range of valid values is 1..255, where a value of one means that no Padding
>bytes are present, other
>than the Pad Length itself.  Zero is not a valid Pad Length field.  The Pad
>Length field is mandatory."
>
>This will of course break all the ESP implementations that support the
>current draft.  Note that you can build in backwards compatability by
>implementing this:
>
>  if pad length > 1
>    then
>      if pad length byte is the same as the previous byte
>      then
>        implement previous pad algorithm i.e. pad_length++;
>
>
>
Follow-Ups: