Subject: [Capwap] RC4 Encryption?

From: "Margaret Wasserman" <[email-masked]>
Date: Tue, 6 Jun 2006 14:26:38 -0400

Hi All,

I tried to send a message to the list on this topic a while back, but I
don't think it ever went out...  Sorry if this is a duplicate.

I have a possible application for CAPWAP that involves running the WTP
portion on a DSP-only device.  In that situation, it will be very difficult
to support AES encryption, due to the processing overhead.  

Would the WG consider supporting a lighter weight algorithm for encryption,
such as RC4?  We could state that AES is preferred when possible, but make
RC4 an accepted option in cases where the hardware would not support the
processing overhead of AES encryption.

Thoughts?

Margaret

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 06 Jun 2006 13:00:37 -0700

> processing overhead of AES encryption.

Stream ciphers like RC4 are hard to use correctly in unreliable
environments (i.e., where packets may be lost). Pretty much
at minimum you need to generate a new key schedule for each
packet. Doing this securely with RC4 pretty much requires
using a secure KDF (e.g., HMAC) to generate the per-packet
key. Failure to do this was one of the problems with WEP [0].

A secondary problem with RC4 is that there are known biases
in the initial ciphertext bytes [1] which means that new designs
should really discard the first 1K or so, if they use RC4 at
all. 

On commodity processors (I don't know about DSPs so I'd be happy
to see new numbers), AES is about 50% as fast as RC4, so when
you factor in the additional work (both computational and design)
you need to do to use RC4 safely, I doubt it's worth it.

-Ekr

[0] Weaknesses in the Key Scheduling Algorithm of RC4, Fluhrer, Mantin
and Shamir, SAC 2001
[1] Ilya Mironov, (Not So) Random Shuffles of RC4. CRYPTO 2002.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: Charles Clancy <[email-masked]>
Date: Tue, 06 Jun 2006 22:30:57 -0400

Are you suggesting adding DTLS ciphersuites such as 
TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA?

There's a fundamental problem when using RC4 with DTLS (that 
incidentally does not appear to be addressed in RFC 4279).  In 
particular, we seed the KDF and use its never-ending output to encrypt 
data by XORing it with the plaintext packets.  However in DTLS, we can 
lose packets.  This means gaps in the keystream, and the key states 
become out of sync.  The only way to fix this is to do what WEP did, 
with per-packet IVs, and then you get all the same problems found in WEP.

So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix 
them, we introduce security problems.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

---

From: Charles Clancy <[email-masked]>
Date: Tue, 06 Jun 2006 22:59:10 -0400

Err... I cited the wrong RFC below.  I meant 4347, and it is addressed:

    "The only stream cipher described in TLS 1.1 is RC4, which cannot be
    randomly accessed.  RC4 MUST NOT be used with DTLS."

---

From: "Michael Montemurro" <[email-masked]>
Date: Thu, 8 Jun 2006 21:46:25 -0400

I've capture this as issue 135