Subject: Re: [Capwap] BSSID-WLAN mappings

From: Jim Murphy <[email-masked]>
Date: Mon, 01 May 2006 12:03:42 -0700

Hi,

Hasn't security already been compromised in CAPWAP by the fact that
a data frame could be sent to multiple WLANs using the WLAN/Status field
of the CAPWAP header? Each of these WLANs could be running a different
crypto type.

Thanks,

Jim

Bob O'Hara (boohara) wrote:
> As I said, this is a proprietary extension, even if it might have been 
> provided on some Cisco products.  I hold that CAPWAP is chartered to 
> implement a protocol to support 802.11, not the myriad proprietary 
> extension that have been hammered onto its side over the years.
>  
> But, the more damning problem for this is the lowering of security and 
> the violation of the security assumptions on which 802.11i is based.  
> Crossing the boundary of a security domain, even if "only" for 
> multicast, dramatically increases the opportunity for compromise of data 
> that communicants believe is secure.
>  
> 
>  -Bob
>  
> 
>  
> 
> ------------------------------------------------------------------------
> *From:* Jeff Joslin [mailto:[email-masked]]
> *Sent:* Friday, April 28, 2006 12:47 PM
> *To:* Bob O'Hara (boohara); [email-masked]
> *Subject:* RE: [Capwap] BSSID-WLAN mappings
> 
> Indeed, the M-SSID mechanism I described is not in the standard but has 
> been implemented by a number of different vendors, including, as I 
> recall, Cisco Aironet. Now that 802.11 chip sets and drivers have better 
> support for M-BSSID, there is little reason to use the more problematic 
> M-SSID. Its only advantage over M-BSSID is that M-SSID uses up fewer MAC 
> addresses.
> 
>  
> 
> Jeff
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Bob O'Hara (boohara) [mailto:[email-masked]]
> *Sent:* 28 April 2006 3:35 PM
> *To:* [email-masked]
> *Subject:* RE: [Capwap] BSSID-WLAN mappings
> 
>  
> 
> The mechanism below is, of course, not compliant with the 802.11 
> standard.  It is a proprietary extension.  It is not clear to me why 
> CAPWAP should support this mechanism, or any other proprietary 
> mechanism.  As Jeff points out below, this is not compatible with all 
> clients (most likely because the mechanism is not mentioned in the 
> standard) and also violates the security assumptions of 802.11.
> 
>  -Bob
>  
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Jeff Joslin [mailto:[email-masked]]
> *Sent:* Friday, April 28, 2006 12:19 PM
> *To:* [email-masked]
> *Subject:* RE: [Capwap] BSSID-WLAN mappings
> 
> You can implement multiple SSID with single BSSID by having only one 
> SSID in the beacon; the others SSIDs are hidden. If a client broadcasts 
> a probe for one of those hidden SSIDs the AP will respond and the client 
> can then do a normal association. The AP maintains one 
> broadcast/multicast key for each encryption type (WEP, TKIP, AES) and 
> uses the appropriate one according to the encryption type of the frame’s 
> SSID. This allows a certain amount of information leakage between SSIDs, 
> but in most applications this is acceptable.
> 
>  
> 
> The above scheme works, after a fashion, but creates some client 
> compatibility issues. Multiple BSSID is preferable.
> 
>  
> 
> One SSID == 1 WLAN. In general we cannot assume that 1 BSSID == 1 WLAN.
> 
>  
> 
> Perhaps 1 VLAN == 1 WLAN is more helpful? It is standard practice to map 
> each SSID to a separate VLAN.
> 
>  
> 
> Jeff Joslin
> 
> Senior Network Architect
> 
> BelAir Networks
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Pat Calhoun (pacalhou) [mailto:[email-masked]]
> *Sent:* 28 April 2006 2:57 PM
> *To:* Puneet; Bob O'Hara (boohara)
> *Cc:* [email-masked]
> *Subject:* RE: [Capwap] BSSID-WLAN mappings
> 
>  
> 
> Well, first, there is no way that I am aware of where you can have 
> multiple SSIDs for a single BSSID. Furthermore, if one were to do this, 
> how would you handle broadcast packet encryption, where a station would 
> see packets from a BSSID, but would not be able to decrypt it - 
> presumably because the AC would have multiple GTKs, not indexed on a 
> BSSID, but some other non-defined mechanism.
> 
>  
> 
> I contend 1 BSSID == 1 WLAN.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* Puneet [mailto:[email-masked]]
>     *Sent:* Monday, April 17, 2006 10:39 AM
>     *To:* Bob O'Hara (boohara)
>     *Cc:* [email-masked]
>     *Subject:* Re: [Capwap] BSSID-WLAN mappings
> 
>     Bob,
> 
>     >  We should not be implementing, or requiring an CAPWAP
>     implementation to implement a method
>     >  that lowers the security of the WLAN.
> 
>     I am not sure I understand the argument here: supporting open or WEP
>     also does the same thing, but CAPWAP supports those encryption
>     protocols. CAPWAP does not force everyone to support WEP, but it
>     *allows* it to be setup on a WLAN. Along the same lines we should
>     allow this mapping too. Maybe make a note that it does not allow
>     WLAN traffic separation into logical groups over the air (Saravanans
>     point)
> 
>     Thanks,
>     Puneet
> 
>     On 4/17/06, *Bob O'Hara (boohara)* <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     There are also security issues when there is not a 1:1 mapping of
>     WLAN to BSSID.  Without this restriction, a station will not have
>     any assurance that traffic it believes is encrypted and protected
>     according to the policy of the WLAN to which it is associated is not
>     being decrypted by an oracle (the AP) and rebroadcast to other
>     stations without the same requirements for abiding with the same
>     security policies.
> 
>      
> 
>     We should not be implementing, or requiring an CAPWAP implementation
>     to implement a method that lowers the security of the WLAN.
> 
>      -Bob
>      
> 
>      
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* Puneet [mailto: [email-masked] <mailto:[email-masked]>]
> 
>     *Sent:* Sunday, April 16, 2006 4:47 PM
>     *To:* Saravanan Govindan
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [Capwap] BSSID-WLAN mappings
> 
>     Hi Saravanan,
> 
>     I see your point, but this seems to address a very specific
>     deployment scenario (service providers sharing WLAN equipment). If
>     nothing else in the CAPWAP messages is dependent on this, then this
>     should be a recommendation instead of a mandate. That way the
>     protocol remains inclusive, and also meets its objective.
> 
>     I think it is very important that existing implementations are not
>     excluded just because they dont seem to meet one specific need in a
>     specific deployment scenario.
> 
>     Thanks,
>     Puneet
> 
>     On 4/15/06, *Saravanan Govindan* <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     Hi Puneet,
> 
>     My concern regarding the BSSID - WLAN mapping is based on the mandatory
>     Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives).
> 
>     The Objective requires that WTP traffic be kept logically distinct
>     among
>     logical groups. This arises from the commercial need of service
>     providers
>     sharing WLAN infrastructure equipment. Service providers want their
>     traffic
>     to be distinguished both over the wireless environment (e.g. BSSIDS)
>     and
>     over the AC-WTP environment (e.g. WLANs).
> 
>     The BSSID-WLAN mapping issue is the technical requirement coming
>     from this
>     commercial need. It allows an AC - or WTP - to decide how logical
>     groups are
>     separated over the wireless and AC-WTP segments. So by making this
>     mapping,
>     CAPWAP frames of different logical groups (WLANs) can be distinctly
>     exchanged.
> 
>     I agree with others that this mapping should not exclude any
>     implementation
>     - my concern is that the mapping be including in the first place.
> 
>     Cheers,
> 
>     Saravanan
> 
> 
> 
> 
>     >  ------------------------------
>     >  *From:* Puneet [mailto:[email-masked] <mailto:[email-masked]>]
>     >  *Sent:* Friday, April 14, 2006 12:29 AM
>     >  *To:* [email-masked] <mailto:[email-masked]>
>     >  *Subject:* [Capwap] BSSID-WLAN mappings
>     >
>     >  the BSSID description in Section 11.9.1 'WTP Radio Configuration'
>     notes
>     >  that a WTP that supports 16 WLANS MUST have 16 MAC addresses
>     reserved for
>     >  it. Why? ie. what part of the protocol does not work if we have
>     multiple
>     >  SSIDs on a single BSSID? (whether thats good design or bad is a
>     different
>     >  matter). Since the WLAN ID could be used in all such places to convey
>     WLAN
>     >  information back to the AC, why do we need to mandate this 1:1
>     BSSID-WLAN
>     >  mapping?
>     >
>     >  Thanks,
>     >  Puneet
>     >
>     >  _________________________________________________________________
>     >  To unsubscribe or modify your subscription options, please visit:
>     >  http://lists.frascone.com/mailman/listinfo/capwap
>     <http://lists.frascone.com/mailman/listinfo/capwap>
>     >
>     >  Archives: http://lists.frascone.com/pipermail/capwap
>     >
> 
>     _________________________________________________________________
>     Get an advanced look at the new version of MSN Messenger.
>     http://messenger.msn.com.sg/Beta/Default.aspx
>     <http://messenger.msn.com.sg/Beta/Default.aspx>
> 
>      
> 
> 
>     _________________________________________________________________
>     To unsubscribe or modify your subscription options, please visit:
>     http://lists.frascone.com/mailman/listinfo/capwap
> 
>     Archives: http://lists.frascone.com/pipermail/capwap
>     <http://lists.frascone.com/pipermail/capwap>
> 
>      
> 
> 
> ------------------------------------------------------------------------
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap

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

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

