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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 1 Mar 2007 20:17:56 -0800

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:[email-masked]]
Sent:	Thursday, March 01, 2007 07:11 PM Pacific Standard Time
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
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
[email-masked]
________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 2:46 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: <[email-masked]>
Date: Thu, 1 Mar 2007 22:24:18 -0600

I suggest we look at the FIPs requirements and their applicability to
centralized encryption vs WTP encryption during the f2f meeting and
consider adding text to the security section as a separate issue.   
 
BR,
DorothyG

________________________________

	From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]] 
	Sent: Thursday, March 01, 2007 8:18 PM
	To: Merwyn Andrade; Gellert Dorothy (Nokia-SIR/MtView);
[email-masked]
	Cc: [email-masked]
	Subject: 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:[email-masked]]
	Sent:   Thursday, March 01, 2007 07:11 PM Pacific Standard Time
	To:     [email-masked]; [email-masked]
	Cc:     [email-masked]
	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
	[email-masked]
	________________________________________
	From: [email-masked]
[mailto:[email-masked]]
	Sent: Friday, February 23, 2007 2:46 PM
	To: [email-masked]
	Cc: [email-masked]; [email-masked]
	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

---

From: "Merwyn Andrade" <[email-masked]>
Date: Thu, 1 Mar 2007 20:57:21 -0800

To your two points 

1) <PatC> "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."

<Merv> That is not correct by making it optional, you are trying to ensure that it is not part of a CAPWAP baseline for WTP implementers. Your word-smithing doesn't change that fact. As Dorothy Stanley eloquently said (and clearly proved by Saravanan and others after lot of back and forth on the KeyRsc 0 issue)

"Option 1 WTPs support all 802.11 security guarantees, and provide 
end to end station-to-AC security. 
Option 2 WTPs do not support all 802.11 security guarantees."

I could have just as easily argued that centralized encryption support was mandatory and distributed optional, but I didn't since by keeping both modes mandatory in, we let a baseline have sufficient functionality to meet both interoperability and markets with differing security needs. 

2) Nice try but no misrepresentation. The end-to-end directive is clear about FIPS certifications and the mandate for End-to-End-Assured channels. End-to-End is to a policy boundary, if you want to convince your customers to buy legacy FIPS approved WTP gear with additional wired side protection hardware or possibly new WTPs with bulk DTLS encryption and still more termination hardware, to meet "the encryption of unclassified data in transit" requirement good for your bottom line and bad for their budgets. Anyone in the FIPS business knows that just because a WTP passed FIPS validation doesn't mean the cryptographic boundaries you drew around it (to get it certified) met the end-to-end assured channel needs. 
Merv

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]
________________________________________
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 8:18 PM
To: Merwyn Andrade; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Capwap] Consensus check for Issue 138:encryption/decryptionatWTP/AC

PatC

 -----Original Message-----

Merv

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 2 Mar 2007 04:48:31 -0800

Dorothy, 
 
I do not believe that trying to interpret FIPS requirements are really
useful at the face to face meeting. Clearly, we have differing opinions
of the requirements, and the term "end-to-end" claimed by Mervyn is open
to interpretation. The DoD has not provided such guidance, so such a
discussion would simply be each other's interpretation of US Gov't
requirements.
 
The reality is that Cisco's LWAPP based architecture, which uses
encryption at the WTP, has passed FIPS certification. For proof, look
under "Cisco 4400" at http://csrc.nist.gov/cryptval/aes/aesval.html. The
actual FIPS certificate can be found at
http://csrc.nist.gov/cryptval/140-1/140crt/140crt693.pdf.
 
Once more, vendors that interpret the requirements such as Mervyn are
not excluded from delivering such systems to their customers using
either option. I would note, however, that undergoing the FIPS
validation process is a very complex and expensive proposition. Just by
supporting an option does not make one "FIPS validated", so I don't
think it is unreasonable to make this an optional feature that would be
implemented by vendors that target that market.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Thursday, March 01, 2007 8:24 PM
	To: Pat Calhoun (pacalhou); [email-masked];
[email-masked]
	Cc: [email-masked]
	Subject: RE: [Capwap] Consensus check for Issue
138:encryption/decryptionatWTP/AC

	I suggest we look at the FIPs requirements and their
applicability to centralized encryption vs WTP encryption during the f2f
meeting and consider adding text to the security section as a separate
issue.   
	 
	BR,
	DorothyG

		From: ext Pat Calhoun (pacalhou)
[mailto:[email-masked]] 
		Sent: Thursday, March 01, 2007 8:18 PM
		To: Merwyn Andrade; Gellert Dorothy (Nokia-SIR/MtView);
[email-masked]
		Cc: [email-masked]
		Subject: 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:[email-masked]]
		Sent:   Thursday, March 01, 2007 07:11 PM Pacific
Standard Time
		To:     [email-masked]; [email-masked]
		Cc:     [email-masked]
		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.

		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
		[email-masked]
		________________________________________
		From: [email-masked]
[mailto:[email-masked]]
		Sent: Friday, February 23, 2007 2:46 PM
		To: [email-masked]
		Cc: [email-masked]; [email-masked]
		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

---

From: "Nehru Bhandaru" <[email-masked]>
Date: Fri, 2 Mar 2007 06:13:03 -0700

I think everyone agrees on having the flexibility to do
encryption/decryption on the WTP or AC. Option 2 does not prevent it.
However, Option 2 may prevent an existing deployment to be migrated to
centralized encryption. Consider deployments with WTPs that support only
WTP-based encryption; In order to migrate to centralized encryption,
WTP's will have to be (software) upgraded.

I think disabling hardware encryption is already supported on WTPs (
most support software encryption/decryption). So, there is no real
penalty for choosing Option 1 - which would be my choice.

- Nehru

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, March 02, 2007 7:49 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [Capwap] Consensus check for
Issue138:encryption/decryptionatWTP/AC

Dorothy, 

Pat Calhoun

	BR,

	DorothyG

		
		
		PatC
		
		 -----Original Message-----
		From:   Merwyn Andrade

		

		

		
		Merv
		
		Merwyn (Merv) Andrade
		CTO, Aruba Networks
		[email-masked]

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 2 Mar 2007 05:35:41 -0800

Nehru, I'd like to ask a clarifying question. You state that the
standard could cause a network to migrate from centralized to WTP
encryption. Wouldn't existing deployments only include equipment from a
single vendor, and vendors that sell centralized encryption not be
motivated to implement the centralized encryption option?
 
I'm not sure that I understand how any one of the options makes the
scenario you stated below more likely to occur.

Pat Calhoun

	From: Nehru Bhandaru [mailto:[email-masked]] 
	Sent: Friday, March 02, 2007 5:13 AM
	To: Pat Calhoun (pacalhou); [email-masked];
[email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Capwap] Consensus check for
Issue138:encryption/decryptionatWTP/AC

	I think disabling hardware encryption is already supported on
WTPs ( most support software encryption/decryption). So, there is no
real penalty for choosing Option 1 - which would be my choice.

	- Nehru

	Dorothy, 

	I do not believe that trying to interpret FIPS requirements are
really useful at the face to face meeting. Clearly, we have differing
opinions of the requirements, and the term "end-to-end" claimed by
Mervyn is open to interpretation. The DoD has not provided such
guidance, so such a discussion would simply be each other's
interpretation of US Gov't requirements.

	Once more, vendors that interpret the requirements such as
Mervyn are not excluded from delivering such systems to their customers
using either option. I would note, however, that undergoing the FIPS
validation process is a very complex and expensive proposition. Just by
supporting an option does not make one "FIPS validated", so I don't
think it is unreasonable to make this an optional feature that would be
implemented by vendors that target that market.

	Pat Calhoun

		BR,

		DorothyG

			From: ext Pat Calhoun (pacalhou)
[mailto:[email-masked]] 
			Sent: Thursday, March 01, 2007 8:18 PM
			To: Merwyn Andrade; Gellert Dorothy
(Nokia-SIR/MtView); [email-masked]
			Cc: [email-masked]
			Subject: 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.

			PatC
			
			 -----Original Message-----
			From:   Merwyn Andrade
[mailto:[email-masked]]
			Sent:   Thursday, March 01, 2007 07:11 PM
Pacific Standard Time
			To:     [email-masked];
[email-masked]
			Cc:     [email-masked]
			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".

			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
			[email-masked]
			________________________________________
			From: [email-masked]
[mailto:[email-masked]]
			Sent: Friday, February 23, 2007 2:46 PM
			To: [email-masked]
			Cc: [email-masked];
[email-masked]
			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:

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

---

From: "Merwyn Andrade" <[email-masked]>
Date: Fri, 2 Mar 2007 07:24:05 -0800

Thank you very much for bring this up. Good now we can actually compare data on a FIPS validation page. You just made my point below when you highlight just your Controller/AC certification (693) instead of WTP (same page 373). 
Let's draw it out for folks to really understand.

1) LWAPP Architecture
   #####################  373             693
   #                   #  %%%%%%%%%%%%%%%%%%%%%%%
   # +------+         +#--%-+   LWAPP   +----+  %
   # |client|---------| WTP |===========| AC |  %
   # +------+         +#--%-+           +----+  %
   #                   #  %%%%%%%%%%%%%%%%%%%%%%%
   # < encrypted data> #  < --unencrypted - >
   #                   #         data
   #####################        
   <-Assured data channel->      
                
Two FIPS certs (373 and 693) and a end-to-end assured channel that terminates at the WTP. To again point out the guidelines that proves the WTP and the AC must be included in the end-to-end I refer you to 8100.2, 
" ..encryption for unclassified data in transit via WLAN-enabled devices ,systems, and technologies "
The data is in transit from a client -> WTP -> AC a WLAN system.
See the point in the directive about "WLAN enabled devices, systems and technologies". It is very easy to confuse folks with FIPS certs but the 8100.2 policy and not how folks creatively interpret or add themselves to FIPS validation lists is what matters.                       

2) Centralized Encryption Architecture
   ##############################################              
   #                                      315   #
   # +------+         +-----+           +----+  #
   # |client|---------| WTP |===========| AC |  #
   # +------+         +-----+           +----+  #
   # <------------encrypted data--------------> #       
   #                                            #
   ##############################################        
   <--------Assured data channel---------------->                      
One FIPS cert (315) for the controller, none required for the WTP and a end-to-end assured channel from client to the AC. The assured channel for unclassified data is over the entire system. No WTP FIPS cert was needed. 
Go and take a look at any VPN solution and you'll see one cert for a client and one for the concentrator. 

Facts speak for themselves. 
Merv  

PS: I reiterate I'm not against decentralized encryption. If someone needs that option in the market, I'll go and FIPS certify my WTPs. I think however we are talking about the CAPWAP standard and not what suits us so we need to let the market choose from both options v/s spec-ing one out of the mandatory-to-implement list. I rest my case.

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]
________________________________________
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, March 02, 2007 4:49 AM
To: [email-masked]; Merwyn Andrade; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Consensus check for Issue 138:encryption/decryptionatWTP/AC

Dorothy, 
 
I do not believe that trying to interpret FIPS requirements are really useful at the face to face meeting. Clearly, we have differing opinions of the requirements, and the term "end-to-end" claimed by Mervyn is open to interpretation. The DoD has not provided such guidance, so such a discussion would simply be each other's interpretation of US Gov't requirements.
 
The reality is that Cisco's LWAPP based architecture, which uses encryption at the WTP, has passed FIPS certification. For proof, look under "Cisco 4400" at http://csrc.nist.gov/cryptval/aes/aesval.html. The actual FIPS certificate can be found at http://csrc.nist.gov/cryptval/140-1/140crt/140crt693.pdf.
 
Once more, vendors that interpret the requirements such as Mervyn are not excluded from delivering such systems to their customers using either option. I would note, however, that undergoing the FIPS validation process is a very complex and expensive proposition. Just by supporting an option does not make one "FIPS validated", so I don't think it is unreasonable to make this an optional feature that would be implemented by vendors that target that market.
 
