[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simplifying IKE
> While I certainly agree that the attack described in the
> Ferguson/Schneier
> paper on ESP was esoteric, I disagree on your conclusion that
> no damage will be done. Let's assume that no attack is
> occurring. What if
> the system administrator enters the section of the key used
> for decryption
> incorrectly?
IPsec is typically used with negotiated keying. Manual keying is most useful
as a hook to allow arbitrary key exchange mechanisms. If you decide to hand
enter the keys, you had better be extra careful that the information you
type is correct.
> Authentication will work correctly, but right
> now, there is
> no verification mechanism in place to assure that the plaintext is not
> garbage, and once you pass garbage up to the upper layers,
> the behaviour is
> system specific and unknown -- it could range from catastrophic to no
> damage at all.
This attack does not allow the bad guy to modify only part of a message or
to control the content of the corrupted message in any way. And in the
situation you bring up, there is no bad guy. Upper layer protocols like TCP
and UDP have checksums. Plus, the chance of creating a correctly formatted
tunnelled IP packet is infinitesimal.
> Authenticating the text after decryption
> assures that the
> correct plaintext is passed to the upper layers.
So does including the key, but without causing the DoS vulnerability. So, to
be a bit lawyerly, redesigning ESP is not necessary, and even if it was, you
wouldn't need to reverse the order of the transforms.
> If the
> current order is
> only maintained to ward off DoS, then I'd suggest that the
> argument is
> weak, since DoS can only be minimized, not eliminated.
That's one of the problems with DoS... there always seems to be a new
vulnerability to be found. However, let's imagine that, some time in the
future, encryption is so widely deployed that a host can have a security
policy which rejects all packets except ESP and IKE (and maybe some ICMP).
Now we have a realistic chance of eliminating DoS simply by making it
infeasible with those two protocols.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com]
> Sent: Thursday, August 09, 2001 3:10 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: 'Dan McDonald'; ipsec@lists.tislabs.com;
> owner-ipsec@lists.tislabs.com; 'Sandy Harris'
> Subject: RE: Simplifying IKE
>
>
>
> Andrew,
>
> While I certainly agree that the attack described in the
> Ferguson/Schneier
> paper on ESP was esoteric, I disagree on your conclusion that
> no damage will be done. Let's assume that no attack is
> occurring. What if
> the system administrator enters the section of the key used
> for decryption
> incorrectly? Authentication will work correctly, but right
> now, there is
> no verification mechanism in place to assure that the plaintext is not
> garbage, and once you pass garbage up to the upper layers,
> the behaviour is
> system specific and unknown -- it could range from catastrophic to no
> damage at all. Authenticating the text after decryption
> assures that the
> correct plaintext is passed to the upper layers. If the
> current order is
> only maintained to ward off DoS, then I'd suggest that the
> argument is
> weak, since DoS can only be minimized, not eliminated.
>
> Steve
>
>
>
>
>
>
> "Andrew Krywaniuk"
>
> <andrew.krywaniuk@al To: "'Dan
> McDonald'" <danmcd@East.Sun.COM>, "'Sandy Harris'"
> catel.com>
> <sandy@storm.ca>
>
> Sent by: cc:
> <ipsec@lists.tislabs.com>
> owner-ipsec@lists.ti Subject:
> RE: Simplifying IKE
> slabs.com
>
>
>
>
>
> 08/09/01 07:45 AM
>
> Please respond to
>
> andrew.krywaniuk
>
>
>
>
>
>
>
>
>
> > > > 4. modify ESP to ensure it authenticates all data used in
> > the deciphering
> > > of the payload
> > >
> > > This is the only recommendation in this paper based on a
> > direct security
> > > flaw, with a proposed attack to demonstrate it. There are
> > others in the
> > > Simpson paper.
> >
> > And if you use Choice 3a above, you get this for free - AH
> > covers the whole
> > ESP datagram, SPI/IV/etc.
>
>
> If my memory serves me correctly, Ferguson/Schneier were actually
> suggesting
> that
>
> 1. encryption be applied AFTER authentication
>
> or, failing that, that
>
> 2. the encryption/decryption key be included in the data
> which is hashed
>
> This is to prevent an esoteric attack they describe which is
> infeasible and
> wouldn't cause any damage anyway. That is not a compelling reason to
> redesign ESP.
>
> Andrew
> -------------------------------------------
> Upon closer inspection, I saw that the line
> dividing black from white was in fact a shade
> of grey. As I drew nearer still, the grey area
> grew larger. And then I was enlightened.
>
>
>
>
>
>
References: