Subject: [Capwap] security in objectives draft

From: Charles Clancy <[email-masked]>
Date: Mon, 16 May 2005 10:47:03 -0400 (EDT)

The chairs have asked me to put together some text for the objectives 
draft that more generally addresses the security issues from the recent 
LWAPP security review.  Before proceeding, I'd like to get some feedback 
from the working group on the high-level ideas.  I think some of them may 
be overly specific or restrictive.

1. CAPWAP Protocol Security (section 5.1.8)

1a. Strengthen the mutual authentication requirement to require explicit 
mutual authentication that verifies proper key derivation (many would 
claim this is the definition of mutual authentication, but ambiguity is 
never good).

1b. I'm curious about the following statement: "While mutual 
authentication is necessary for CAPWAP, the protocol should not prevent 
the use of asymmetric, non-mutual authentication."  Can anyone tell me 
what "asymmetric" and "non-mutual" have to do with each other?  I agree 
that asymmetric methods should be supported, but not non-mutual methods.

1c. Add requirements to key derivation such that session keys and IVs must 
be mutually derived.

1d. Require that certificates in public-key authentication schemes are 
both authenticated AND authorized.

2. System-wide Security (section 5.1.9)

2a. This section addresses PMK sharing, but this only seems applicable to 
a local MAC scenario.  When split MAC is being used, PTK sharing is the 
bigger concern.  IMHO, the following should be required: in a split-MAC 
environment, an 802.11 4-way handshake should be required; in a local-MAC 
setup, an EAP reauthentication (possibly a fast reauthentication, TLS 
resume, etc) should be required.  Is this too specific and inflexible for 
protocol designers and implementers?  At a minimum, we should add PTK 
sharing to the threat list, and require handoffs to be authenticated in 
some way.

2b. I think use of WEP should be disallowed, but I understand that vendors 
often have to support legacy devices.  Should we suggest that drafts have 
disclaimers normatively recommending that WEP not be used?

Thanks!

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "James Kempf" <[email-masked]>
Date: Mon, 16 May 2005 09:10:17 -0700

Charles,

Comments.

> claim this is the definition of mutual authentication, but ambiguity is

Yes.

> that asymmetric methods should be supported, but not non-mutual methods.

Asymmetric w.r.t. cryptographic protocols (i.e. public key) is fine.
Non-mutual is not. I believe mutual authentication should be required.

> 1c. Add requirements to key derivation such that session keys and IVs must

Yes.

> both authenticated AND authorized.

This would require a certificate profile with attributes added to the
identity certificate for authorization, right? This might be too
restrictive. We originally required this (MUST) in SEND but had to back off
because of deployment considerations. So now it's a SHOULD.

An alternative might be attribute certificates, but that also has a
deployment concern.

> sharing to the threat list, and require handoffs to be authenticated in

I'm not so sure this is an issue. Following the concept of a "cryptographic
boundary", the split mac moves the cryptographic boundary for the keys to
the AC, and a handover on the AC doesn't result in the keys being
transferred outside. If that is so, why do you feel that reusing the PTK on
handover is a problem? The issue here is that any additional signaling on
handover is going to cut deeply into VoIP performance.

I do agree with your recommendation on local mac, however.

> disclaimers normatively recommending that WEP not be used?

Perhaps a SHOULD rather than a MUST?

            jak

---

From: Charles Clancy <[email-masked]>
Date: Mon, 16 May 2005 13:06:11 -0400 (EDT)

> restrictive. We originally required this (MUST) in SEND but had to back 
> off because of deployment considerations. So now it's a SHOULD.
>

You could also define a new KeyPurposeID much like RFC 3770 did for EAP. 
While it would still leave options for attack (for example, a compromised 
AC cert from one network being used on another that uses the same CA), 
IMHO that would be the simplest and least restrictive.

> handover is going to cut deeply into VoIP performance.

In the split-MAC model where the PTK is pushed to WTPs through which a STA 
roams, if one WTP is compromised then it can essentially request the PTK 
for any authenticated client in the network.  Using that the rogue WTP can 
decrypt all the STA's wireless traffic, among other things.  If the PTK is 
renegotiated on handoff, then the affects of a rogue WTP are contained, as 
it doesn't know the PMK.  As I see it, the only way to do this rekey 
without making changes to the STA is to do another 4-way handshake.

>> 2b. I think use of WEP should be disallowed, but I understand that 
>> vendors often have to support legacy devices.  Should we suggest that 
>> drafts have disclaimers normatively recommending that WEP not be used?
>

Drafts MUST say SHOULD, or SHOULD say SHOULD?

---

From: "James Kempf" <[email-masked]>
Date: Mon, 16 May 2005 11:06:46 -0700

> IMHO that would be the simplest and least restrictive.

