[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DES-CBC "interface" shim
> From: Stephen Kent <kent@bbn.com>
> A couple of comments on your DES-CBC "shim" document (which we're calling
> "algorithm" documents in the AH and ESP I-Ds):
>
Please change your terminology; that makes no sense. The "algorithm"
document describes the actual algorithm (for example, RFC-2144).
If you read the draft, I call it the "transform interface". It's less
than a transform.
Perhaps other folks can come up with a better term. Shim is good enough
for the vernacular for now.
> - I'd suggest rewording the IV section to make it clear that the
> IVs used here are not carried explicitly in the ESP packet, but are
> constructed from values elsewhere in the ESP packet format, what the ESP
> I-D refers to as an "implicit" IV.
Sure.
> Also, I hope your insistance on always
> including the sequence number field, wasting 4 bytes in the IPv4 context if
> anti-replay was not enabled, was not motivated by your desire to use it for
> IV computation here.
>
The implementors decided to keep the field, as the sender has no idea
whether the receiver has implemented anti-replay.
Of course, if they had dropped it, I would just keep the current
RFC-1829 text having a 32-bit number in that location, which can be
either a counter or pseudo-random.
> -I don't see a need to include section 7, on the authentication
> data field.
>
I'm sorry, I don't understand why not? The DES-CBC shim needs to talk
about the need for integrity. That's algorithm dependent.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2