Capwap Mailing List: Re: Consensus check for Issue 138:encryption/decryptionatWTP/AC

[Pat Calhoun (pacalhou) (pcalhoun]

Title: Re: [Capwap] Consensus check for Issue 138:encryption/decryptionatWTP/AC

To reiterate, option 2 does not remove centralized encryption as an option, so these arguments are unnecessary. If someone deems this model as necessary, the standard supports it, and customers that feel they need it will ask for it.

But to address Mervyn's point, this is a misrepresentation of the FIPS requirement. WTP encryption systems have passed the scrutinity of FIPS certification. But that's irrelevant to the question posed by the chair.

PatC

 -----Original Message-----
From:   Merwyn Andrade [mailto:mandrade [at] arubanetworks.com]
Sent:   Thursday, March 01, 2007 07:11 PM Pacific Standard Time
To:     Dorothy.Gellert [at] nokia.com; capwap [at] frascone.com
Cc:     margaret [at] thingmagic.com
Subject:        Re: [Capwap] Consensus check for Issue 138:encryption/decryptionatWTP/AC

I support Option 1 for all the reasons Dorothy Stanley already covered. One additional, but very important point. Option 1 (via preservation of centralized encryption support on WTPs) clearly and cost-effectively meets the end-to-end assured channel requirements within the Federal market (as specified in 8100.2) and reduces the burden to FIPS certify existing WTPs and modify them. More details on the directive and what it means to Federal customers below.

The updated and long awaited DoD 8100.2 directive released June 02, 2006 which opened the floodgate for implementation of COTS (Commercial Off The Shelf) 802.11i technology for use in the Federal market, states
"encryption for unclassified data in transit via WLAN-enabled devices, systems, and technologies must be implemented end-to-end over an assured channel and be validated by NIST as meeting requirements per FIPS 140-2 Overall Level 1 at a minimum. If WLAN infrastructure devices which store keying information are used in public unprotected environments, then those products must meet FIPS 140-2 Overall Level 2".

It is quite clear to budget constrained Federal customers that 802.11i FIPS validated WTPs, that do not handle the un-encrypted tunnel behind the WTP-to-AC do not meet the end-to-end directives. Why you may ask does end-to-end extend to an AC? Prior to WPA2/802.11i, first generation deployment of WLANs entailed deployment of L3 VPNs over untrusted wireless and created a compliance environment where assured-channel encryption traversed from FIPS approved VPN clients all the way to the VPN concentrator (the policy boundary). The wireless and wired network was clearly untrusted. Having to pursue waivers to already granted approvals to their existing policy boundaries by requesting that they be moved down to individual WTPs (for distributed encryption) is an even more painful and expensive endeavor and a non-starter.

In centralized encryption one end of the end-to-end assured channel is the FIPS 140-2 approved 802.11i client station and the other end of the policy boundary is where the 802.1X/11i key management/authorization functions are carried out. The end-to-end assured channel is the link between the 802.11i station and the AC. This easy replacement of a VPN concentrator with centralized 802.11i encryption gear to meet current mandates and policy boundaries for "end-to-end assured channel" represent the cleanest way of not having to redo one's compliance.

It has been argued that with DTLS support for the data-channel it should be possible to encrypt behind the AP (in distributed encryption modes), and meet the end-to-end assured channel. While possible in theory, this ignores the fact that today's WTPs do not have crypto assist to bulk re-encrypt 802.11i into a DTLS data channel and with 11n bandwidths this is only getting worse. Centralized encryption provides a fighting chance for these WTPs to perform only control-channel encryption and leave data-channel security to the AC while not needing them to be FIPS certified. A double advantage.

Mandating DTLS crypto assist support (to meet the bulk-encryption needs to compete in Federal), both hurts the chances of current generation CAPWAP WTPs as candidates in the Federal market, and increases prices on WTPs via the need for a FIPS-140-2 Level 2 (v/s 1) certification. This is because as per 8100.2 above "If WLAN infrastructure devices which store keying information are used in public unprotected environments, then those products must meet FIPS 140-2 Overall Level 2" (WTPs/APs are typically in hostile user space and not locked in a closet).

I am not against the distributed encryption model but believe both modes should be available for customers to make an informed choice based on the level of security and the markets they want to pursue.

This (need to FIPS certify WTPs, as well as the need to add crypto assist for DTLS to meet assured channel needs), v/s offloading 802.11i encryption to the AC/controller is the better of two burdens to WTP vendors to preserve their ability to mate with CAWPAP compliant centralized encryption vendors and pursue federal markets. In these times of tight war budgets this is an important and far superior security option that we need to preserve for federal customers to allow them to take advantage of COTS gear as we proceed towards an interoperable WTP-AC CAPWAP protocol.

Merv

Merwyn (Merv) Andrade
CTO, Aruba Networks
merv [at] arubanetworks.com
________________________________________
From: Dorothy.Gellert [at] nokia.com [mailto:Dorothy.Gellert [at] nokia.com]
Sent: Friday, February 23, 2007 2:46 PM
To: capwap [at] frascone.com
Cc: margaret [at] thingmagic.com; Dorothy.Gellert [at] nokia.com
Subject: [Capwap] Consensus check for Issue 138: encryption/decryption atWTP/AC
Dear CAPWAP WG,
During the CAPWAP Interim meeting in San Jose last month, we discussed issue 138: Wireless Encryption/Decryption at the WTP/AC, but did not achieve clear consensus. This issue has been discussed at length since IETF 67 in San Diego and on the list over the past few months.
The chairs would like to close this issue  with WG consensus on one of the following proposals that have the most WG support:
1) To provide system component interoperability, the WTP MUST support 802.11 encryption/decryption at the WTP, and the WTP MUST support 802.11 encryption/decryption at the AC. The AC MUST support either 802.11 encryption/decryption at the WTP or 802.11 encryption/decryption at the AC.
The AC MAY support both 802.11 encryption/decryption at the WTP and 802.11 encryption/decryption at the AC.
-OR-
2) To provide system component interoperability, the WTP and AC must support 802.11 encryption/decryption at the WTP. The WTP and AC MAY support 802.11 encryption/decryption at the AC.
Note the 2 proposals differ with support of 802.11 encryption/decryption at the AC.
As there has been no objections to the optional use of DTLS in the Data Plane, this portion of issue 138 is closed.
Please submit your choice and opinions on this topic to the WG list by March 1st for a final consensus call on this feature.   This is a short consensus call since the last date to submit drafts for IETF 68 is March 5th.   If we cannot agree to come to consensus in the next week, this issue will remain unresolved in the draft targeted for review in IEEE. 
Best Regards,
Dorothy, Mani and Margaret.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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