Subject: RE: [Capwap] About LWAPP's security

From: Michael Cheng <[email-masked]>
Date: Wed, 14 Apr 2004 11:09:14 +0100

Hi Scott,

Thank you very much for your quick response. Sorry to reply late. I was
off for a few days.

We wrote the paper purely for our own research interest and  did not
plan to attack one particular design. We noticed the problem last June(
maybe you still can find my email in  the group) and wrote the paper under a
request for academic reason last December. Because we believed that the
lwapp team would release new version after the old draft expired, we didn't
post the paper. However, it seems that the LWAPP team becomes inactive after
establishing CAPWAP or am I wrong?
We think we should post the paper purely for academic reason.

Only a few comments on your response.
Moreover, I updated the paper with some minor corrections.

Scott G. Kelly wrote:

> Hi Michael,
>
> Michael Cheng wrote:
>
> > Hi,
> >
> > We wrote a paper to briefly analyze the security aspect of LWAPP.
> > If anyone is still interested in LWAPP, the paper is avaible
> > on http://www.cs.mdx.ac.uk/staffpages/m_cheng/link/lwapp_g.pdf
>
> Thanks for posting this paper. After giving it a quick review, I have a
few comments. I'd like to preface this by saying that this is not currently
a working group item, and so this discussion is purely academic, and it may
be terminatated by the wg chairs at any time. Nonetheless, I think it should
hold some interest for wg members, and the paper deserves some response.
>
> In order to properly analyze the security properties of the protocol
discussed in the draft, you must understand the assumptions under which the
protocol operates. These were described in an internal document here, but
not in detail in the lwapp draft, so you are at a disadvantage in that
regard.
>
> One primary architectural assumption in the original lwapp security design
was that the AP's have a direct layer 2 connection to the AR, which in our
case is a switch. It is also assumed that this connection is relatively
protected with regard to physical security (e.g. runs through the ceiling of
your office building to your lockable server room). That is, the security
protocol discussed in the draft was not designed to operate over a hostile
network. I believe this was made clear in subsequent discussions on this
list. 

I totally agree with you that when designing a security protocol we
should consider the protocol application environment and evaluate the
potentional threats.

However, I believe all of us agree with that we can not just design a
protocol to cope with the threats we found.

A general way to design a protocol is
first to analyze the available cryptography primitives( enc: AES, RSA,
ECC, ..., hash: ..., sometimes patents are concerned)

second to decide the acceptable protocol complexity (computation,
bandwith, implementation)

third to decide the general protocol type (symmetric or aymmetric-based,
password-based, key agreement or  key transport, AK or AKC)

four to design a protocol (or some) as rigerous as possible (formally
provable with some general properties: known-key attack, key-comprise
impersonation...)

fifth to evaluate the protocol's ability to counter the potential threats.
(Some attacks in networks can not be defended by only designing a
generally good protocol.
Some protocol security properties are undesireable in the application
environment.)

sixth to make a choice based on the balance between complexity and security.

Of cz sometime we also should consider whether the parameter negotiation
is necessary.

I believe a rigerous protocol with tolerable complexity is NEVER a bad
choice.

For example protocol 3 in our paper,  to provide explicit key-confirmation,
AR only needs to perform one more hash operation.
Maybe one will argue that the opening  key attack is  not feasible in LWAPP.
However when we tell customers that there is a bug, but the attack is
extremely unlikely, customers maybe will not be convinced.
On the other hand,  why not  use a small cost to remove the potential
bug with an explicity key confirmation?

Moreover, we cannot forcast the future. If we can design a protocol with
acceptable complexity which is secure in the hotile environment, why don't
we  do it ?

>
> In our internal analysis we concluded, as do you, that there is no
significant security benefit inherent in encrypting the wep keys, since
anyone who can see the encrypted lwapp channel can see the unencrypted data
traffic. But try telling a customer that you're sending encryption keys over
the network in the clear, but that they shouldn't worry about this. Also, in
the case where an attacker can't insert himself as a MiM, there is a small
security benefit: in these cases he can only eavesdrop; he cannot modify the
traffic flow, whereas with compromised wep keys he could inject traffic. But
this is an admittedly small benefit.
>
> There is some additional benefit in the encrypted/authenticated command
channel: the AP control API is protected (including firmware downloads).
This prevents the introduction of hostile firmware and/or configuration into
the AP which might be used as building blocks in an attack.
>
> After related discussions on this list and the subsequent publication of
the lwapp security requirements draft (expired, but still available at
http://www.legra.com/downloads/IETF_Internet_Draft_LWAPP_Security.pdf ), it
should be clear that the mechanism discussed in the original lwapp draft was
quite limited, and is not viewed as sufficient solution for generalized
lwapp security.
>
> Regarding various discussions about the authentication mechanism, you guys
are mistaken in some of your assumptions. Both sides are supposed to be
authenticated (not just the AR), and clearly you want to look at the IDs in
the certs as part of the verification. We did not publish that level of
detail in the 00 draft, but this does not mean it has not been considered.

That is great. However we didnot see any new publication in the last few
months. Is LWAPP still alive?
I  can't quite understand why LWAPP runs out of steam. or am I wrong? (
I did not follow the progress tightly.)

In fact, ID and validality of certifications are problems out of the
scope of designing secure protocols. Two problems are faced by any
certification-based protocol. However, these two problems are particularly
important in LWAPP-like  protocols and should be addressed in the proposal
if certification-based protocol is used.
Password-based protocol has no such problem because AR's ID and password
must be preconfigured in AP.

For certification revocation, commonly there are two solutions.
A: after establishing the channel, AP checks the CRL. (for example
EAP-TLS uses this method)
B: AR relays the request and response. (We proposed this way)
Both methods have advantages and disadvantages.

About ID, I agree with that this is more likely about implementation and
deployment.

>
> Verifying IDs implies some preconfiguration during the initial staging,
but this should come as no surprise to someone experienced at deploying this
sort of gear. Discussion of these points was beyond the scope of the draft,
and I'm sure these issues will be addressed if this wg moves forward with an
lwapp-like protocol.
> Scott
Michael

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