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

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 3 Apr 2006 13:22:54 -0700 (GMT-07:00)

Reply below..

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]]
> Sent: Friday, March 31, 2006 2:24 PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap
> Subject: Re: [Capwap] PFS: requirement or not?
> 
> In general, transient DTLS keys for past sessions would not be saved
> on the WTP.  Without PFS, if an attacker had saved the DTLS handshake
> from  the previous session, they could use the compromised long-term
> key to derive past session keys, and therefore compromise past sessions.
> Therefore, in general, PFS is a good thing.
> 
> HOWEVER, what exactly are we trying to protect?  The whole point of
> DTLS is to prevent an attacker from compromising control traffic.  My
> question: What good is old control traffic to an attacker?  The only
> thing of value contained within is the PTK for 802.11i sessions that
> are no longer active.  Thus, my conclusion is that PFS is not a
> requirement.
> 
> I see no reason not to have PFS ciphersuites defined, but I don't
> think they should be mandatory to implement.

Let's go back to how this all started. This sentence appeared, offset from other text, in one of the later lwapp drafts:

" It is important to note that Perfect Forward Secrecy is not a requirement for the LWAPP protocol."

I've never agreed with this, and with it standing off by itself in the text, it's sort of like a "kick me" sign. Anyway, that got me to thinking, and here we are.

This boils down to your point of view. At the risk of being trite, I might say it boils down to your "threat model".  Unfortunately, that term has been so abused (these days it's little more than secu-babble) that it's hard to get people to take it seriously. Still, that's what we need to discuss. People who aren't security geeks might be more comfortable with "use cases and associated vulnerabilities/threats". In any event, let's talk about that.

Implicit in the Charles' argument above is the assumption that the there is nothing of value to be had if old conversations can be decrypted, which sort of suggests the view that the 802.11i keys are little more than a wlan access control mechanism, sort of like a one-time-password . Also, it ignores the case where the credential may be compromised without detection (crack the AP open, get the key, close it back up and place it back into operation), which allows for real-time decryption, as well as injection and active MiM attacks over the wireless link. 

So, back to the threats: if you assume that there are only two deployment models, i.e. hotspot and closed enterprise networks with reasonably good physical security, then you might assume there is no real threat here. [Actually, there are many more than those two deployment models, and I'd love to chat about them, but I don't feel like emailing a book].  Still, even in the hotspot case, it turns out that this assumption would be incorrect. You have to remember: we are dividing the old 802.11 AP functionality in two, and then exposing the link in between - this opens up many new possibilities for the attacker, especially when this link runs over hostile territory. We discussed this in the capwap wg meeting and also in our saag presenation: capwap is being used to indirectly extend the trust bootstrapping process - it MUST NOT degrade the security of this arrangement.

So, on to the beef: in the discussion below I'm going to be very concise, but I want the chairs, ADs, and working group to take note of the complexity involved in properly analyzing this stuff. This is why the security considerations of the capwap-00 draft was only a placeholder - we need a stand-alone document dedicated to this sort of analysis and elucidation of security requirements. I've been trying to make that point behind the scenes, but I'm not sure I've been very effective thus far. Hopefully this will drive the point home. 

Just for now, let's forget about all the various wlan deployment models, save just this one: the remote AP. In this model,  APs are deployed in one place, and managed from somewhere else. I know of at least two vendors who are selling this model today. The management may be handled by some sort of MSP (with the AC in the cloud), or from a central headquarters AC. Typically, these will be local MAC configurations:

                         security
                         boundary
++========================++
||                        ||
||  +---------------------++
||  | local network       ||       /^^^^^^^^^^^^^^\
||  |           |         ||      (                )      +-----+
||  | [user1]---| +----+  ||     (  [hostile hop]   )     |     |
||  |           +-+    +--++----(                    )----+     |
||  |           | | WTP|                                  |  AC |
||  | [srvr1]---+ |    +--++----(                    )----+     |
||  |           | +----+  ||     (                  )     |     |
||  |        ^            ||      \vvvvvvvvvvvvvvvv/      +-----+
||  +--------|------------++
||           |            ||
++========================++
            \
             \
              \--- soft and chewy

I'm hoping webmail didn't mangle that too badly - if so, I'll post a follow up from a different email account. Pay special attention to the security boundary. For simplicity, let's talk about a branch office, with the WTPs being managed by headquarters, but note: the same sort of issues apply anytime capwap crosses a security boundary, and the user and WTP are together on one side of it.

Can you see the issue here? Put simply, it is that confidential data is flowing over the 802.11 link, data which could have value to an attacker, and which should not be visible outside of the secuirty boundary. That data may be valuable long after it was transmitted, or it may have value only for seconds or moments after transmission. Still, the "old" 802.11i keys could very wll be worth a *lot* to an adversary. And in the case where the key is compromised without detection, the attacker may have access in real-time. Doh!

Okay, now let's zoom out a bit, and come back in on a hotspot. I've heard lots of arguments around this scenario saying "if they can see the capwap, they can see the user's internet traffic and/or do a MiM from the other side of the AP, so why attack the credential?". Why, indeed. Note that being able to *see* the capwap (and Internet data) is not the same as being able to do a MiM - these are two very different capabilities. However, if you can see the capwap and you have the credential, an untraceable MiM attack over the WLAN is now possible.

There certainly are more threats and vulnerabilities we could look at (actually, quite a few more), but in the interest of keeping this email manageable, I will stop here for now. Like I said, I think a document should be dedicated to this, and email is a difficult medium for such complexity. 

So, what's it take to defend against these particular threats? Turns out PFS goes a long way, and at very little cost to us. If we add PFS, an attacker can no longer simply sniff/record the capwap link to derive the session keys. Now, simply compromising the PSK is not enough. Instead, the attacker has to mount a successful MiM attack during the capwap key exchange, which is *significantly* more difficult And what does this added protection cost us? Very little - basically, a Diffie-Hellman exchange during session establishment. Assuming the gear is stable and we're using strong crypto for the capwap session, this should be relatively infrequent.

We could say "use PFS in this scenario, and that scenario, ... oh yeah, and when this happens too", or we could just say "preshared key usage requires PFS". Operationally, the latter is much simpler, and much more likely to be correctly implemented. Those of you who watched the design and deployment of IPsec might agree that simpler is almost always better, and this is why I vote for PFS-only preshared keys.

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 17:44:03 -0400 (EDT)

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.

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.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]