Pat Calhoun

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 8:24 PM
To: Pat Calhoun (pacalhou); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Consensus check for Issue 138:encryption/decryptionatWTP/AC
I suggest we look at the FIPs requirements and their applicability to centralized encryption vs WTP encryption during the f2f meeting and consider adding text to the security section as a separate issue.   
 
BR,
DorothyG

To: Merwyn Andrade; Gellert Dorothy (Nokia-SIR/MtView); [email-masked]

PatC

 -----Original Message-----

Merv

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 2 Mar 2007 07:30:41 -0800

Merwyn, this is an interesting discussion, and while I disagree with some of your statements, I would like the bring the discussion back to the original question, which is whether we should adopt option 1 or option 2. To re-iterate, there is nothing in option 2 that disallows a customer from supporting either of the scenarios below. The question is whether WTP vendors are forced to support this mode of operation, for which I have provided my reasons on why this is problematic in my original post. I stand by those statements.

Pat Calhoun

> Sent: Friday, March 02, 2007 7:24 AM
> Thank you very much for bring this up. Good now we can 
> actually compare data on a FIPS validation page. You just 
> made my point below when you highlight just your 
> Controller/AC certification (693) instead of WTP (same page 373). 
> Two FIPS certs (373 and 693) and a end-to-end assured channel 
> that terminates at the WTP. To again point out the guidelines 
> that proves the WTP and the AC must be included in the 
> end-to-end I refer you to 8100.2, " ..encryption for 
> unclassified data in transit via WLAN-enabled devices 
> ,systems, and technologies "
> See the point in the directive about "WLAN enabled devices, 
> systems and technologies". It is very easy to confuse folks 
> with FIPS certs but the 8100.2 policy and not how folks 
> creatively interpret or add themselves to FIPS validation 
> lists is what matters.                       
> 
> 
> One FIPS cert (315) for the controller, none required for the 
> WTP and a end-to-end assured channel from client to the AC. 
> The assured channel for unclassified data is over the entire 
> system. No WTP FIPS cert was needed. 
> Go and take a look at any VPN solution and you'll see one 
> cert for a client and one for the concentrator. 
> 
> PS: I reiterate I'm not against decentralized encryption. If 
> someone needs that option in the market, I'll go and FIPS 
> certify my WTPs. I think however we are talking about the 
> CAPWAP standard and not what suits us so we need to let the 
> market choose from both options v/s spec-ing one out of the 
> mandatory-to-implement list. I rest my case.
> 
> Merwyn (Merv) Andrade
> CTO, Aruba Networks
> [email-masked]
> I do not believe that trying to interpret FIPS requirements 
> are really useful at the face to face meeting. Clearly, we 
> have differing opinions of the requirements, and the term 
> "end-to-end" claimed by Mervyn is open to interpretation. The 
> DoD has not provided such guidance, so such a discussion 
> would simply be each other's interpretation of US Gov't requirements.
>  
> The reality is that Cisco's LWAPP based architecture, which 
> uses encryption at the WTP, has passed FIPS certification. 
> For proof, look under "Cisco 4400" at 
> http://csrc.nist.gov/cryptval/aes/aesval.html. The actual 
> FIPS certificate can be found at 
> Mervyn are not excluded from delivering such systems to their 
> customers using either option. I would note, however, that 
> undergoing the FIPS validation process is a very complex and 
> expensive proposition. Just by supporting an option does not 
> make one "FIPS validated", so I don't think it is 
> unreasonable to make this an optional feature that would be 
> applicability to centralized encryption vs WTP encryption 
> during the f2f meeting and consider adding text to the 
> security section as a separate issue.   
>  
> BR,
> DorothyG
> 
> 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 
> the FIPS requirement. WTP encryption systems have passed the 
> scrutinity of FIPS certification. But that's irrelevant to 
> 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
> 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.
> 
> 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.
> 
> 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 
> control-channel encryption and leave data-channel security to 
> the AC while not needing them to be FIPS certified. A double 
> advantage.
> 
> 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 
> 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).
> 
> 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.
> 
> 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
> [email-masked]
> 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:
> 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 
> 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,

---

From: "Nehru Bhandaru" <[email-masked]>
Date: Fri, 2 Mar 2007 09:52:05 -0700

Pat,

If you are saying deployment scenarios must be considered independent of
options, I agree.

Consider a single vendor standard CAPWAP-based deployment that is set up
to use WTP encryption - this is allowed under both options under
consideration. If option 2 is chosen, the vendor solution where the WTP
does not support AC-based encryption/decryption would be possible and
the customer loses the option of moving to AC-based encryption - with
the same or another vendor - without upgrading or replacing the WTPs.

We could debate if the customer really needs that flexibility. I'd
choose a more flexible option if there is no or very little cost
associated.

- N

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, March 02, 2007 8:36 AM
To: Nehru Bhandaru; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Consensus check for
Issue138:encryption/decryptionatWTP/AC

Pat Calhoun

	- Nehru

	Dorothy, 

	Pat Calhoun

		BR,

		DorothyG

			
			
			PatC
			
			 -----Original Message-----
			From:   Merwyn Andrade

			

			

			
			Merv
			
			Merwyn (Merv) Andrade
			CTO, Aruba Networks
			[email-masked]

			
			Archives:

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 2 Mar 2007 13:53:05 -0500 (EST)

While it's not necessarily a FIPS requirement (yet), the DoD is evaluating
using CAPWAP centralized encryption for providing access to USG networks. 
This would allow them to provide secure access to a protected network. 
The protected network could be behind the AC, and a wired DMZ of sorts
could provide connectivity to the WTPs.  Without centralized encryption,
such a deployment could not be supported.

As far as what's mandatory to implement where, I guess I don't really
care, as long as it's still realtively easy to do centralized encryption.

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 2 Mar 2007 15:30:28 -0800

Thanks for the clarification, Nehru.

I think the argument you are raising is that flexibility can only be
achieved by making both features mandatory to implement. I will note
that there are other optional features in the CAPWAP protocol that have
a much more drastic effect on a customer's network than the one being
discussed here. For instance, the CAPWAP protocol states that Local MAC
is mandatory, while Split MAC is optional. Looking at the taxonomy spec,
you will note that six vendors supported Split MAC, while only five
supported Local MAC.

I will submit that a customer running a Split MAC network today that
installs a new wiz-bang CAPWAP WTP that only support Local MAC is in for
a much larger surprise than he would in the scenario you describe below.
The difference between these two features are very dramatic. They alter
the behavior of the CAPWAP devices, as well as the network. Yet, as
vendors we were able to agree that Local MAC was the simplest to
implement, and it would be the mandatory mode. Is this my preferred
approach? Absolutely not, but I recognized the complexity of supporting
both modes, and realized we had to make a call. In the end, as long as
Split MAC was an option, then I could provide products to my customers
to allow them to continue to operate their network in the same manner as
they do today. And then we can have the discussion of the format of the
frames when they are tunneled (e.g., 802.3 vs. 802.11), whether
tunneling exists or not, certificates vs. pre-shared keys, and the list
goes on. 

We've been creating protocols here at the IETF for a very long time, and
we have been successful by making sure that protocols had a minimal
profile of mandatory to implement, while providing the flexibility for
vendors to provide differentiation (and customers to chose based on
their needs). The argument being raised here that interoperability can
only be guaranteed by forcing the WTP vendor to support both modes of
encryption does not guarantee interoperability with existing network
deployments. If we want to use that line of thinking, then we need to
apply it to all features in the protocol - a very slippery slope....

Pat Calhoun

	Sent: Friday, March 02, 2007 8:52 AM

	Pat,

	If you are saying deployment scenarios must be considered
independent of options, I agree.

	Consider a single vendor standard CAPWAP-based deployment that
is set up to use WTP encryption - this is allowed under both options
under consideration. If option 2 is chosen, the vendor solution where
the WTP does not support AC-based encryption/decryption would be
possible and the customer loses the option of moving to AC-based
encryption - with the same or another vendor - without upgrading or
replacing the WTPs.

	We could debate if the customer really needs that flexibility.
I'd choose a more flexible option if there is no or very little cost
associated.

	- N

	I'm not sure that I understand how any one of the options makes
the scenario you stated below more likely to occur.

	Pat Calhoun

		I think disabling hardware encryption is already
supported on WTPs ( most support software encryption/decryption). So,
there is no real penalty for choosing Option 1 - which would be my
choice.

		- Nehru

		Dorothy, 

		I do not believe that trying to interpret FIPS
requirements are really useful at the face to face meeting. Clearly, we
have differing opinions of the requirements, and the term "end-to-end"
claimed by Mervyn is open to interpretation. The DoD has not provided
such guidance, so such a discussion would simply be each other's
interpretation of US Gov't requirements.

		The reality is that Cisco's LWAPP based architecture,
which uses encryption at the WTP, has passed FIPS certification. For
proof, look under "Cisco 4400" at
http://csrc.nist.gov/cryptval/aes/aesval.html. The actual FIPS
certificate can be found at
http://csrc.nist.gov/cryptval/140-1/140crt/140crt693.pdf.

		Once more, vendors that interpret the requirements such
as Mervyn are not excluded from delivering such systems to their
customers using either option. I would note, however, that undergoing
the FIPS validation process is a very complex and expensive proposition.
Just by supporting an option does not make one "FIPS validated", so I
don't think it is unreasonable to make this an optional feature that
would be implemented by vendors that target that market.

		Pat Calhoun

			To: Pat Calhoun (pacalhou);

			I suggest we look at the FIPs requirements and
their applicability to centralized encryption vs WTP encryption during
the f2f meeting and consider adding text to the security section as a
separate issue.   

			BR,

			DorothyG

				From: ext Pat Calhoun (pacalhou)
[mailto:[email-masked]] 
				Sent: Thursday, March 01, 2007 8:18 PM
				To: Merwyn Andrade; Gellert Dorothy
(Nokia-SIR/MtView); [email-masked]
				Cc: [email-masked]
				Subject: Re: [Capwap] Consensus check
for Issue 138:encryption/decryptionatWTP/AC

				
				PatC
				
				 -----Original Message-----
				From:   Merwyn Andrade
[mailto:[email-masked]]
				Sent:   Thursday, March 01, 2007 07:11
PM Pacific Standard Time
				To:     [email-masked];
[email-masked]
				Cc:     [email-masked]
				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.

				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
				[email-masked]
				________________________________________
				From: [email-masked]
[mailto:[email-masked]]
				Sent: Friday, February 23, 2007 2:46 PM
				To: [email-masked]
				Cc: [email-masked];
[email-masked]
				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:

				Archives:

---

From: Jim Murphy <[email-masked]>
Date: Fri, 02 Mar 2007 15:59:27 -0800

Pat,

Thanks for pointing this out. This was my observation as well
but you beat me to the keyboard.

I support option 2.

Thanks,

Jim

Pat Calhoun (pacalhou) wrote:
>     ------------------------------------------------------------------------
>     *From:* Nehru Bhandaru [mailto:[email-masked]]
>     *Sent:* Friday, March 02, 2007 8:52 AM
>     *To:* Pat Calhoun (pacalhou); [email-masked];
>     *Cc:* [email-masked]
>     *Subject:* RE: [Capwap] Consensus check for
>     Consider a single vendor standard CAPWAP-based deployment that is
>     set up to use WTP encryption – this is allowed under both options
>     under consideration. If option 2 is chosen, the vendor solution
>     where the WTP does not support AC-based encryption/decryption would
>     be possible and the customer loses the option of moving to AC-based
>     encryption – with the same or another vendor - without upgrading or
>     replacing the WTPs.
> 
>      
> 
>     We could debate if the customer really needs that flexibility. I’d