Capwap Mailing List: [Fwd: Secdir review of draft-ietf-capwap-threat-analysis-00]

[Scott G Kelly (scott]

Here's Joe Salowey's review of the capwap security draft (thanks, Joe!).
Charles and I have yet to connect and discuss the comments. Once we
have, we'll respond.


> --- Begin Message ---
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
> (Note that since I don't believe this document has gone to the IESG yet
> I am sending my comments to the working group list instead of the IESG
> list)
>
>
> In general the document is well presented and does a good job of
> presenting a threat analysis of CAPWAP.   I have a few comments:
>
> Title: how specific is this document to 802.11?  It seems that most of
> the detailed analysis applies to CAPWAP using any technology.  Should
> the document be specific to 802.11?
>
>
> The document needs a security considerations section and an IANA
> consideration section as part of the ID-Checklist
>
> Section 2 
>
> - I think this section could more clearly describe the complexity
> involved.  Instead of saying "In the ideal case, the simple act of
> splitting AP functions between the WTP and AC introduces no new security
> considerations beyond those relating to the added complexity of the
> split" which doesn't mean much to me,  It might be better to say
> something like:
>
> "CAPWAP splits the AP functions between the WTP and AC and therefore
> introduces security considerations associated with these components and
> the newly introduced management and control channel interfaces. In
> actuality the considerations depend on the security properties of the L3
> network between the AC and WTP." 
>
> - It is not clear to me from this section whether effects on AAA
> security and over the air security are in scope or out of scope from
> this section.  The document does point out some impact in both these
> areas so I'm not sure they should be declared completely out of scope.
> Suggestion is to better define what the goals of the document are with
> respect to interactions with 802.11 and AAA.  
>
> Perhaps say something like "Over-the-are security and AAA security are
> discussed in section 3, but threat analysis of the CAPWAP protocol
> itself makes up the bulk of the rest of the document"  
>
> Section 3.2
>
> It seems that most of the security considerations directly associated
> with the 802.11 binding are in the 802.11 binding document.  Since there
> are bound to be binding specific considerations with any binding perhaps
> this document should recommend that a bindings document cover specific
> threats associated with a particular binding in the specific binding
> document.  This might be good topic for the security considerations of
> this document. 
>
> Section 3.4
>
> - I'm not sure channel bindings is the best term for this section.
> There are multiple similar definitions for channel bindings and it gets
> confusing.  Basically, channel bindings are a way to bind particular
> parameters to a cryptographic channel,  since we are taking about
> multiple channels I'm not sure this is the best term.  The section is
> more about managing and verifying a series of trust relationships; it is
> possible that channel bindings can be used as a technique in some of the
> verification of trust.  
>
> It would probably be good to point out that the complexity of managing a
> chain of trust relationships already exist in systems without CAPWAP
> architecture.  Does the CAPWAP split introduce new problems in this area
> that are beyond the scope of the current STA - AP - AAA architecture?  
>
> Section 4
>
> I am wondering if the authors considered a slightly different structure
> for the document:
>
> - Deployment scenarios
> - Adversary Goals
> - Adversary capabilities
> - vulnerabilities
> - countermeasures
>
> This moves the adversary goals section to earlier in the document.  This
> seems to make more sense to me.
>
> Section 5
>
> Do we really need to differentiate between 5.2.3.4 (telecommuter) and
> 5.2.3.5 (tactical)? These seem to be very similar, do they point out
> differences in the rest of the threat analysis? 
>
> Section 6 
>
> Section 6.1
>
> An adversary may also be able to delay the delivery of a packet, this
> may not be significant in the environments you are targeting. 
>
> Section 7.1.1
>
> Is there a resource consumption vulnerability (leading to DOS)
> associated with the discovery phase?  For example does the discovery
> phase require maintaining state? 
>
> Section 7.1.2 
>
> It seems that there could be an impersonation aspect to the misdirection
> where an attacker could cause the WTP to associate with a different
> (perhaps malicious) AC than it intended and vice versa? 
>
> Section 8.2 
>
> A goal of WTP impersonation could be to DoS the system (wired or
> wireless).
>
> Section 8.3
>
> - with regard "to intercept user mobility context (possibly including
> security-sensitive information such as cryptographic keys)" , where  is
> the context communicated to and from?
>
> - Is CAPWAP involved in inter AC trust? 
>
>
> --- End Message ---