Subject: [Capwap] PFS: requirement or not?

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Mar 2006 10:49:27 -0800 (GMT-08:00)

I've heard it asserted that PFS (perfect forward secrecy) is not a requirement for capwap. After thinking this over, I don't agree.

For those of you who aren't crypto geeks, here's a simple definition of PFS (you can see this one on the FreeS/WAN site at http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/glossary.html#PFS):

Perfect forward secrecy (PFS)
    A property of systems such as Diffie-Hellman key exchange which use a long-term key (such as the shared 
    secret in IKE) and generate short-term keys as required. If an attacker who acquires the long-term key
    provably can

        * neither read previous messages which he may have archived
        * nor read future messages without performing additional successful attacks

    then the system has PFS. The attacker needs the short-term keys in order to read the trafiic and merely having
    the long-term key does not allow him to infer those. Of course, it may allow him to conduct another attack
    (such as man-in-the-middle) which gives him some short-term keys, but he does not automatically get them
    just by acquiring the long-term key.

...and of course, there are other definitions out there, but this one is pretty non-controversial, and captures the general gist of it.

So, back to the point: I'm puzzled by the assertion that PFS is not a requirement for capwap, and I want to assert that in fact, it *is* a requirement.

Why? Because WTP's will often be deployed in scenarios where physical security is very difficult, if not impossible to provide. That being the case, their credentials (i.e. the long-term key referred to above) could be compromised at any time, possibly without detection. If compromising this key allows someone to decrypt previously recorded exchanges (and future ones by simply recording them), this violates the confidentiality requirement which led us to support encryption to begin with.

As it turns out, DTLS supports PFS, provided we choose the right key exchange (KE) schemes. In particular, the DHE_PSK ciphersuites provide PFS, while the vanilla PSK and RSA_PSK ciphersuites do not.

We can easily deal with this by naming only the appropriate ciphersuites in the spec, but I think it's important that we explicitly assert PFS as a requirement now, so that someone doesn't inadvertantly add support for the "wrong" KE schemes in the future.

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: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Mar 2006 18:52:09 -0500 (EST)

Hi Charles,

>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 know of at least two interesting use cases. I want to spend a little more time thinking about this before summarizing those - I'll post a follow-up by Monday.

Scott