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

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?"

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.

First I'd like to mention that this "new" attack
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...>

In article <14ekoortlqg0i....@news.cis.dfn.de>,
Sebastian Gottschalk  <se...@seppig.de> wrote:

It wasn't the "designers", it was the
"standardizers"... but you're right.

Yes, I agree with this one.

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

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.

On Sun, 15 May 2005 14:04:50 +0200, Sebastian Gottschalk

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

"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. "

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.

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 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?

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

"Simon  Johnson" <simon.john...@gmail.com> writes:

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/

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?

In article <d6e6em$2d3...@agate.berkeley.edu>,
  >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.
--
Greg Rose
232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C
Qualcomm Australia: http://www.qualcomm.com.au

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".

   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

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.

David Wagner <d...@taverner.cs.berkeley.edu>:

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

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?

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.

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.

Yup.  The goal of a committee is to reach a consensus, not to create a
practical, workable design.

Peter.

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.

I know of banks that use them over leased-line links to mainframes, where CPU
cycles are expensive.

Peter.