At 12:48 PM -0700 1/6/10, Grewal, Ken wrote:
Steve,
The either-or on using an ICV or explicitly checking the WESP header
on the recipient was based on the assumption that the threat does
not come from the sender and only from some other malicious entity
after the packet has been sent.
This was the reason for simplifying the header check by using the
ICV, instead of explicitly checking every field.
You cited my comments about a vulnerability as the rationale for
pursuing this design. I noted that my comments did not specify the
source of the mismatch between header data that IPsec acts upon (for
access control) vs. what WESP caused an intermediate system to
examine. You chose to focus on one possible source of manipulation,
i.e., a MITM attack. That's fine, but it does not necessitate
changing the ESP ICV computation, i.e., checking by the recipient
suffices. Also, the I-D calls for consistency checking, so I was
(justifiably) confused by the either-or statement you made.
If the sender is malicious, then an encrypted (covert) channel is
all that is needed to bypass any intermediate checking and
furthermore, any explicit checking of each WESP field on the
recipient does not help, as the payload can contain whatever is
intended by the malicious sender!
I see we have a miscommunication about the nature of the
vulnerability that I cited. It is what I noted above, i.e., "a
mismatch between header data that IPsec acts upon (for access
control) vs. what WESP caused an intermediate system to examine."
This is an old security concern, dating from the mid/late 1970s, when
it was discovered that one could make a call to an OS with one set of
parameters, and then change the parameters after an access control
check was performed but before the OS acted upon the call. The fix
for this sort of attavck was to copy the parameters into
OS-controlled address space, out of user-space. An encrypted covert
channel was not what motivated my comments, because IPsec makes its
access control decisions based on the 5-tuples from the IP and
transport layer headers.
We did debate this a number of times and extending the integrity
appears as early as May of last year in version 3 of the draft (at
version 12 now), so it should not have been a surprise at last call.
I have already apologized for not closely tracking the changes to
WESP. However, during IETF last call everyone is free to raise
questions of this sort, so we ought not devote too much time and
energy to this aspect of the discussion.
In either case, as Gabriel indicates in a separate email, if it
makes sense to go back to not integrity protecting the WESP header,
I am fine with that. This was the original position and aligns with
your other email on WESP acting as a wrapper to ESP, and should also
address other comments indicating that the name Wrapped ESP is a
misnomer!
That works for me too, but I would feel better if we were all in
agreement about the nature of the vulnerability that I cited, which
motivated this in the first place.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
