TSN Architecture Mike Moreton, STMicroelectronics doc.: IEEE 802.11-04/xxxx February 2004 February 2004 TSN Architecture Mike Moreton, STMicroelectronics February 19, 2004 Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

doc.: IEEE 802.11-04/xxxx February 2004 February 2004 Why MLME? MLME and MA interfaces describe a functional split between the MAC and “everything else” Make it easier to understand the problem, by splitting it in two. Describe the architecture – particularly important in security. Needs to be “almost” implementable. Does not constrain implementation. It’s exactly these issues of “who knows what when” that have led to problems with the 4 way handshake. While the MLME/MA architectural split does not constrain an implementation, it’s up to the implementer to check the security of any other architecture. Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

802.1X Filtering The 802.1X filtering function is “above” the MAC doc.: IEEE 802.11-04/xxxx February 2004 February 2004 802.1X Filtering The 802.1X filtering function is “above” the MAC MLME-ASSOCIATE.ind requires filtering to exist for STAs that the Authenticator doesn’t know about. In a TSN, some STAs are not RSNA capable 802.1X filtering will be applied to them as well To prevent a race condition between an MLME-ASSOCIATE.indication and an immediately following data frame, the 802.1X filtering function must behave as if there is an uncontrolled/(unauthorised)controlled port pair instantiated for every possible MAC address. At this point we’re not saying that there isn’t WEP based filtering as well, just that whether there is or not, 802.1X filtering will be applied anyway. Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

doc.: IEEE 802.11-04/xxxx February 2004 February 2004 Pre-RSNA Ports How is 802.1X filtering turned off for pre-RSNA devices? Could have special code in the filtering code to handle such devices. But if already treating them as if there was a controlled/uncontrolled port pair, why not just authorise the controlled port? Conclusion: Pre-RSNA devices have controlled/uncontrolled ports But they don’t have an 802.1X PAE In some senses you could argue that they do have a PAE, but that it’s different from an 802.1X one Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

Filtering in an 802.11 Environment February 2004 Filtering in an 802.11 Environment 802.1X filtering only works if protection is enabled before the controlled port is authorised. For a pre-RSNA device, this means turning on WEP. Two options – the MAC could do it, or the SME could do it. Mike Moreton, STMicroelectronics

Option 1 – MAC Enables WEP doc.: IEEE 802.11-04/xxxx February 2004 February 2004 Option 1 – MAC Enables WEP MAC digs into the Association Request, spots that there is no RSN IE, and hence turns on WEP. Against the spirit of both TGi and 802.11-1999 where enabling/disabling encryption is the responsibility of the SME Requires extra code in the MAC AP architecture for pre-RSNA devices different than for RSNA devices. (1) Alternatively WEP is normally on, and when an RSN IE is present it turns it off for that STA. Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

Option 2 – SME Enables WEP doc.: IEEE 802.11-04/xxxx February 2004 February 2004 Option 2 – SME Enables WEP By default MAC receives unencrypted frames from anywhere Relies on 802.1X filtering that we know is there. When SME gets a pre-RSNA association, it enables WEP before authorising the controlled port for that device. No special handling in the MAC AP Architecture for Pre-RSNA and RSNA devices is the same Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

doc.: IEEE 802.11-04/xxxx February 2004 February 2004 One slight twist… The current WEP configuration interface is not flexible enough The current WEP configuration interface is not synchronised So… Allow WEP to be configured as a pairwise key through the SETKEYS and SETPROTECTION interfaces The issue with WEP configuration is that the Discard Protected flag is not per-STA. Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

One Unexpected Benefit? doc.: IEEE 802.11-04/xxxx February 2004 February 2004 One Unexpected Benefit? TSN APs don’t have to support pre-RSNA per-frame pseudocode An advantage when WEP dies… Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

One Unavoidable(?) Problem doc.: IEEE 802.11-04/xxxx February 2004 February 2004 One Unavoidable(?) Problem When a pre-RSNA device associates, some frames from it may be lost while the 802.1X port is authorised. Implementations could fix it by attaching a flag to frames indicating the association type. Correct architectural solution is to add MLME-ASSOCIATE.response This is an existing problem, not one introduced by this proposal. For pre-RSNA devices, SME would enable WEP, authorise the controlled port, and send MLME-ASSOCIATE.response. Could this also remove the need for 1X filtering on pre-RSNA connections? Well no, the same arguments about whether you want WEP specific functionality in the 1X filtering, and how actually to configure WEP still apply. Mike Moreton, STMicroelectronics Fred Stivers, Texas Instruments

Architectural Responsibilities February 2004 Architectural Responsibilities MAC sends and receives frames, protected or unprotected as required. SME decides which encryption suites to use, and when. SME is responsible for protocol based frame filtering. MAC is responsible for source based filtering (when required by SME) Mike Moreton, STMicroelectronics

Conclusion This is not the only possible architecture February 2004 Conclusion This is not the only possible architecture But we need an architecture to analyse, and this is one. Relatively simple and consistent. Mike Moreton, STMicroelectronics