This looks promising. Any idea how widely KeyPurposeID is deployed?

> without making changes to the STA is to do another 4-way handshake.

OK. Isn't 802.11r working on this problem?

> Drafts MUST say SHOULD, or SHOULD say SHOULD?

I think the draft should say SHOULD.

            jak

---

From: Charles Clancy <[email-masked]>
Date: Mon, 16 May 2005 14:52:11 -0400 (EDT)

>> You could also define a new KeyPurposeID much like RFC 3770 did for 
>> EAP. While it would still leave options for attack (for example, a 
>> compromised AC cert from one network being used on another that uses 
>> the same CA), IMHO that would be the simplest and least restrictive.
>

KeyPurposeID is the data type for elements of the X509v3 extended key 
usage.  I suspect you'd see it in almost all certificates these days. 
OpenSSL has support for the simple ones (i.e. "TLS Web Server 
Authentication", etc).  I have no idea what fraction of applications 
actually pay attention to them, though.

>> In the split-MAC model where the PTK is pushed to WTPs through which a 
>> STA roams, if one WTP is compromised then it can essentially request 
>> the PTK for any authenticated client in the network.  Using that the 
>> rogue WTP can decrypt all the STA's wireless traffic, among other 
>> things.  If the PTK is renegotiated on handoff, then the affects of a 
>> rogue WTP are contained, as it doesn't know the PMK.  As I see it, the 
>> only way to do this rekey without making changes to the STA is to do 
>> another 4-way handshake.
>

I'm not familiar with all the TGr proposals, but from what I understand 
they all still rely on the 4-way handshake to turn the PMK into a PTK. 
They look at ways to handle the discovery and preemptive PMK keying so a 
full EAP reauthentication doesn't have to happen.  Since the split-MAC 
model inherently handles the handoff process (unless of course you're 
roaming between ACs), I think the TGr work would only apply to the 
local-MAC model.

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 17 May 2005 00:29:43 -0700

> In the split-MAC model where the PTK is pushed to WTPs 
> through which a STA roams, if one WTP is compromised then it 
> can essentially request the PTK for any authenticated client 
> in the network.  Using that the rogue WTP can decrypt all the 
> STA's wireless traffic, among other things.  If the PTK is 
> renegotiated on handoff, then the affects of a rogue WTP are 
> contained, as it doesn't know the PMK.  As I see it, the only 
> way to do this rekey without making changes to the STA is to 
> do another 4-way handshake.

Actually, I don't believe this is the way CAPWAP protocols work (well,
not LWAPP anyhow), and if any of them do, then wouldn't interoperate
with any 802.11 station/supplicant that I am aware of. When a client
moves, even if it had a cached PMK, it would still have to undergo
the full 4-way key handshake, which requires proof of the PMK in
order to be successful.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 17 May 2005 00:47:11 -0700

> I'm not familiar with all the TGr proposals, but from what I 
> understand they all still rely on the 4-way handshake to turn 
> the PMK into a PTK. 
> They look at ways to handle the discovery and preemptive PMK 
> keying so a full EAP reauthentication doesn't have to happen. 
>  Since the split-MAC model inherently handles the handoff 
> process (unless of course you're roaming between ACs), I 
> think the TGr work would only apply to the local-MAC model.

TGr is actually valid for any architecture. The goal is to 
minimize the latency associated with a handoff, by optimizing
some of the rekeying process, as well as having some form of a
guarantee that the target AP has the QoS resources to handle the
station. 

Whether a product uses an autonomous or centralized approach, the
station can/will not know, and therefore must treat all APs
the same. However, I do agree that implementing TGr is simpler for
centralized approaches.

Pat Calhoun

---

From: "T. Charles Clancy" <[email-masked]>
Date: Tue, 17 May 2005 07:56:08 -0400 (EDT)

> the full 4-way key handshake, which requires proof of the PMK in

You're right -- 11i requires a 4-way handshake after association, so the 
PTK thing isn't an issue.  However, I'd wager that there's a supplicant 
out there that would do it.  For one, most accept pushed keys using the 
EAPOL RC4 key descriptor for use with dynamically-keyed WEP.  They may 
only update their keys upon termination of an EAPOL keying exchange.  I'm 
not sure what the 802.11/802.1X standards have to say about it, but I 
wonder what would happen if an reassociate request was not followed by an 
EAP-Request/Identity but rather an EAP-Success.

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 17 May 2005 02:31:58 -0700

>disclaimers normatively recommending that WEP not be used?

With all due respect to the installed base of WEP-only gear, the IETF 
should absolutely not make any exception in this or any other similar case. 
The legacy installed base has nothing to do with future IETF protocols, 
especially when it weakens security. Just because the CAPWAP protocol may 
be used by these legacy AP's, doesn't mean that they have to be forklift 
upgraded. What it means is that they will not fully comply with the 
security portion of the specification. Anyone doing a security audit of 
such a network would reject any WEP-only gear in any case.

Think if we had rejected IPsec because the massive installed base of 
Windows 3.1 intel-386 PC's couldn't comply with it.

-Matt

---

From: "T. Charles Clancy" <[email-masked]>
Date: Tue, 17 May 2005 10:47:57 -0400 (EDT)

> the same. However, I do agree that implementing TGr is simpler for

Oh, sorry, I was only refering to the keying optimizations.  There are 
plenty of non-keying approaches to speed up handoffs.  I'm skeptical that 
the keying approaches will help the split-MAC environment, unless they are 
aware of CAPWAP-like deployments, where a PMK is logically shared between 
multiple BSSes.

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 17 May 2005 13:26:25 -0700

> With all due respect to the installed base of WEP-only gear, 
> the IETF should absolutely not make any exception in this or 
> any other similar case. 
> The legacy installed base has nothing to do with future IETF 
> protocols, especially when it weakens security. Just because 
> the CAPWAP protocol may be used by these legacy AP's, doesn't 
> mean that they have to be forklift upgraded. What it means is 
> that they will not fully comply with the security portion of 
> the specification. Anyone doing a security audit of such a 
> network would reject any WEP-only gear in any case.
> 
> Think if we had rejected IPsec because the massive installed 
> base of Windows 3.1 intel-386 PC's couldn't comply with it.
Matt, while I understand your concerns here, I don't agree that 
the IETF is in a position to tell AP vendors what security schemes
they can and cannot support. In fact, as of today, not supporting
WTP would mean that the vendor would lose their ability for 
WiFi certification. 

Pat Calhoun

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 17 May 2005 17:23:58 -0700

>CTO, Wireless Networking Business Unit

First of all the IETF tells all vendors of all products what they MUST and 
MUST NOT support to comply with an RFC. AP vendors are no different from 
anyone else and AP vendors already support lots of MUST's in other RFC's. 
Secondly, I don't think the WiFi Alliance has anything like a normative 
reference to any RFC's right? The WiFi alliance can insert into their 
documents whatever they want and they can say that "even though the IETF 
CAPWAP RFC says no to WEP, we will allow it for our certification tests."

My concern is the integrity of the IETF and RFC's. We shouldn't stoop to 
antiquated marketing requirements, especially where security is concerned.

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 17 May 2005 17:32:13 -0700

> First of all the IETF tells all vendors of all products what 
> they MUST and MUST NOT support to comply with an RFC. AP 
> vendors are no different from anyone else and AP vendors 
> already support lots of MUST's in other RFC's. 
> Secondly, I don't think the WiFi Alliance has anything like a 
> normative reference to any RFC's right? The WiFi alliance can 
> insert into their documents whatever they want and they can 
> say that "even though the IETF CAPWAP RFC says no to WEP, we 
> will allow it for our certification tests."

Please don't misunderstand my position. I'm in no way supportive
of folks running WEP in their networks, but the reality is that
802.11 vendors cannot adhere to an RFC that causes them to be out
of compliance with WFA. Furthermore, there are hundreds of thousands
of devices of there (e.g., legacy scanners) that cannot be upgraded,
and it is possible that customers running these networks are less
concerned about the security of that data - while wanting to provide
higher security SSIDs for other applications - which is a requirement
defined in the objectives document, may I add.

Pat Calhoun

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Matt Holdrege
> Sent: Tuesday, May 17, 2005 5:24 PM
> To: Pat Calhoun; 'Charles Clancy'; [email-masked]
> Subject: RE: [Capwap] security in objectives draft
> 
> > > With all due respect to the installed base of WEP-only gear, the 
> > > IETF should absolutely not make any exception in this or 
> any other 
> > > similar case.
> > > protocols, especially when it weakens security. Just because the 
> > > CAPWAP protocol may be used by these legacy AP's, doesn't 
> mean that 
> > > they have to be forklift upgraded. What it means is that 
> they will 
> > > not fully comply with the security portion of the specification. 
> > > Anyone doing a security audit of such a network would reject any 
> > > WEP-only gear in any case.
> > >
> >Matt, while I understand your concerns here, I don't agree that the 
> >IETF is in a position to tell AP vendors what security 
> schemes they can 
> >and cannot support. In fact, as of today, not supporting WTP 
> would mean 
> >that the vendor would lose their ability for WiFi certification.
> >
> >
> >Pat Calhoun
> My concern is the integrity of the IETF and RFC's. We 
> shouldn't stoop to antiquated marketing requirements, 
> especially where security is concerned.
> 
>