<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: cipe-l,AT,inka,DOT,de
Subject: Long message - thoughts on Gutmann response
From: "R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>
Date: Wed, 24 Sep 2003 12:59:44 -0600

Hi,

As a fan and user of CIPE, and as owner of a small company that helps 
customers use CIPE to secure traffic between physical locations, I'm pretty 
concerned over the ramification of Gutmann's response.  I've now had two 
customers query me about this message.  The general response after the first 
read seems to be: "this guy is an expert, CIPE has problems, it's better to 
be safe than sorry, so maybe we should look for something else".

However, after reading carefully and listening to others on this list, I feel 
that are a number of problems with this analysis, and that it leads to 
inaccurate conclusions by the reader.  I present these thoughts to the list 
in hopes that they might be useful in helping craft an "official" CIPE 
response.

Please note that I am definitely *not* a crypto expert, and so my comments 
may 
present wrong facts or make wrong assessments.  If this info is more pain 
then help, please hit delete in your e-mail as fast as you can!

Gutmann claims his analysis is "evolving" (his word).  Here's the link on his 
site: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt.

CIPE usage
-----------------
"A friend of mine recently pointed me at CIPE, a Linux VPN tool that he 
claimed was widely used but that no-one else I know seems to have heard of."

Why is this comment so important as to be the first statement and 
introduction 
for his analysis?   I am also concerned that he only took a "quick look" 
while at a friend's place.  Gutmann is apparently a strong crypto guy, so his 
quick look probably beats most's comprehensive analysis.  But there is other 
evidence in his document to suggest his look may have been perhaps too 
cursory or performed from a predisposed viewpoint that undermines an unbiased 
analysis.

CIPE uses a compromisable CRC-32 checksum
-----------------
CIPE is using the checksum to validate proper delivery of an encrypted 
packet; 
i.e. identify packets corrupted during transit. While Gutmann's references 
are correct, he muddies the water a bit.  Yes, the CRC-32 has a known attack 
and its use in CIPE is apparently a weakness.  But this weakness alone does 
not provide an exploit make.  Gutmann then goes on to highlight how such a 
weakness played a *part* in an SSHv1 exploit.  Comparing a weakness in one 
product to an actual exploit in another is circumstantial and sensational.

CIPE uses a too-short padding length
-----------------
This is a valid weakness.  This issue in and of itself does not provide an 
exploit, but in conjunction with others it might.  Nothing in Gutmann's 
analysis shows valid evidence of an imminent threat.

CIPE has no replay protection
-----------------
CIPE is stateless and doesn't provide replay protection; it relies on upper 
layers in the protocol stack to do so.  TCP, for example, provides the 
necessary mechanics to impart pretty decent (in my opinion) replay 
protection.  Non-TCP apps almost always implement message reliability in 
their internal protocols, which also impart replay protection.  By being 
stateless, CIPE is less complex and doesn't incur the overhead of replay 
protection when it is usually provided elsewhere.  It is unclear to me 
whether my understanding is wrong, Gutmann didn't understand this decision, 
or if he discounted the approach so dramatically it wasn't even worth 
mentioning.

Assuming I'm accurate thus far, the glaring error in Gutmann's analysis is 
his 
example which infers that one could replay a database transaction through a 
CIPE tunnel.  Database systems invariably provide message reliability 
mechanisms *and* are usually implemented on top of TCP.  Gutmann's claim 
seems disingenuous, since there appears no way for it to be valid.

CIPE keys can be modified in transit
-----------------
Gutmann uses the example of 3DES and how a bit-flipping technique used in 
conjunction with CRC-32 checksums might be used to alter key values.  He then 
indicates that IDEA has weak keys like 3DES and infers that it would also be 
vulnerable.  This inference is not compelling evidence, but perhaps with 
Gutmann's knowledge base the inference is clear.  But this whole section is 
moot, because every implementation of CIPE I've seen uses the far superior 
Blowfish algorithm, which he doesn't address at all.  The source document 
Gutmann uses to analyze CIPE is clear in the use of this algorithm, so I'm 
unsure of the rationalization of not addressing it at all.

Because Gutmann does not show the above key attack is effective in CIPE, the 
rest of his points in Section 3 are not supported.  However, I'm compelled to 
point out his analysis of keyex management packets.  He implies that the 
CRC-32 attack (in conjunction with others) can be used on these packets.  
This is true, because applying an attack does not imply success (although a 
reader may infer such).  By his own analysis, it doesn't appear one will have 
the minimum of 16 bytes of known plaintext, as the flag in question appears 
to be part of a 4-byte bit field (perhaps encapsulated IP header info?).  
Further, he did not address the exposure of the Blowfish cipher to the key 
bit-flip attack.  Using his data, he hasn't convinced me this attack is 
possible.  At Gutmann's apparent level of crypto experience, I have to either 
conclude that he isn't good at presenting all the facts, I'm missing some 
obvious information unsaid in the article, or he misleads the reader in his 
analysis of keyex packet vulnerability.

