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

From: Scott G Kelly <[email-masked]>
Date: Tue, 21 Aug 2007 07:28:10 -0700

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.

Subject: Secdir review of draft-ietf-capwap-threat-analysis-00
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
To: "Charles Clancy" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 19 Aug 2007 21:24:28 -0700

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? 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap