Subject: [Capwap] IEEE Review 13 - Protocol security

From: "Saravanan Govindan" <[email-masked]>
Date: Wed, 1 Jun 2005 18:22:24 +0800

Section 5.1.8 - CAPWAP Protocol Secuirty (Description)

Comment:

Justify mutual authentication requirement

Existing text:

The CAPWAP protocol must first provide for the participating entities -
WLAN controller and WTPs - to be mutually authenticated.  This is to
ensure that rogue WTPs do not breach legitimate WLAN systems.  For
example, WTPs may need to regularly renew their authentication state
with the WLAN controller.

Proposed change:

The following changes include text from Charles Clancy. 

"The CAPWAP protocol must first provide for the participating entities -
WLAN controller and WTPs - to be mutually authenticated.  This is to
ensure that rogue elements do not gain access to the WLAN system. Rogue
WTPs should not be allowed to breahch legitimate WLANs and at the same
time rogue WLAN controllers should not be allowed to gain control of
legitimate WTPs. For example, WTPs may need to regularly renew their
authentication state with the WLAN controller and similarly for WLAN
controllers.

If authentication is performed via an authenticated key exchange, future
knowledge of derived keys is not sufficient for authentication.

Any session keys used between the AC and WTP MUST be mutually drived
using entropy contributed by both parties.  This ensures that no one
party has control over the resulting session keys."
:
:
"CAPWAP should not prevent the use of asymmetric authentication.  The
security considerations of such asymmetric authentication are described
in the Security Considerations section."
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Dan Harkins <[email-masked]>
Date: Wed, 01 Jun 2005 08:33:05 -0700

Saravanan,

  I clearly understand the threat posed by a "rogue WTP" but what is
the threat posed by a "rogue AC"? A CAPWAP-capable WTP is not service
providing all by its lonesome. It requires an AC to provision and control
it, and to forward packets for its associated STAs. With that in mind
the only thing I can see a "rogue AC" doing is analagous to physical theft.
It can induce WTPs to be controlled and provisioned by it instead of a
different, legitimate, AC. It cannot gain access to a wired network,
only put a WTP's associated STAs on its network (if it has one).

  If the "rogue AC" is something CAPWAP MUST prevent then I'd like to
see some text describing the threat to justify it. If the "rogue AC"
is not something that CAPWAP MUST prevent (i.e. it SHOULD prevent) then
the requirement for mutual authentication should also be a SHOULD.

  Dan.

On Wed, 01 Jun 2005 18:22:24 +0800 you wrote

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 2 Jun 2005 05:59:21 -0700

Please see my comments below, otherwise I'm ok with the new text.

> Existing text:
> 
> The CAPWAP protocol must first provide for the participating 
> entities - WLAN controller and WTPs - to be mutually 
> authenticated.  This is to ensure that rogue WTPs do not 
> breach legitimate WLAN systems.  For example, WTPs may need 
> to regularly renew their authentication state with the WLAN 
> controller.
> 
> 
> Proposed change:
> 
> "The CAPWAP protocol must first provide for the participating 
<PRC> s/must/MUST/

> entities - WLAN controller and WTPs - to be mutually 
<PRC> Charles' text stated "... to be explicitly mutually ..."
                                      ^^^^^^^^^^
> authenticated.  This is to ensure that rogue elements do not 
> gain access to the WLAN system. Rogue WTPs should not be 
> allowed to breahch legitimate WLANs and at the same time 
<PRC> Typo at breach
> rogue WLAN controllers should not be allowed to gain control 
> of legitimate WTPs. For example, WTPs may need to regularly 
> renew their authentication state with the WLAN controller and 
> similarly for WLAN controllers.
> 
> If authentication is performed via an authenticated key 
> exchange, future knowledge of derived keys is not sufficient 
> for authentication.
> 
> Any session keys used between the AC and WTP MUST be mutually 
> drived using entropy contributed by both parties.  This 
<PRC> s/drived/derived/
> ensures that no one party has control over the resulting 
> session keys."
> :
> :
> "CAPWAP should not prevent the use of asymmetric 
<PRC> s/should not/MUST NOT/
> authentication.  The security considerations of such 
> asymmetric authentication are described in the Security 
> Considerations section."

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap