Subject: Last call comments for capwap-threat-analysis-01

From: <[email-masked]>
Date: Tue, 29 Jul 2008 18:55:31 +0300

Couple of comments/observations about capwap-threat-analysis-01:

There seem to be couple of places where this document isn't
completely in sync with the protocol/binding documents.
In particular, the following two places:

Section 4.2, "The current CAPWAP binding for IEEE 802.11 only
supports the use of IEEE 802.11i [80211I] security on the 
wireless link." The current version of the binding spec seems
to support WEP, too.

Section 6.1: The text about "Local MAC", "Remote MAC", and "Split MAC" 
doesn't seem to match the other documents. E.g., there's no "Remote MAC"
in the other documents, and description of "Local MAC" doesn't quite
match the description in IEEE 802.11 binding.

The document would benefit from some discussion about authorization.
Especially if WTPs/ACs have manufacturer-issued certificates installed
in factory, everyone can easily authenticate everyone else. And with
DHCP AC option, this could "zero configuration" for WTPs -- except
that this wouldn't be secure: WTP (and AC) needs some configuration 
to know who is the *right* AC (who are the *right* WTPs).

Editorial nits:

Section 9.2: the section title includes "Rootkit installation": is
this in right place, or should it be in Section 9.3?

Best regards,
Pasi
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 22:20:28 +0300

Scott G. Kelly wrote:

> Some comments inline below...
> 
> Pasi.Eronen wrote:
> I think Charles already addressed this.

Right; I think we can say that "the binding supports using WEP,
but doing so has so many other security problems we don't bother
discussing WEP in this document" (or something more polite along
those lines :-).

> >Section 6.1: The text about "Local MAC", "Remote MAC", and "Split
> >MAC" doesn't seem to match the other documents. E.g., there's no
> >"Remote MAC" in the other documents, and description of "Local MAC"
> >doesn't quite match the description in IEEE 802.11 binding.
> 
> See RFC4118.

Thanks for the pointer; however, since this document is a threat
analysis for CAPWAP IEEE 802.11 binding, it should be aligned with 
the capwap-protocol-binding-ieee802 document, not RFC 4118.

> >The document would benefit from some discussion about
> >authorization.  Especially if WTPs/ACs have manufacturer-issued
> >certificates installed in factory, everyone can easily authenticate
> >everyone else. And with DHCP AC option, this could "zero
> >configuration" for WTPs -- except that this wouldn't be secure: WTP
> >(and AC) needs some configuration to know who is the *right* AC
> >(who are the *right* WTPs).
> 
> I believe you attended the lunch with Sam where this was
> discussed. We've explicitly deferred certificate-related authn/authz
> discussion for now so that we can get these specs published in a
> meaningful timeframe, although we do discuss validating the EKU bits
> and MAC address for this. This is the classic "camel's nose"
> problem: if you attempt to add text that addresses this more fully,
> where do you stop?
>
> I don't think we want to open this can of worms just now. At 
> Sam's request, we added some cert-related clarifications, but 
> I think we all agreed to stop there.

Trying to *solve* these problems would probably open a can of worms,
but I wasn't proposing that -- just accurately describing what is
solved and what isn't. (That shouldn't be more than couple of
paragraphs.)

Best regards,
Pasi