Subject: RE: [Capwap] security in objectives draft

From: "Cheng Hong" <[email-masked]>
Date: Wed, 18 May 2005 07:12:11 +0800

Hi all,

Why the CAPWAP protocol needs to mandate the mechanism used in 802.11
procedures? Whether WEP should be used or not is just a local policy
issue at the AC. During the negotiation between the AC and WTP, they can
decide if WEP is acceptable. This is purely the operator's issue. As for
the CAPWAP protocol, it should just provide means for the negotiation,
e.g. for the AC to reject the WEP only WTP if the AC policy says so. 

The pre-RSN support is still a part of the 11, even with 11i.

cheers

Cheng Hong    

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pat Calhoun
> Sent: Wednesday, May 18, 2005 4:26 AM
> To: 'Matt Holdrege'; 'Charles Clancy'; [email-masked]
> Subject: RE: [Capwap] security in objectives draft
> 
> > With all due respect to the installed base of WEP-only 
> gear, the IETF 
> > should absolutely not make any exception in this or any 
> other similar 
> > case.
> > The legacy installed base has nothing to do with future IETF 
> > protocols, especially when it weakens security. Just because the 
> > CAPWAP protocol may be used by these legacy AP's, doesn't mean that 
> > they have to be forklift upgraded. What it means is that 
> they will not 
> > fully comply with the security portion of the specification. Anyone 
> > doing a security audit of such a network would reject any WEP-only 
> > gear in any case.
> > 
> > Think if we had rejected IPsec because the massive 
> installed base of 
> > Windows 3.1 intel-386 PC's couldn't comply with it.
> Matt, while I understand your concerns here, I don't agree 
> that the IETF is in a position to tell AP vendors what 
> security schemes they can and cannot support. In fact, as of 
> today, not supporting WTP would mean that the vendor would 
> lose their ability for WiFi certification. 
> 
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
> 

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Darren Loher" <[email-masked]>
Date: Tue, 17 May 2005 17:32:23 -0700

CAPWAP's scope is to define a solution between the WTP and AC.  It is
here that we do need to take a stand on the minimum security
requirements.  I do believe we owe it to the community to specify a
minimum security level and explicitly require that additional mechanisms
be allowed in the future, should the default/minimum become compromised
in the future.

CAPWAP probably shouldn't be directly concerned with which WTP to
STA/client security mechanisms are supported.  But rather CAPWAP should
make sure that it can "transparently transport" the
configuration/negotiation of WTP to STA security according to an
administratively defined policy, stored on or upstream of the AC.  

That being said, the WiFi alliance has been doing a good job of
informing and marketing it's certifications and labels for what level of
security devices are certified to.  Network implementers are starting to
get to know what WPA and WPA2 are.

--
Darren Loher
Senior Architect
Roving Planet  
http://www.rovingplanet.com
+1.303.996.7578

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Pat Calhoun
> Sent: Tuesday, May 17, 2005 2:26 PM
> > With all due respect to the installed base of WEP-only gear,
> > the IETF should absolutely not make any exception in this or
> > any other similar case.
> > protocols, especially when it weakens security. Just because
> > the CAPWAP protocol may be used by these legacy AP's, doesn't
> > mean that they have to be forklift upgraded. What it means is
> > that they will not fully comply with the security portion of
> > the specification. Anyone doing a security audit of such a
> > network would reject any WEP-only gear in any case.
> >
> > Think if we had rejected IPsec because the massive installed
> > base of Windows 3.1 intel-386 PC's couldn't comply with it.
> Matt, while I understand your concerns here, I don't agree that
> the IETF is in a position to tell AP vendors what security schemes
> they can and cannot support. In fact, as of today, not supporting
> WTP would mean that the vendor would lose their ability for
> WiFi certification.
> 
> 
> Pat Calhoun

---

From: "Randy Chou" <[email-masked]>
Date: Wed, 18 May 2005 10:06:33 -0700

Clint, agree 100% with what you are saying.  However, this also brings
up an interesting problem in the security requirements themselves of the
CAPWAP protocol being chosen.  If WEP and less secure encryption methods
are to be allowed for users which I believe they must, then that opens
up possible attacks on the wired side from within the wireless domain
since WEP is not secure.  If a proposal for CAPWAP is susceptible to
wired attacks, it is by this requirement that it is just as susceptible
to a wireless attack.  The seriousness of a wired security hole present
in the proposal is the same as that of a wireless security hole.

So whatever proposal CAPWAP ends up choosing must not have any security
holes, whether wired or wireless.  I would like to make sure we don't
trivialize the presence of a hole just because it appears to only be
on the wired side.

Regards,
 
--
Randy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Clint Chaplin
Sent: Tuesday, May 17, 2005 6:17 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Capwap] security in objectives draft

"antiquated marketing requirements" are not the only reason for this
position.  Low cost/low power terminals, especially legacy devices,
currently are deployed in the industry, and need WEP support in the
infrastructure.

Laptops are not the only portable/mobile devices to use 802.11, although
it has by far the greatest mindshare withing various standards bodies in
this space.  Small industrial handheld terminals are a viable market.

Besides, whatever protocol CAPWAP settles upon should be completely
agnostic to the security policy being used over the air.

Clint (JOATMON) Chaplin
Wireless Security Advisor
Wireless Standards Manager
>>> Matt Holdrege <[email-masked]> 05/17/05 17:26 PM >>>
At 01:26 PM 5/17/2005, Pat Calhoun wrote:
> > With all due respect to the installed base of WEP-only gear, the 
> > IETF should absolutely not make any exception in this or any other 
> > similar case. The legacy installed base has nothing to do with 
> > future IETF protocols, especially when it weakens security. Just 
> > because the CAPWAP protocol may be used by these legacy AP's, 
> > doesn't mean that they have to be forklift upgraded. What it means 
> > is that they will not fully comply with the security portion of
> > Think if we had rejected IPsec because the massive installed base of

>Matt, while I understand your concerns here, I don't agree that the 
>IETF is in a position to tell AP vendors what security schemes they can

>and cannot support. In fact, as of today, not supporting WTP would mean

>that the vendor would lose their ability for WiFi certification.
>
>
>Pat Calhoun

First of all the IETF tells all vendors of all products what they MUST
and 
MUST NOT support to comply with an RFC. AP vendors are no different from

anyone else and AP vendors already support lots of MUST's in other
RFC's. 
Secondly, I don't think the WiFi Alliance has anything like a normative 
reference to any RFC's right? The WiFi alliance can insert into their 
documents whatever they want and they can say that "even though the IETF

CAPWAP RFC says no to WEP, we will allow it for our certification
tests."

My concern is the integrity of the IETF and RFC's. We shouldn't stoop to

antiquated marketing requirements, especially where security is
concerned.

_______________________________________________
Capwap mailing list
[email-masked] http://mail.frascone.com/mailman/listinfo/capwap

________________________________________________________________________
This email has been scanned for computer viruses.

_______________________________________________
Capwap mailing list
[email-masked] http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Randy Chou" <[email-masked]>
Date: Wed, 18 May 2005 15:36:26 -0700

Resending as I did not see it appear on the list...

So whatever proposal CAPWAP ends up choosing must not have any security
holes, whether wired or wireless.  I would like to make sure we don't
Trivialize the presence of a hole just because it appears to only be
on the wired side.

Regards,
 
--
Randy

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

Clint (JOATMON) Chaplin

---

From: "Darren Loher" <[email-masked]>
Date: Wed, 18 May 2005 16:47:23 -0700

This sounds like we should write a BCP draft following the selection of
a solution for capwap which document the recommended best practices for
configuration and use of the solution.  This BCP should point out the
security holes created by using WEP and lessor encryption techniques on
the WTP <-> STA interface and strongly recommend against usage of those
techniques even though they are permitted.

-Darren

> Behalf Of Randy Chou
> Sent: Wednesday, May 18, 2005 4:36 PM
> To: Clint Chaplin; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: Randy Chou