---

From: "T. Charles Clancy" <[email-masked]>
Date: Mon, 1 May 2006 15:21:49 -0400 (EDT)

Sort of...

As I understand the conversation, in the M-SSID case, you could send an 
encrypted broadcast packet to other people on your WLAN.  This packet 
would be encrypted with a key that other users on other WLANs could know. 
For example, someone on WLAN-B could see NETBIOS broadcast packets from 
devices associated to WLAN-A.  They might even think they could 
communicate with said NETBIOS machines, but unicast packets addressed to 
them would fail (hopefully, assuming the WTP is properly implemented).

Jim's scenario below is somewhat different, where you have someone on the 
wired side sending data that CAPWAP intentionally decides should be 
transmitted to multiple WLANs.  The concern here is more along the lines 
of a chosen ciphertext attack that could leak information about keys by 
seeing packets encrypted multiple times with different keys.  Provided 
people are using good crypto (i.e. not WEP), this shouldn't be a problem.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

On Mon, 1 May 2006, Jim Murphy wrote:

>>  But, the more damning problem for this is the lowering of security and the 
>> violation of the security assumptions on which 802.11i is based.  Crossing 
>> the boundary of a security domain, even if "only" for multicast, 
>> dramatically increases the opportunity for compromise of data that 
>> communicants believe is secure.
>> 
>>  -Bob
>> 
>> 
>> been implemented by a number of different vendors, including, as I recall, 
>> Cisco Aironet. Now that 802.11 chip sets and drivers have better support 
>> for M-BSSID, there is little reason to use the more problematic M-SSID. Its 
>> only advantage over M-BSSID is that M-SSID uses up fewer MAC addresses.
>> 
>> 
>> Jeff
>> 
>> 
>> The mechanism below is, of course, not compliant with the 802.11 standard. 
>> It is a proprietary extension.  It is not clear to me why CAPWAP should 
>> support this mechanism, or any other proprietary mechanism.  As Jeff points 
>> out below, this is not compatible with all clients (most likely because the 
>> mechanism is not mentioned in the standard) and also violates the security 
>> assumptions of 802.11.
>> 
>>  -Bob
>> 
>> 
>> 
>> You can implement multiple SSID with single BSSID by having only one SSID 
>> in the beacon; the others SSIDs are hidden. If a client broadcasts a probe 
>> for one of those hidden SSIDs the AP will respond and the client can then 
>> do a normal association. The AP maintains one broadcast/multicast key for 
>> each encryption type (WEP, TKIP, AES) and uses the appropriate one 
>> according to the encryption type of the frame’s SSID. This allows a certain 
>> amount of information leakage between SSIDs, but in most applications this 
>> is acceptable.
>> 
>> 
>> Well, first, there is no way that I am aware of where you can have multiple 
>> SSIDs for a single BSSID. Furthermore, if one were to do this, how would 
>> you handle broadcast packet encryption, where a station would see packets 
>> from a BSSID, but would not be able to decrypt it - presumably because the 
>> AC would have multiple GTKs, not indexed on a BSSID, but some other 
>> non-defined mechanism.
>> 
>>

---

From: Jim Murphy <[email-masked]>
Date: Wed, 03 May 2006 15:25:48 -0700

T. Charles Clancy wrote:
> would be encrypted with a key that other users on other WLANs could 
> know. For example, someone on WLAN-B could see NETBIOS broadcast packets 
> from devices associated to WLAN-A.  They might even think they could 
> Jim's scenario below is somewhat different, where you have someone on 
> the wired side sending data that CAPWAP intentionally decides should be 

It doesn't matter if the packet originated on the wired side or not
because all broadcast packets from stations must be retransmitted
by the AP.

Yes, people should be using good crypto, but we should not limit the
legitimate flexibility of the protocol to enforce it.

Thanks,

Jim

>>> As I said, this is a proprietary extension, even if it might have 
>>> been provided on some Cisco products.  I hold that CAPWAP is 
>>> chartered to implement a protocol to support 802.11, not the myriad 
>>> proprietary extension that have been hammered onto its side over the 
>>> years.
>>>  But, the more damning problem for this is the lowering of security 
>>> and the violation of the security assumptions on which 802.11i is 
>>> based.  Crossing the boundary of a security domain, even if "only" 
>>> for multicast, dramatically increases the opportunity for compromise 
>>> of data that communicants believe is secure.
>>>
>>>  -Bob
>>>
>>>
>>> Indeed, the M-SSID mechanism I described is not in the standard but 
>>> has been implemented by a number of different vendors, including, as 
>>> I recall, Cisco Aironet. Now that 802.11 chip sets and drivers have 
>>> better support for M-BSSID, there is little reason to use the more 
>>> problematic M-SSID. Its only advantage over M-BSSID is that M-SSID 
>>> uses up fewer MAC addresses.
>>>
>>>
>>> Jeff
>>>
>>>
>>> SSID in the beacon; the others SSIDs are hidden. If a client 
>>> broadcasts a probe for one of those hidden SSIDs the AP will respond 
>>> and the client can then do a normal association. The AP maintains one 
>>> uses the appropriate one according to the encryption type of the 
>>> frame’s SSID. This allows a certain amount of information leakage 
>>> between SSIDs, but in most applications this is acceptable.
>>>
>>>
>>> Perhaps 1 VLAN == 1 WLAN is more helpful? It is standard practice to 
>>> map each SSID to a separate VLAN.
>>>
>>>
>>> Jeff Joslin
>>>
>>> Senior Network Architect
>>>
>>> BelAir Networks
>>>
>>>
>>> multiple SSIDs for a single BSSID. Furthermore, if one were to do 
>>> this, how would you handle broadcast packet encryption, where a 
>>> station would see packets from a BSSID, but would not be able to 
>>> decrypt it - presumably because the AC would have multiple GTKs, not 
>>> indexed on a BSSID, but some other non-defined mechanism.
>>>
>>>

