Scott G. Kelly wrote:
Some comments inline below...
Pasi.Eronen wrote:
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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf