Attacks on IPsec
Kevin Drapel
mode, enabled encryption but disabled integrity check. Another also
applies to AH with some special settings. The attacker can retrieve
some plaintext data using the ICMP messages.
http://www.uniras.gov.uk/niscc/docs/al-20050509-00386.html?lang=en
Simon Johnson
designers of IPSec.
"Why on earth did you allow integrity checks to be turned off?"
Although most people don't realise it, they actually care about
integrity more than secrecy. Most people who use SSH or IPSec for
administering their computers would probably be more concerned about an
attacker who could hijack their connection rather than a person who
could simply inspect the traffic.
Never in a million years should you allow integrity to be turned off.
It's just irresponsible to allow this as an option because most users
would not understand the ramifications of that decision. We don't
bother the typical VPN user with the details of the mathematics going
on in the background so why are we handing them control of such an
important option when it can only lead to them hanging themselves? As
far as the user is concerned they want exactly two options: "Secure",
"Not Secure". Everything else is unnecessary confusion.
In my opinion, it's even a bad idea to allow the user to choose the
cipher and key-size properties. When writing a protocol the writers
should specify one hash, one cipher and one signature/key-exchange
algorithm and one set of parameter sizes. Any other choice of
primitives should be non-standard. They should go even further than
this and also specify how to implement that algorithms because bad
implementation can leave the protocol open to timing attacks.
It might seem like I'm advocating micromanagement on a grand scale,
well if you're thinking this then you're right because that's exactly
what I'm advocating. In cryptography, the stakes are so high we have to
be sure the standard covers all the bases. Any "feature" in a
cryptographic system is another place for insecurity to hide. Only by
having a rigid standard can we mitigate these kind of problems. The
more "features" we can purge, the smaller the perimeter we have to
secure and this is good for designer and user alike.
Cheers,
Simon.
Gregory G Rose
is just a variation on a theme of a paper full of
such attacks, published in 1996 by Steve Bellovin
at USENIX Security. See
<http://www.usenix.org/publications/library/proceedings/sec96/bellovin.html>
In article <14ekoort...@news.cis.dfn.de>,
Sebastian Gottschalk <se...@seppig.de> wrote:
>Simon Johnson wrote:
>
>> Well this just brilliant cryptography. I have a quick question for the
>> designers of IPSec.
>>
>> "Why on earth did you allow integrity checks to be turned off?"
It wasn't the "designers", it was the
"standardizers"... but you're right.
>I have a quick question: Who in hell does turn of integrity checks and what
>hell of an implementation actually allows this (wihtout modifying the
>source code?
Yes, I agree with this one.
>That's why this attack is just considered as a "flaw" with no practical
>meaing.
>
>BTW, even though IPSec was subject to public scrunity, the designer where
>just a lame old-fashioned commitee of idiot experts that, in most times,
>didn't get the clue. Please read Bruce Schneier's analysis of IPSec, the
>flaws he found and his opinions about the design criteria.
Sorry, you weren't there, and neither was Bruce.
This is historically naive. Bellovin, Phil Karn,
JI Ioannides, and many others who were very much
not "idiot experts" did most of the fundamental
design. They need to be thanked for making it as
good as it is. Only later did it get bogged down
by the "idiot non-experts" who thought that it
would be more efficient if integrity was optional,
no-one needs anonymous Diffie-Hellman anyway, PKI
will save the world, it'll only be used in tunnel
mode, ... . Gah. The original group disown what is
only now starting to be deployed.
Greg.
PS. By way of disclaimer, I wasn't there either,
but Phil Karn is a close colleague, Steve Bellovin
is a good friend, and I was close enough to the
fringes to hear what was going on when it was
happening, not in some historical distorted
mirror.
--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Qualcomm Australia: http://www.qualcomm.com.au
David Wagner
>BTW, even though IPSec was subject to public scrunity, the designer where
>just a lame old-fashioned commitee of idiot experts that, in most times,
>didn't get the clue.
I dissent from this characterization.
It was a committee, but not of idiots.
I think Schneier's argument was that design by committee, even when
the committee is full of super-smart people, can lead to unnecessary
complexity and other less-than-optimal outcomes.
Juuso Hukkanen
<se...@seppig.de> wrote:
>BTW, even though IPSec was subject to public scrunity, the designer where
>just a lame old-fashioned commitee of idiot experts that, in most times,
>didn't get the clue. Please read Bruce Schneier's analysis of IPSec, the
>flaws he found and his opinions about the design criteria.
I guess You are not referring to following note about IPSec design,
which the ChiefChef wrote in his 99/2 cryptogram. And to which article
he pointed in last weeks securityfocus interview.
http://www.securityfocus.com/columnists/324
<snip>
Trusting the Known
^^^^^^^^^^^^^^^^
Consider IPSec, the Internet IP security protocol. Beginning in 1992,
it was designed in the open by committee and was the subject of
considerable public scrutiny from the start. Everyone knew it was an
important protocol and people spent a lot of effort trying to get it
right. Security technologies were proposed, broken, and then modified.
Versions were codified and analyzed. The first draft of the standard
was published in 1995. Aspects were debated on security merits and on
performance, ease of implementation, upgradability, and use.
In November 1998, the committee published a pile of RFCs -- one in a
series of steps to make IPSec an Internet standard. And it is still
being studied. Cryptographers at the Naval Research Laboratory
recently discovered a minor implementation flaw. The work continues,
in public, by anyone and everyone who is interested.
On the other hand, Microsoft developed its own Point-to-Point
Tunneling Protocol (PPTP) to do much the same thing. They invented
their own...
</snip>
http://www.schneier.com/crypto-gram-9904.html#different
My opinion is that all the crypto products provided to public should
be oversimplified. Everything else and somebody will in no time find
the way to how to implement it wrongly - and how to make that wrong
implementation most popular.
Juuso Hukkanen
Simon Johnson
by the "idiot non-experts" who thought that it
would be more efficient if integrity was optional,
no-one needs anonymous Diffie-Hellman anyway, PKI
will save the world, it'll only be used in tunnel
mode, ... . Gah. The original group disown what is
only now starting to be deployed. "
What is is about people wanting cryptography to be free? Ladies and
gentlemen I present a new and interesting idea: Cryptography costs
clock cycles! That's right boys and girls, if you have cryptography in
your application it will slow it down! Shock horror!
It reminds me of a conversation I had with Tom where people complained
because a 300Mhz system couldn't back up, over an encrypted connection,
to the backup server at a full 100 mega-bit per second.
The mind boggles, yes it will slow down the back-up. If a few minutes
on a back-up job is cause for complaint how much do you really value
the security? Not a lot I would say.
In reality the cryptography is just another checkbox a company buyer
needs to fill in order to purchase a backup solution.
Simon.
Tom St Denis
> What is is about people wanting cryptography to be free? Ladies and
> gentlemen I present a new and interesting idea: Cryptography costs
> clock cycles! That's right boys and girls, if you have cryptography
in
> your application it will slow it down! Shock horror!
Because often they're not very knowledgeable about computer science.
But if you look at say video/audio codecs... most commercial systems
have hardware MPEG. So they assume and ask "MPEG is fast and it's
complicated why is CCM-AES slow(er)?"...
Of course if they shilled out for hardware crypto they'd get that ooh
and aah too [depending on what processor they're offloading from, bus
conditions, etc...]. At "nameless" corporation I work at we have
hardware CCM-AES designs [for instance] that would basically floor any
software implementation.
The problem is the companies want to offer "super crypto!" but not
shill out [or get their customers to shill out] for the needed
acceleration.
> It reminds me of a conversation I had with Tom where people
complained
> because a 300Mhz system couldn't back up, over an encrypted
connection,
> to the backup server at a full 100 mega-bit per second.
It was a [iirc] ~700Mhz P3 box. A null-cipher only got 9MiB/sec
through their network stack (which sits on top of TCP ... which sits on
IP which sits on ...). With my crypto stack they were getting around
6-7MiB/sec. My AMD64 could [iirc] handle 24MiB/sec full-duplex [so
48MiB/sec] with the same crypto layer but without their backup stack
[48MiB == 384Mbps].
... and my AMD64 motherboard+cpu cost all of around $450 CAD ...
In this case the complaint was "we only have X hours for backup
windows". So they had customers who were backing up thousands of GiB
of data [presumably worth $$$] and couldn't afford a $450 upgrade to
get them better than 100Mbps throughput.
When I tried to explain that to them [could have been a language
barrier... who knows] they were confused. Million of dollars of
database records and we have to spend 200 euros to fix the problem?
WTF?
> The mind boggles, yes it will slow down the back-up. If a few minutes
> on a back-up job is cause for complaint how much do you really value
> the security? Not a lot I would say.
> In reality the cryptography is just another checkbox a company buyer
> needs to fill in order to purchase a backup solution.
Bingo. But standards are always full of stuff like that. Recently I
had a chance to glance through 802.16e and you see the same thing. A
dozen encoding schemes [FSK, BFSK, QAM, ...] and you know for a fact
that implentors won't support them all, just the easiest subset.
Tom
Anne & Lynn Wheeler
"Simon Johnson" <simon....@gmail.com> writes:
> "Only later did it get bogged down by the "idiot non-experts" who
> thought that it would be more efficient if integrity was optional,
> no-one needs anonymous Diffie-Hellman anyway, PKI will save the
> world, it'll only be used in tunnel mode, ... . Gah. The original
> group disown what is only now starting to be deployed. "
my impression was that ipsec was being worked on for awhile in ietf
... but it involved hitting everybody's (normally kernel-based) stack
(which in turn implies replacing everybody's kernel).
i think it was the ietf fall '94 meeting where what is now called VPN
was introduced in gateway working group meeting. this had the
advantage over end-to-end ipsec ... by not having to replace
everybody's kernel. some amount of contention was sort-of resolved by
labeling VPN as "light-weight" ipsec (as opposed to the regular,
heavy-weight ipsec).
about that time-frame we were asked to work with a small client-server
startup in menlo park that wanted to have the server do payment
transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and they had this thing they called SSL. The SSL implementation also
had the characteristic that it didn't require replacing the kernel in
order to achieve some level of added internet integrity.
now, the nominal design point for digital certificate-based PKI was
the offline email world of the early 80s; somebody would dialup their
local electronic post-office, exchange email, and then hangup. The
issue if the recipient/relying-party had email from some entity that
they never had communicated before ... how were they to establish any
information about the sender in this offline, disconnected world
communicating for the first time with a complete stranger (aka the
letters of credit model from the sailing ship days).
nominally, in normal entity relationship management ... you have
established some information resource about the entities you are
dealing with (things like business accounts, financial accounts,
accounts payable, etc) and have recourse to information about the
party you are dealing with (and/or are able to directly contact
responsible agencies for that information). the issue in the offline,
disconnected environment, with first-time communication between two
parties that have never communicated before and have no prior
knowledge about each other ... how to provide some substitute for
having the real information.
misc. posts about ssl certificate-based environments
http://www.garlic.com/~lynn/subtopic.html#sslcert
misc. posts about public key certificateless based environments
http://www.garlic.com/~lynn/subtopic.html#certless
various passed early internet references
http://www.garlic.com/~lynn/internet.htm
other internet related history
http://www.garlic.com/~lynn/rfcietf.htm#history
misc. things like interop '88
http://www.garlic.com/~lynn/subnetwork.html#interop88
and doing rfc 1044 support
http://www.garlic.com/~lynn/subnetwork.html#1044
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
David Wagner
Huh? I confess I don't understand this vulnerability report. I thought
IPSec made integrity mandatory for the usual modes of operation,
ever since Bellovin's seminal Usenix Security paper. Certainly there
is nothing new about the possibility of attacks on IPSec if you use
encryption without authentication -- that is exactly what Bellovin warned
about close to a decade ago. It's been a while since I've followed IPSec
closely; did "mandatory integrity" requirement fall by the wayside at
some point?
Gregory G Rose
David Wagner <daw-u...@taverner.cs.berkeley.edu> wrote:
>Kevin Drapel wrote:
>>One attack apply on certain configurations of IPsec with ESP in tunnel
>>mode, enabled encryption but disabled integrity check. Another also
>>applies to AH with some special settings. The attacker can retrieve
>>some plaintext data using the ICMP messages.
>>
>>http://www.uniras.gov.uk/niscc/docs/al-20050509-00386.html?lang=en
>
>Huh? I confess I don't understand this vulnerability report. I thought
>IPSec made integrity mandatory for the usual modes of operation,
>ever since Bellovin's seminal Usenix Security paper. Certainly there
Oh, yes, if you use ESP, it automatically has
integrity protection. But it's perfectly allowable
to negotiate the NULL integrity algorithm.
My point from a couple of days ago, exactly.
Greg.
David Wagner
>Oh, yes, if you use ESP, it automatically has
>integrity protection. But it's perfectly allowable
>to negotiate the NULL integrity algorithm.
Oh. I didn't realize that's allowed by the spec. Yup, that would do it.
I guess I must not have been paying attention when that one got approved
by the working group; I'll accept my share of the blame.
I think TLS also has a NULL ciphersuite, but if I remember correctly,
there are suitable warnings in the spec that basically say "don't use this".
Mike Amling
> Oh, yes, if you use ESP, it automatically has
> integrity protection. But it's perfectly allowable
> to negotiate the NULL integrity algorithm.
This is why security software should not be as configurable as the
average committee thinks it should be.
For another example, the choice of encryption algorithm negotiated in
SSL can be None. Admittedly, that option is off by default in the only
browser I've checked (Netscape).
--Mike Amling
David Wagner
> For another example, the choice of encryption algorithm negotiated in
>SSL can be None. Admittedly, that option is off by default in the only
>browser I've checked (Netscape).
Yes, you should never enable the NULL ciphersuite (except for
debugging).
I thought the TLS spec had appropriate warnings about this, though if
I'm wrong, please feel free to let me know.
Implementing crypto protocol securely does require some understanding
of cryptography. If you don't understand the crypto, then there are real
reasons to be concerned about whether your implementation will be secure
(it is probably a mistake to think that just because you can read a spec
and that you can write code, you can write crypto code that is likely to
be secure). If the implementors don't understand enough cryptography
to be able to recognize the issues with allowing the NULL ciphersuite,
they might well inadvertently introduce other security holes into their
implementation in other places as well.
Bodo Moeller
> Mike Amling wrote:
>> For another example, the choice of encryption algorithm negotiated in
>> SSL can be None. Admittedly, that option is off by default in the only
>> browser I've checked (Netscape).
> Yes, you should never enable the NULL ciphersuite (except for
> debugging).
>
> I thought the TLS spec had appropriate warnings about this, though if
> I'm wrong, please feel free to let me know.
While the SSL 3.0 specification doesn't say too much on this
ciphersuite, the TLS speficiation explicitly says that this
ciphersuite "must not be negotiated". A reason for formally defining
such a ciphersuite even though it can't be negotiated is that this
ciphersuite is used in the initial state of any connection: SSL/TLS
allows for renegotiation during a connection, which is why handshake
messages are always sent under some ciphersuite, even if it is
TLS_NULL_WITH_NULL_NULL most of the time.
There are other ciphersuites that don't do everything you might expect
from a ciphersuite: TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA.
These do not provide data encryption, but they do provide
authentication (but I don't thin anyone uses them).
Mike Amling
> While the SSL 3.0 specification doesn't say too much on this
> ciphersuite, the TLS speficiation explicitly says that this
> ciphersuite "must not be negotiated". A reason for formally defining
> such a ciphersuite even though it can't be negotiated is that this
> ciphersuite is used in the initial state of any connection: SSL/TLS
> allows for renegotiation during a connection, which is why handshake
> messages are always sent under some ciphersuite, even if it is
> TLS_NULL_WITH_NULL_NULL most of the time.
>
> There are other ciphersuites that don't do everything you might expect
> from a ciphersuite: TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA.
> These do not provide data encryption, but they do provide
> authentication (but I don't thin anyone uses them).
Not mention the 40-bit and 56-bit possibilities, which these days I
consider another example of a protocol being too configurable for its
own good.
SSH is another over-configurable protocol. It was not until last week
that the sysadmin here removed the fallback to SSH v1.
--Mike Amling
David Wagner
>Well this just brilliant cryptography. I have a quick question for the
>designers of IPSec.
>
>"Why on earth did you allow integrity checks to be turned off?"
A follow-up:
The real problem seems to be not the IPSec protocol, but rather clueless
implementors who are doing dumb things in their implementation.
The intent was not to allow integrity to be turned off. The IPSec
standards documents are very clear about the dangers of encryption
without authentication.
For instance, RFC 2406 says that encryption without authentication
is dangerous:
"Confidentiality may be selected independent of all other services.
However, use of confidentiality without integrity/authentication (either
in ESP or separately in AH) may subject traffic to certain forms of
active attacks that could undermine the confidentiality service (see
[Bel96])."
RFC 2405 has this to say:
"[Bell95] and [Bell96] describe a cut and paste splicing attack which
applies to all Cipher Block Chaining algorithms. This attack can be
addressed with the use of an authentication mechanism.
The use of the cipher mechanism without any corresponding authentication
mechanism is strongly discouraged. This cipher can be used in an ESP
transform that also includes authentication; it can also be used in
an ESP transform that doesn't include authentication provided there
is an companion AH header. Refer to [ESP], [AH], [arch], and [road]
for more details."
If implementors were reading the spec, I'd think this would all be
very clear.
Now, back to your real question. Why didn't the IPSec standard absolutely
forbid turning off authentication in ESP?
The answer involves a little bit of history. Back in the old days, the
way you got authentication is to use ESP over AH. But then Bellovin's
paper came along, and eventually people decided that, if everyone is using
authentication, we might as well allow ESP to support authentication as
well. Today you can use either ESP over AH, or ESP with authentication.
Either one works. They're both allowed.
So why is authentication optional in ESP? The reason that authentication
is optional in ESP is to allow for both "olden days" usage, where you use
AH+ESP, and "newfangled" usage, where you use ESP with authentication
built in. The intent was never to suggest that it is a good idea to
use encryption without encryption.
It's worth pointing out that this is clearly explained in the
documentation for at least one responsible implementation of IPSec.
http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/ipsec.html
http://www.manualy.sk/freeswan-1.3/doc/overview.html#encnoauth
In any case, using ESP without authentication and without AH is clearly
a mistake. This is all very well understood among the IPSec community,
and is not news.
So I disagree with the characterization of this as an IPSec flaw. It is
not a flaw in IPSec. Sure, some clueless implementations might be buggy;
but that's a problem with a lousy implementation, not a problem with
IPSec itself.
The real question is, why did some IPSec implementation allow users to
turning off authentication, despite very clear warnings in the standards
documents that this is a bad idea?
David Wagner
>BTW, even though IPSec was subject to public scrunity, the designer where
>just a lame old-fashioned commitee of idiot experts that, in most times,
>didn't get the clue.
I think this characterization is unsupportable. See my other post,
which demonstrates that the IPSec documents clearly warn about the
dangers of turning off authentication.
David Wagner
>Gregory G Rose wrote:
>>Oh, yes, if you use ESP, it automatically has
>>integrity protection. But it's perfectly allowable
>>to negotiate the NULL integrity algorithm.
>
>Oh. I didn't realize that's allowed by the spec. Yup, that would do it.
>I guess I must not have been paying attention when that one got approved
>by the working group; I'll accept my share of the blame.
Now that I've had a chance to look at the IPSec RFCs again, I retract
my willingness to accept any blame for this. I think the spec is clear
about the dangers of encryption without authentication. If anyone built
implementations that negotiate encryption without authentication, then
maybe they weren't paying attention closely enough.
There is always a danger in having cryptographic standards implemented by
people who don't understand cryptography, though I don't know whether
that is what happened this time, because I'm not familiar with the
details of which implementations are affected by this recent report.
Peter Gutmann
Yup. The goal of a committee is to reach a consensus, not to create a
practical, workable design.
Peter.
Peter Gutmann
>I think TLS also has a NULL ciphersuite, but if I remember correctly,
>there are suitable warnings in the spec that basically say "don't use this".
MUST NOT in RFC terms. It's only present so the security state-machine has an
initial state for the first handshake, which is sent in the clear before the
security parameters have been negotiated.
Peter.
Peter Gutmann
>There are other ciphersuites that don't do everything you might expect
>from a ciphersuite: TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA.
>These do not provide data encryption, but they do provide
>authentication (but I don't thin anyone uses them).
I know of banks that use them over leased-line links to mainframes, where CPU
cycles are expensive.
Peter.