---

From: Charles Clancy <[email-masked]>
Date: Wed, 03 May 2006 20:17:59 -0400

Jim Murphy wrote:
> 
> 
> T. Charles Clancy wrote:
> 
>> Sort of...
>>
>> As I understand the conversation, in the M-SSID case, you could send 
>> an encrypted broadcast packet to other people on your WLAN.  This 
>> packet would be encrypted with a key that other users on other WLANs 
>> could know. For example, someone on WLAN-B could see NETBIOS broadcast 
>> packets from devices associated to WLAN-A.  They might even think they 
>> could communicate with said NETBIOS machines, but unicast packets 
>> addressed to them would fail (hopefully, assuming the WTP is properly 
>> implemented).
>>
>> the wired side sending data that CAPWAP intentionally decides should 
>> be transmitted to multiple WLANs.  The concern here is more along the 
>> lines of a chosen ciphertext attack that could leak information about 
>> keys by seeing packets encrypted multiple times with different keys.  
>> Provided people are using good crypto (i.e. not WEP), this shouldn't 
>> be a problem.
> 

Your proposed security flaw has to do with CAPWAP data packets being 
marked for transmission on multiple WLANs, for each each may have a 
different crypto type.  My point is that this could only ever happen on 
purpose, for example if someone configured some sort of multicast group. 
  It could cause a theoretic crypto attack if someone is using WEP, but 
if they're using WEP they have bigger problems, like actual practical 
crypto attacks.

Adding support fro M-SSID would cause all broadcast traffic on the same 
WTP to be visible to all devices, and this is both a security problem, 
and a protocol problem.  It's a security problem because you have data 
being leaked between WLANs, and it's a problem for upper-layer protocols 
because they may discover each other via broadcasts, but then not be 
able to actually communicate via unicast.

---

From: Jim Murphy <[email-masked]>
Date: Thu, 04 May 2006 11:13:49 -0700

> able to actually communicate via unicast.

It is not clear to me that M-SSID proposes that all broadcasts would
be visible by all stations associated with the BSSID. Each SSID would
have its own group shared key and each may or may not be of the same
crypto type. This is no different than the current draft's exposure.

Thanks,

Jim