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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf