Subject: Re: [Capwap] Encryption Capabilities

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Wed, 7 Jun 2006 08:39:57 -0700

Hi Charles,

Right!  I view the 11i security and CAPWAP security as orthogonal.  To
state whether the 11i is "centralized" or not is different from whether
we should protect the CAPWAP data plane...from a security standpoint,
the CAPWAP protocol must provide its own security mechanism to ensure
that both confidentiality and integrity are provided for its own
encapsulation.  I agree that letting users pick which one is very
dangerous indeed.

While the 11i security is not affected by where the 11i crypto is done
(within the CAPWAP context),  failure to protect the CAPWAP data plane
will render it (the CAPWAP data transport) vulnerable to attack. 

	Nancy. 

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Wednesday, June 07, 2006 6:25 AM
To: Nancy Winget (ncamwing)
Cc: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap] Encryption Capabilities

Nancy,

You've brought up a good point.  Relying on 11i to encrypt data packets
between the WTP and AC only provides confidentiality of the data, and
does not protect the CAPWAP data transport protocol.

Each scenario has its pros and cons... this to me implies they should
all be supported in the standard, and let users pick the one that fits
their environment (though that can be dangerous when it comes to
security).

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

Nancy Winget (ncamwing) wrote:
> Charles,
> 
> I think I agree with you though I'm not sure I understand the full 
> thread.
> 
> It seems that the current email thread is mixing the securing of 
> different transport layers, e.g. CAPWAP with that of 802.11i.
> 
> 802.11i is designed to afford protection of the 802.11 transport 
> layer, providing both packet confidentiality and authentication; but 
> it does not address securing the CAPWAP transport layer.  An obvious 
> example of this is that the CAPWAP header is not authenticated!
> 
> So whether the 802.11i crypto is done either at the WTP or AC should 
> be construed as a different feature than that of securing the CAPWAP 
> transport layer.  Also, I do not understand what the notion of 
> "centralized" encryption is as the client has no clue of the topology 
> or architecture behind the AP?
> 
>>From a threat model, if we are intending to address secure transport 
>>of
> data packets within CAPWAP, doing 802.11i at the AC does not address 
> this requirement, CAPWAP must secure its own encapsulation as well.
> That is why the draft includes the option of establishing a DTLS 
> tunnel for its data transport.
> 
>    Nancy.
> 
> 
> 
> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]]
> Sent: Tuesday, June 06, 2006 7:53 PM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]
> Subject: Re: [Capwap] Encryption Capabilities
> 
> Removing centralized encryption doesn't change the security properties

> of CAPWAP.
> 
> HOWEVER, if you really want packets encrypted all the way to the AC, 
> and you remove centralized encryption, your WTPs first have to decrypt

> the
> 802.11 packet, and then re-encrypt it for DTLS transport.  This seems 
> like a lot of extra processor time for devices that need to be cheap 
> and disposable.  For example, OpenSSL on my dual 2.8GHz P4 machine can

> process AES at roughly 424Mbps [1].  An embedded device with 1/10 my 
> processing power could only keep up with a 21.2 Mbps data flow.
> 
> [1] openssl speed -elapsed -evp aes-128-cbc
> 
> --
> t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy
> 
> Pat Calhoun (pacalhou) wrote:
> 
>>But what we end up doing is providing two means to do the exact same 
>>thing. I admit that I was surprised when the optional DTLS support was
> 
> 
>>added for data frames in the CAPWAP draft. However, having thought 
>>through the impact of this change, it actually does address the 
>>previous issues I had raised against centralized 802.11i security,
> 
> which are:
> 
>> 
>>1. By encrypting at the AC, how does one support 802.11e (specifically
> 
> 
>>frame fragmentation to fit a service period) 2. How does the AC 
>>provide 802.11n A-MPDU/MSDU aggregation?
>> 
>>So I would propose we define one way, and I prefer the DTLS mechanism 
>>as it doesn't introduce any issues in supporting any 802.11 feature.
>>
>>Pat Calhoun
>>CTO, Wireless Networking Business Unit Cisco Systems
>>
>> 
>>
>>
> 
> ----------------------------------------------------------------------
> --
> 
>>    *From:* Dorothy Stanley [mailto:[email-masked]]
>>    *Sent:* Monday, June 05, 2006 5:04 PM
>>    *To:* Pat Calhoun (pacalhou)
>>    *Cc:* Michael Montemurro; David T. Perkins; [email-masked]
>>    *Subject:* Re: [Capwap] Encryption Capabilities
>>
>>
>>    I do not agree with always requiring the WTP to provide wireless
>>    encryption. The split MAC architecture allows 802.11
>>    encryption/decryption
>>    at either the WTP or the AC, and this flexibility should be
>>    retained, with use of the
>>    field in question clearly defined.
>>
>>    Dorothy
>>
>>
>>    On 6/5/06, *Pat Calhoun (pacalhou)* <[email-masked]
>>    <mailto:[email-masked]>> wrote:
>>
>>        Actually, this field was intended to allow the WTP to
>>        communicate whether it is capable of providing its
> 
> capabilities,
> 
>>        and therefore allow the AC to determine whether it should
>>        perform centralized encryption. However, with the transition
> 
> to
> 
>>        DTLS, I propose that we always require the WTP to provide
>>        wireless encryption, and use DTLS between the AC and the WTP.
>>         
>>
>>        Pat Calhoun
>>        CTO, Wireless Networking Business Unit
>>        Cisco Systems
>>
>>         
>>
>>
> 
> ----------------------------------------------------------------------
> --
> 
>>            *From:* Michael Montemurro
>>            [mailto:[email-masked]
>>            <mailto:[email-masked]>]
>>            *Sent:* Saturday, June 03, 2006 12:12 PM
>>            *To:* David T. Perkins
>>            *Cc:* [email-masked] <mailto:[email-masked]>
>>            *Subject:* Re: [Capwap] Encryption Capabilities
>>
>>        David,
>>         
>>        Would it be sufficient to move Encryption Capabilities from
> 
> the
> 
>>        WTP Descriptor (Section 4.4.34) to the WTP Radio Information
>>        message element (Section 4.4.39)?
>>         
>>        Mike
>>
>>         
>>        On 6/3/06, *Michael Montemurro* <[email-masked]
>>        <mailto:[email-masked]>> wrote:
>>
>>            David,
>>
>>            I've created issue 125 to track this issue.
>>             
>>            Mike
>>
>>             
>>            On 6/1/06, *David T. Perkins* <[email-masked]
>>            <mailto:[email-masked]>> wrote:
>>
>>                HI,
>>
>>                The "(4.4.34)WTP Descriptor" message element has the
>>                subfield "encryption capabilities". What is this used
>>                for? If for radios, then it should be per radio. If
>>                for the user data between the WTP and AC, then
>>                it doesn't seem appropriate to say the value is
>>                defined by "specific binding" definitions because
>>                the WTP can be supporting multiple radios with
>>                some that provide encryption services and some
>>                that don't.
>>
>>                In general, I don't feel that this subfield is
>>                well defined, and it appears to me that it
>>                should be a per radio attribute.
>>
>>                Regards,
>>                /david t. perkins
>>
>>
> 
> _________________________________________________________________
> 
>>                To unsubscribe or modify your subscription options,
>>                please visit:
>>                http://lists.frascone.com/mailman/listinfo/capwap
>>                <http://lists.frascone.com/mailman/listinfo/capwap>
>>
>>                Archives: http://lists.frascone.com/pipermail/capwap
>>                <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
>>        <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
> 
> 
> 
> _________________________________________________________________
> 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

---

From: Charles Clancy <[email-masked]>
Date: Wed, 07 Jun 2006 13:53:53 -0400

Nancy,

I agree they are orthogonal.  Each requires processing power to encrypt 
and decrypt, and we need to make sure we don't overload either the WTPs 
or ACs.

If I recall correctly, the original CAPWAP model assumed an unprotected 
data plane.  The thought being that in order to attack the data plane 
you need access to the wired network, and if you already have access to 
the wired network, why do you need to attack CAPWAP to get network 
connectivity?

The desire to support broader backhauls (wireless, Internet, hostile 
network, etc) of the CAPWAP link has fueled interest in securing the 
data plane.  If people really do want a fully-secured data plane, it 
does indeed need to flow over a DTLS-protected channel.

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