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

From: "Darren Loher" <[email-masked]>
Date: Wed, 1 Jun 2005 16:05:01 -0700

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 09:50:21 -0700

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

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 02 Jun 2005 10:08:44 -0700

Also remember that an AC is a *function* and not necessarily an isolated 
piece of hardware. That function may operate anywhere in a network. It may 
operate on a laptop PC owned and operated by a hacker. So unless I'm 
missing something (quite possible!), I don't see how you can avoid a 
requirement for mutual authentication.

I understand the burden placed on rolling out cheap AP's which must support 
this, but hey, security always costs you something. And the end user can 
choose to turn it off as they often do.

-Matt

---

From: Charles Clancy <[email-masked]>
Date: Thu, 2 Jun 2005 13:20:09 -0400 (EDT)

I don't agree that mutual authentication is any more difficult than 
one-way authentication from a deployment perspective.  To keep it simple, 
let's look at two basic authentication schemes -- preshared key and public 
key.

In a preshared-key approach, both the WTP and AC need to know some static 
key.  Mutual authentication can be accomplished by virtue of both parties 
knowing the key.  Initial configuration of the WTP involves loading the 
key onto the client in some way -- this would have to be done even if the 
protocol did WTP->AC authentication only.  Thus mutual authentication has 
no effect on deployments -- just two round-trips instead of one during the 
authentication phase.

Now, in a public-key approach, you have to preload the WTP's key pair onto 
the device in order to perform one-way WTP->AC authentication.  During 
this loading process, is it any more difficult to load some CA certificate 
as well?  This CA certificate can verify a certification path for the AC 
certificate presented during authentication.

IMHO, mutual authentication MUST be a MUST.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

On Thu, 2 Jun 2005, Matt Holdrege wrote:

> operate on a laptop PC owned and operated by a hacker. So unless I'm missing 
> something (quite possible!), I don't see how you can avoid a requirement for 
> mutual authentication.
>

---

From: Dan Harkins <[email-masked]>
Date: Thu, 02 Jun 2005 10:48:07 -0700

Matt,

  I notice, further down in my inbox, that Saravanan sent out some 
additional text that sort of justifies it. But let me respond to
you.

  OK, let's say that I'm a hacker, that my laptop implements the AC
side of CAPWAP and I induse a WTP to become controlled and provisioned
by me instead of the enterprise's AC which should be controlling and
provisioning it. So now what can I do and what can I not do with that
WTP? (Substitute "starbucks" for "enterprise" below if that's your cup
of chai).

  - I can configure it so it can look like the legitimate enterprise's
    WTP. But, assuming 802.11i is used, a client will not successfully
    authenticate to the WTP. If you're not using 802.11i then this is
    just the same as going down to Fry's and buying a cutrate AP and
    configuring it to beacon out the enterprise's legitimate SSID and
    associated IEs. Nothing really new here and nothing that is
    necessarily solved by requiring mutual authentication in CAPWAP.

  - I cannot gain access to the enterprise's network.

  - I can configure it so that it will become part of my network. This
    is analagous to theft. I've just stolen the enterprise's property
    because I provisioned it to be part of my network. This is the
    threat that I brought up in my original post in this thread. I
    could redirect people to my services instead of the services of
    the legitimate enterprise. And I can expand my network without
    having to purchase the hardware that one normally would need
    to purchase.

Yes, it's possible that a rogue AC can exist. It is important, though,
to look at the threat it poses and why it is or is not worthwhile
to address it. Saravanan has new text that mentions the last threat
that I listed. That's great! Now we know why we need mutual authentication
because the previous version of the Objectives draft didn't have that.

  Dan.

On Thu, 02 Jun 2005 10:08:44 PDT you wrote

---

From: Dan Harkins <[email-masked]>
Date: Thu, 02 Jun 2005 11:19:24 -0700

Charles,

On Thu, 02 Jun 2005 13:20:09 EDT you wrote
> no effect on deployments -- just two round-trips instead of one during the 

That requires staging and precludes a zero-config drop ship.

> certificate presented during authentication.

Whose CA certificate? Either it's the customer's which requires staging
and has the same problems as pre-shared key, or it's the manufacturer's
and then what sort of mutual authentication are you talking about?

We don't want authentication that verifies the vendor of a WTP, we 
want authentication that verifies that it is the WTP we want to control
and provision. That is, having a certificate in a WTP that say is signed
by the vendor-- the Foobar AP company's CA-- is not interesting to an
enterprise. So what? Is it the WTP that I purchased from the Foobar AP
Company or is it the one that hacker purchased from the Foobar AP Company?
An enterprise wants to put it's own certificate in the WTP. That, again,
requires staging.

Whether it's "difficult" to stage hundreds of WTPs or not is not my
point. The point is that it is much more difficult than staging zero WTPs.

Again, experience shows that people that buy these products we develop
will go to extreme lengths-- even to gutting the security of the key
exchange protocol-- to not have to put unique credentials on all products
they deploy. If we're going to require that step than we MUST explain
why it is necessary.

> IMHO, mutual authentication MUST be a MUST.

IMHO, justification for requirements MUST be a MUST.

  Dan.

---

From: Charles Clancy <[email-masked]>
Date: Thu, 2 Jun 2005 15:03:47 -0400 (EDT)

> point. The point is that it is much more difficult than staging zero 

My point was that ANY cryptographically-secure one-way authentication will 
require staging, since you'll have to load some sort of long-term 
credential onto the client.  Zero-config drop ships just aren't an option. 
So, if we're going to require WTP->AC authentication, there's not reason 
not to require mutual authentication.

There are bootstrapping schemes that could securely provision keys to WTPs 
using, for example, a 4-digit numeric PIN.  These schemes require less 
staging, but "less" is still more than "none".

---

From: Dan Harkins <[email-masked]>
Date: Thu, 02 Jun 2005 13:36:21 -0700

Charles,

  I think you're misunderstanding me. I'm not saying that a secure
connection is arrived out of nothing. The zero config I'm talking about
is zero config of the WTP. Something must be done on the AC to cause
it to trust the WTP's credential (which could be loaded at manufacture
time). That scales much better than having to do something on the AC
to cause it to trust the WTP's credential AND do something on the WTP
to cause it to trust the AC's credential. That last step can be really
really time consuming. Especially if it requires opening up a box,
connecting the WTP to a power injector, connecting something to the
WTP's console, doing the "monkey work" command, unplugging, putting
it back in its case, readdressing it to the place where it ultimately
will have to be installed (by someone whose technical expertise involves
a ladder and a screwdriver), and sticking it on the loading dock to await
FedEx. Do that for 100 WTPs. Or 500 WTPs. Or.... See my point? A zero
config drop ship of the WTP would be much more appealing especially if
the whole reason to require mutual authentication did not apply to the
customer's deployment.

  But we've already agreed that there is a (small) reason to require
the WTP to authenticate the AC and that is something analagous to
physical theft and to theft of services provided through a WTP in
some hotspot situation-- send the other company's customers to my expensive
service instead of their less expensive service, "I thought this coffeehouse
had a roaming agreement with the Blah Company, shoot, guess I'll have to
pay the $5.95 cause I really need to check email but I'm not coming back
here again". Obviously that is not the concern of all people who deploy
WLANs so as long as we still require support for asymmetric authentication
techniques which can be used with zero config drop ship all is well. (Note
that the requirement is for supporting them, not using them).

  Dan.

On Thu, 02 Jun 2005 15:03:47 EDT you wrote

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 02 Jun 2005 18:46:59 -0700

Can I ask a silly question? Why can't the vendors of WTP's include the 
ability to input a shared key? The default could be no mutual 
authentication. And if people want security, they can input a key. Let the 
AC vendor also give their customers the choice of accepting trusted or 
un-trusted WTP's.

Remember that we are developing a *protocol* here, rather than a set of 
products. So the CAPWAP protocol MUST support mutual authentication. We are 
not saying products MUST support this and we are absolutely not saying that 
end users MUST use mutual auth.

-Matt

---

From: Charles Clancy <[email-masked]>
Date: Fri, 3 Jun 2005 11:41:56 -0400 (EDT)

Another option might be SSH-style security.  The WTP could be preprogramed 
with a self-signed cert.  The public key could be saved on the AC. 
During the first authentication, the WTP saves the AC's public key. 
During later authentications, the WTP just verifies the AC's public key 
matches the saved one.

Maybe we could allow non-mutual authentication during a provisioning 
phase, but require it afterwards?  Matt brings up a good point -- do we 
want these mutual authentication requirements to be supported by the 
protocol, or required by the protocol?

On Thu, 2 Jun 2005, Matt Holdrege wrote:

> ability to input a shared key? The default could be no mutual authentication. 
> And if people want security, they can input a key. Let the AC vendor also 
> give their customers the choice of accepting trusted or un-trusted WTP's.
>

---

From: Dan Harkins <[email-masked]>
Date: Fri, 03 Jun 2005 10:08:49 -0700

Charles,

On Fri, 03 Jun 2005 11:41:56 EDT you wrote
> During later authentications, the WTP just verifies the AC's public key 

Exactly! Except you don't even need a self-signed cert, just a keypair
installed on the WTP at manufacture time. And you don't need to save the
public key on the AC, just a fingerprint of it, SSH-style.

Then you can do a TLS-style (or DTLS, see SLAPP) asymmetric authentication
to secure the link.

> protocol, or required by the protocol?

There's a difference between required to implement and required to use.

What I'm getting at is that we don't (can't) have a key exchange protocol
that can only support mutual authentication. IKE is that way. There's
many, too many, flavors of authentication but they're all mutual. But
that's because mutual authentication is needed for IPsec. It is not
needed for CAPWAP so we shouldn't have a protocol that only supports
mutual authentication. 

  Dan.