Subject: Re: [Capwap] PFS: requirement or not?

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 3 Apr 2006 18:52:12 -0400 (EDT)

Hi Charles,

-----Original Message-----
>From: "T. Charles Clancy" <[email-masked]>
>Sent: Apr 3, 2006 2:44 PM
>To: "Scott G. Kelly" <[email-masked]>
>Cc: capwap <[email-masked]>
>Subject: Re: [Capwap] PFS: requirement or not?
>
>Some thoughts...
>
>I don't see how PFS will help us protect data.  All data has to go through 
>the AC (at least that's my understanding), so unless the CAPWAP data 
>channel is protected, all data is vulnerable to compromise.  

I wondered if you that's what you were thinking. This assumption is wrong - all data does *not* have to go through the AC, and especially not in many remote AP scenarios. What my diagram may not have illustrated so clearly is that in some local MAC scenarios, much of the wlan traffic may be destined for local (wired) servers/hosts. In general, this is described in the architecture taxonomy RFC as "Local MAC", and it's commonly deployed today. There are also hybrids possible. And the scenario I described is only one of many that we need to consider.  There is far more to be concerned with than initially meets the eye.

> Using a 
>DTLS-protected data channel or terminating 802.11i at the AC will solve 
>these problems, not PFS.  Thus, IMHO, old CAPWAP traffic is not useful to 
>an attacker, assuming the proper caveats.

Yes, as it turns out, data channel security will solve many problems. For example, terminating 802.11i at the AC largely overcomes the PFS, but it is simply not an option in many local MAC scenarios. In thinking about these problems over the weekend, I arrived at the conclusion that data channel security (of some sort) is a hard requirement for some scenarios - but that's another discussion, one I'm sure will be at least as much fun as this one :-)

But again, let me emphasize this: since there may be confidential (read: high value) traffic on the local segment which is protected by 802.11i and does not traverse the link between WTP and AC (i.e. it is not supposed to be visible outside of the security boundary in my ascii drawing), we need to make sure someone can't record it and crack it later (unless they brute force the AES). PFS helps to mitigates this threat.

>On the other hand, Scott does bring up a good point.  PFS will force an 
>attacker who has already compromised a CAPWAP credential to be active 
>rather than passive when launching attacks against future sessions.
>
>Of course in order to have keys equivalently strong to AES-CCM-128, you'll 
>need to use 3072-bit DH.  The complexity of that is not something to 
>sneeze at, especially for a super-cheap, light-weight AP.

This is a very reasonable point, and we went through similar pain in IPsec when we added AES crypto suites. I think that in cases where you actually *need* 128 bits of security, you either won't be using preshared keys, or you'll have beefy-enough hardware to deal with this. 

A 200Mhz PPC (not a high end processor by today's measures, but very common in APs) can do the DH in a few hundred millisecs or less. If your hardware doesn't reboot every day, you won't have to do capwap session establishment very frequently, and one 128-bit key (assuming aes-ccm) should last you for 2^64 or so packets, (which should be a *very* long time if you're only encrypting control traffic).

However, there are two other possibilities: first, use smaller moduli. If you only need, say, 80 bits of strength (suffiicient in many scenarios), you can use much smaller moduli/exponents.  The second option is to use elliptic curves instead. There currently are no ECC PSK suites defined for (D)TLS, and I'm not sure what the IPR status is at this point,  but I'll look into this a bit. 

Honestly, though, I don't think that people should be cheaping out on security-critical hardware. If 3072-bit DH is the price of admission, then it may be best just suck it up and deal with it...

Scott

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

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

---

From: "T. Charles Clancy" <[email-masked]>
Date: Mon, 3 Apr 2006 20:03:43 -0400 (EDT)

> I wondered if you that's what you were thinking. This assumption is 
> wrong - all data does *not* have to go through the AC, and especially 
> not in many remote AP scenarios.

Ah, I see.  I guess I've been so focused on the security part, and how to 
multiplex DTLS and data channels, etc, I lost sight of the Local MAC 
model.

> Yes, as it turns out, data channel security will solve many problems. 
> For example, terminating 802.11i at the AC largely overcomes the PFS, 
> but it is simply not an option in many local MAC scenarios.

Implementing crypto on the data channels means you have something new in 
your security model that you need to protect, and may further substantiate 
the case for PFS.

> Honestly, though, I don't think that people should be cheaping out on 
> security-critical hardware. If 3072-bit DH is the price of admission, 
> then it may be best just suck it up and deal with it...

It might also be good to look at which DTLS ciphersuites would be NIST 
FIPS 140-2 certifiable.

I agree that PFS is a good thing.  I guess I'm just not entirely sold on 
the idea of it being mandatory.  From a security perspective, we have 
bigger problems.  For example, avoiding WEP and low-entropy RADIUS shared 
secrets is only RECOMMENDED.  I guess CAPWAP has less control over those 
though, and we shouldn't let our protocol be the weak link.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap