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

Re: ICMP Security Failures



Craig Metz <cmetz@sundance.itd.nrl.navy.mil> writes:
>Hilarie Orman writes:
>>Some combinations may not be possible, due to ambiguities in
>>processing order.  For example, IP-AH-AH or IP-ESP-AH.
>
>	I think IP-AH-AH is valid, though maybe not very useful. You
>would process those in order, i.e., the first AH would cover the payload,
>and the second AH would cover the first AH and the payload.
>
>	I don't think IP-ESP-AH is valid -- it would have to be >IP-ESP-IP-AH.

No, sadly, I don't think IP-AH-AH is safe to use with today's AH spec.

It has been decided (or "decided"?) that the AH header covers some
stuff preceding it, not just the payload: at least part of the
previous IP header, and everything following it, is protected.

You could probably implement IP-AH-AH by constructing a skeleton
of all the headers in the first pass, zeroing out the Authentication
Data field in each AH header & zeroing other relevant stuff in the
IP header, and then do the relevant MAC calculations in a second
pass.  This is a royal pain in the ass.

The other implementation strategy is to completely fill out the
inner AH header in a first pass, and then completely fill out the
outer AH header in a second pass (noting that the IP header will
have changed between the two passes in this case).

The two algorithms will NOT be compatible.  (The issue is whether
to use the same IP header values when calculating both MACs.)
The AH document doesn't specify which algorithm to use, as far as
I can see.

I also didn't find anything in the AH spec to indicate clearly
whether IP-AH-AH is compliant.  I suspect it's invalid.  Clarification,
anyone?  (A quote from the AH spec would be nice.)


In short, IMHO, I think the AH spec is deficient when it comes to
multiple uses of ipsec headers.  (In clarity, at least, and perhaps
in design too: see below.)


Obligatory repetitive bitching and moaning:
If AH didn't try to protect bits of the datagram that precede the
AH header (or used a pseudo-header), there wouldn't be a problem:
IP-AH-AH and IP-ESP-AH would be valid & trivial to handle, as would
other more complicated combinations.



Follow-Ups: