Subject: RE: [Capwap] IEEE Review 13 - Protocol security

From: "Darren Loher" <[email-masked]>
Date: Thu, 2 Jun 2005 10:46:30 -0700

Two threats immediately come to mind for rogue AC that must be
addressable are:

Various nan in the middle attacks
 - Rogue AC can configure WTP to disable authentication requirements
between STA and WTP, or change/slave the WTP to the Rogue AC's
authentication proxy, capturing all STA passwords, etc.
 - Rogue AC can configure WTP to tunnel user data through an
intermediate, packet capturing proxy 

However, your points are absolutely valid!  If it is too difficult, it
won't be used.  I'd say those points are a good case for supporting
various authentication methods and asymmetric authentication.  A simple
authentication mechanism could be used for the WTP to authenticate the
AC for initial setup to ensure the initial installation is an automated
operation.  

Zero configuration of the WTP could be supported using a pre-shared key:
- AC and WTP loaded with a standard key from the factory
	- The AC or WTP discover each other using whatever mechanism
      - The WTP could check the shared key for the AC 
- The AC could then configure the WTP to use a stronger mechanism to
authenticate the AC if desired, providing stronger protection of the WTP
against rogue AC's after the initial configuration

This approach does leave new WTP's open to being hijacked at install
time after the value of the pre-shared key gets out.  But after initial
configuration, the mutual authentication could be updated to a new
pre-shared key or public key/certificate if the administrator chooses.
This is still quite valuable as the WTP is only vulnerable at install
time.  In addition, a WTP hijacked at install time would show up as a
rogue WTP if over the air methods are used to detect such WTP's.

-Darren

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Thursday, June 02, 2005 10:50 AM
> To: Darren Loher
> Cc: Saravanan Govindan; [email-masked]
> Subject: Re: [Capwap] IEEE Review 13 - Protocol security 
> 
>   Darren,
> 
>   Yes, I understand that a rogue AC is a realistic 
> possibility, I am not questioning that. But what is the 
> threat that it poses? It has nothing to do with the 45% of 
> the people you mention in an FBI survey.
> 
>   In the Objective draft it describes threats posed by a 
> rogue WTP and then says that mutual authentication is 
> required. Mutual authen- tication is not required to address 
> the threats described. Don't get me wrong. I'm all in favor 
> of mutual authentication but I'd like to know the threat that 
> is being addressed by having the AC authenticate itself to the WTP.
> 
>   There are configuration and management implications to mutual
> authentication-- precludes zero-config drop ship, requires 
> some form of staging, scales less well. (Experience has shown 
> that this added burden is enough to make some in IT so upset 
> that they will actually gut the security of their key 
> management protocol. I speak of the XAUTH hack to IKE). 
> Because of this I think it is imperative that the
> threat(s) requring mutual authentication be spelled out. If 
> they can't then the only alternative is to not make mutual 
> authentication required. 
> 
>   There's a reason why you don't need a personal certificate 
> to purchase things from Amazon. And that is not because the 
> possibility of a "rogue purchaser" is zero. It is because the 
> threat that a "rogue purchaser" poses is not worth the 
> trouble of requiring mutual authen- tication before selecting 
> your purchase. A "rogue company" (a phishing
> expedition) is a possibility and the threats from that are 
> well documented but, like with the current Objectives draft, 
> those threats are not addressed by mutual authentication.
> 
>   Again, I'm not against mutual authentication. I'm just 
> saying that it hasn't been justified and it needs to be 
> because its cost is not trivial.
> 	
>   Dan.
> 
> On Wed, 01 Jun 2005 16:05:01 PDT you wrote
> > If the path between a WTP and a AC contains an untrusted 
> link(s), then 
> > there is a possibility of a Rogue-AC.  If the path between 
> the WTP and 
> > AC contains a wireless link then the likelyhood of a rogue AC seems 
> > just as likely as a Rogue-WTP.
> > 
> > Such a configuration is a reasonable scenario.  Wifi 
> hotspot providers 
> > often operate over an un-trusted network between the AC and the WTP.
> > Often it is desirable for an enterprise to use their shared wired 
> > infrastructure for management between WTP's and AC's.  This shared 
> > network may be trusted for general systems access, but not 
> for network 
> > control.
> > 
> > In many scenarios, having AC - WTP communition on the wired 
> network is 
> > only a minor security advantage.  There's the FBI Computer 
> Crime and 
> > Security survey that listed 45% of respondents saying they have 
> > detected unauthorized access by insiders.  Quotes from the 
> 2003 report 
> > at http://www.crime-research.org/news/01.06.2004/283/
> > 
> > I strongly support mutual authentication as a "MUST" have 
> requirement.
> > 
> > -Darren
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Dan Harkins
> > > Sent: Wednesday, June 01, 2005 9:33 AM
> > > To: Saravanan Govindan
> > > Cc: [email-masked]
> > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security
> > > 
> > >   Saravanan,
> > > 
> > >   I clearly understand the threat posed by a "rogue WTP" 
> but what is 
> > > the threat posed by a "rogue AC"? A CAPWAP-capable WTP is not 
> > > service providing all by its lonesome. It requires an AC to 
> > > provision and control it, and to forward packets for its 
> associated 
> > > STAs. With that in mind the only thing I can see a "rogue 
> AC" doing 
> > > is analagous to physical theft.
> > > It can induce WTPs to be controlled and provisioned by it 
> instead of 
> > > a different, legitimate, AC. It cannot gain access to a wired 
> > > network, only put a WTP's associated STAs on its network 
> (if it has 
> > > one).
> > > 
> > >   If the "rogue AC" is something CAPWAP MUST prevent then 
> I'd like 
> > > to see some text describing the threat to justify it. If 
> the "rogue 
> > > AC"
> > > is not something that CAPWAP MUST prevent (i.e. it SHOULD
> > > prevent) then the requirement for mutual authentication 
> should also 
> > > be a SHOULD.
> > > 
> > >   Dan.
> > > 
> > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote
> > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description)
> > > > 
> > > > Comment:
> > > > 
> > > > Justify mutual authentication requirement
> > > > 
> > > > 
> > > > Existing text:
> > > > 
> > > > The CAPWAP protocol must first provide for the
> > > participating entities
> > > > - WLAN controller and WTPs - to be mutually authenticated.  
> > > This is to
> > > > ensure that rogue WTPs do not breach legitimate WLAN 
> systems.  For 
> > > > example, WTPs may need to regularly renew their
> > > authentication state
> > > > with the WLAN controller.
> > > > 
> > > > 
> > > > Proposed change:
> > > > 
> > > > The following changes include text from Charles Clancy. 
> > > > 
> > > > "The CAPWAP protocol must first provide for the
> > > participating entities
> > > > - WLAN controller and WTPs - to be mutually authenticated.  
> > > This is to
> > > > ensure that rogue elements do not gain access to the 
> WLAN system. 
> > > > Rogue WTPs should not be allowed to breahch legitimate 
> WLANs and 
> > > > at the same time rogue WLAN controllers should not be 
> allowed to 
> > > > gain control of legitimate WTPs. For example, WTPs may need to 
> > > > regularly renew their authentication state with the WLAN 
> > > > controller and similarly for WLAN controllers.
> > > > 
> > > > If authentication is performed via an authenticated key 
> exchange, 
> > > > future knowledge of derived keys is not sufficient for
> > > authentication.
> > > > 
> > > > Any session keys used between the AC and WTP MUST be
> > > mutually drived
> > > > using entropy contributed by both parties.  This ensures
> > > that no one
> > > > party has control over the resulting session keys."
> > > > :
> > > > :
> > > > "CAPWAP should not prevent the use of asymmetric
> > > authentication.  The
> > > > security considerations of such asymmetric authentication are 
> > > > described in the Security Considerations section."
> > > > _______________________________________________
> > > > Capwap mailing list
> > > > [email-masked]
> > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > 
> > > _______________________________________________
> > > 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: Dan Harkins <[email-masked]>
Date: Thu, 02 Jun 2005 11:58:49 -0700

Darren,

  The man-in-the-middle attacks you describe would not work if 802.11i
was used. If it wasn't then these attacks can still be mounted by
configuring a generic cutrate AP, forget CAPWAP. It would not be possible
to capture the STA's passwords because the STA authenticates the AS
prior to devulging her passwords and she would not authenticate a rogue
AS.

  Regarding the idea of loading a standard pre-shared key at the factory
keep in mind that CAPWAP must be interoperable by different vendors so
all vendors would have to use the same pre-shared key. Therefore let me
refer you to the following (unfortunately now expired) Internet Draft:

	http://www.lounge.org/draft-ietf-ipsec-internet-key-00.txt

I recommend reading the entire draft, it's pretty short, but check out the
"Security Considerations" section. Then check out the date. 

  For what it's worth I know of one company that shipped product that
used that for authentication purposes as the "default pre-shared key" so
there is precedense!

  Dan.

On Thu, 02 Jun 2005 10:46:30 PDT you wrote