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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 7 Apr 2006 07:42:12 -0700

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

Just to make sure we are on the same wavelength, all traffic for
a given WLAN is either terminated locally, or not. There is no
such thing in the protocol as half going one way, and half going
the other way.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Monday, April 03, 2006 3:52 PM
> To: T. Charles Clancy
> Cc: capwap
> Subject: Re: [Capwap] PFS: requirement or not?
> 
> 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.
> 
> 
> > 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
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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