Thoughts - insecure security products
-----------------
"At least Microsoft eventually tries to fix their stuff, given sufficient 
public embarrassment and the odd hundred thousand or so computers being taken 
out by attackers."

How is this comparison valid?  CIPE has no reported systems or data 
compromises.  The Microsoft product in question has had several.  Gutmann is 
comparing the unrealized *possibility* of an exploit with the *reality* of 
multiple exploits.  Rather than support his message that many open source 
developers don't have the skill or interest to maintain the security level of 
their products, his comparison does a better job of supporting the converse.

Summary of Analysis
-----------------
This quote from the analysis summarizes what I feel to be Gutmann's personal 
perspective before, during, and after writing this analysis:

"Whenever someone thinks that they can replace SSL/SSH with something much 
better that they designed this morning over coffee, their computer speakers 
should generate some sort of penis-shaped sound wave and plunge it repeatedly 
into their skulls until they achieve enlightenment."

I come to the conclusion that this analysis is more a rant.  One by a gifted 
and talented individual and one that does make some valid points, but a rant 
nonetheless.  Effective analyses don't typically rely on circumstantial 
evidence, unsupported inference, disingenuous facts, omission of relevant 
data, and faulty conclusions.  After initial research and review, I find this 
analysis to be much thinner on substantive claims that I originally 
anticipated.

Benefits of CIPE
-----------------
Most professional analyses I read tend to state both strengths and 
weaknesses, 
then provide insight into which contextual uses of the analyzed product may 
pose problems or issues.  Gutmann doesn't do this, so let me try.

1. CIPE is small and therefore easily audited and maintained.  CIPE has ~ 
7.954 lines of code.  FreeS/WAN has ~ 96.265 and openssh/openssl combine for 
~ 281,431.  Complexity and defect count are proportional.  Defects often can 
be used to subvert security.  All else being equal, CIPE will be far more 
secure.

2. CIPE has had no reported exploits, yet has been around and in use for 
years.  Compare that to the track record of those products Gutmann feels more 
comfortable with, like ssh and ssl.

3. Gutmann used 3DES and IDEA in his analysis, but don't most of us use the 
Blowfish cipher?  Anyway, it appears that key weakness in IDEA (and 
apparently to a lesser extent Blowfish) is exploitable only under very 
limited and typically unlikely situations: 
http://gunther.smeal.psu.edu/context/136432/0

4. CIPE uses preshared keys.  As long as the key transfer is done over a 
secure medium, CIPE avoids all the complexity of PKI (and the inherent 
defects in that much code) without incurring a decrease in security.  (We 
don't use pkcipe).

5. CIPE rekeys regularly.  Gutmann doesn't address this, probably because it 
seems to be a given feature.  But doesn't this limit a "crack" to the 
duration a given key is in play?

6. CIPE is not as heavily used as other protocols.  This makes it a less 
enticing target.  While this is not a sound reasoning for selecting a 
security technology, it has a valid impact on the exposure and risk 
equations.

Concerns with CIPE
-----------------
1. CRC-32 is a valid weakness in CIPE.  Real exposure level?  unknown

2. Packet padding is a valid weakness in CIPE.  Real exposure level?  unknown

3. CIPE uses the Blowfish cipher (does anyone still use IDEA?).  If Blowfish 
is ever compromised, it will take more time to modify CIPE to switch to a 
different, presumably more secure cipher.

4. CIPE is not as heavily used as other protocols.  This makes it a less 
enticing target, but also means it may not be subjected to the same scrutiny 
by the white and black hat communities as the other products.  This is a 
corollary to "security by obscurity", which has been proven invalid in the 
past.

The Future of CIPE
-----------------
I understand CIPE's next major release will use the linux in-kernel cryptoapi 
system, which will allow runtime selection between multiple high-end ciphers, 
like Blowfish, 3DES, and AES.  Perhaps other valid issues Gutmann has raised 
will also be addressed?

I like the architecture of CIPE.  A simple encrypting tunnel based on sound 
security underpinnings is much more valuable to me and those I support than a 
feature-laden, complex technology that is more likely to contain errors and 
be exploited.

All the best,
Steve McKown
Titanium Mirror, Inc.


<< | Thread Index | >> ]    [ << | Date Index | >> ]