350 likes | 606 Views
802.1X Misuses. David Johnston david.johnston@ieee.org. An Appeal for Simplicity. We have spent a lot of time fiddling with details of our authentication mechanism. A lot more needs to be done to fill in the gaps There may be simpler architectures that achieve our ends with less complexity
E N D
802.1X Misuses David Johnston david.johnston@ieee.org David Johnston, Mobilian
An Appeal for Simplicity • We have spent a lot of time fiddling with details of our authentication mechanism. A lot more needs to be done to fill in the gaps • There may be simpler architectures that achieve our ends with less complexity • I contend that we can benefit from using the architecture that has been laid out already • 802.1X – Read It! • 802.11-1999 – Authentication MMPDUs, MLME, filtering rules David Johnston, Mobilian
Observation: 802.1X is Not a Layer! • There is no 802.1X_SAP • LLC Interface is not defined • No Encapsualtion • 802.1X is: • Controlled and uncontrolled ports below the DS in the MAC • EAPOL messaging injected at the uncontrolled port • State Machines • Management via managed objects (SNMP) David Johnston, Mobilian
No such service Wrong place for controlled port DS/802.1d bridging bypasses 802.1X here 802.1X doesn’t have this interface. Management is through MIB Current Layering LSAP missing from this diagram David Johnston, Mobilian
Hence - Klein Layering: David Johnston, Mobilian
The Legacy Authentication Problem • A Legacy station meets an RSN AP • Does not see the RSNE • Attempts Open Authentication • Succeeds! • Successful auth reported to user • AP Proceeds to drop all traffic on the floor David Johnston, Mobilian
The Ambiguous LLC Header Problem • Per MSDU Rx procedure is to examine traffic for 802.1X EAPOL messages. • This takes place below the LLC and on data MSDUs • Thus LLC encapsulation is not universal • Data frame could be formed to look like an LLC header+SNAP header+EAPOL • Inspection process would erroneously pass this to the uncontrolled port. David Johnston, Mobilian
The Pre-Authentication Problem • 1999 standard allows a STA to authenticate to many APs and associate to 1. • Allows Pre-Authentication • TGi requires RSN authentication after association • Can only associate to 1, thus can only RSN authenticate to 1. • Hence have a hack to send EAPOL via the DS – Does not work if the MAC address is not sufficient to identify the other AP (E.G. across IP Subnets) • So despite having a perfectly good RF path to the AP, we can’t pre-authenticate to it. • See LB2299. TGi Rejected this point. But it is still valid. David Johnston, Mobilian
The Missing Interfaces Problem • In order for signaling to warp past the LLC from the MAC to 802.1X, new interfaces need to be defined • 802.1X_SAP • MLME-802.1X_SAP • The 802.1X ‘way’ is for to manage 802.1X through 802.1X managed objects and for the datapath to interact through state machine variables David Johnston, Mobilian
Why all these Problems? :802.1X may be in the Wrong Place • Leading to: • Legacy Authentication Problem • Ambiguous LLC Header Problem • The Pre-Authentication Problem • The Missing Interfaces Problem • Complex Filtering Rules • Klein Layering (Layer Violations) David Johnston, Mobilian
But 802.1X Works Fine in 802.3! • 802.3 has an ethertype field and 802.1X uses it. • No LLC header ambiguity • 802.3 has no DS. Only 802.1d bridging • 802.1X traffic identified before .1d sees it • 802.1d will not bounce traffic back down the stack or onto a portal like the DS will • 802.3 doesn’t have roaming • No pre authentication problem • 802.3 doesn’t have authenticate before associate • It has plug-in before authenticate • 802.1X is still not a layer in 802.3 David Johnston, Mobilian
Solution: Reposition 802.1X to the SME • 802.1X works if the port is placed below the DS, above defragmentation and above burst ack reordering. The state machines work in the SME. • Can work on MSDUs • Needs to block access to all services above defragmentation (E.G. DSS) • Existing 802.1X provisions for managing 802.1X work David Johnston, Mobilian
How is this Done? • Define where in layering the 802.1X controlled port lies within the layering in 02-439. • Solves Missing Interfaces Problem • Removes Klein Layering • Define an 802.11 EAPOL format to use management auth/deauth frames • Solves Ambiguous LLC Problem • Extend Open and Shared Key Auth to include RSN Auth • Solves Legacy Authentication Problem • Solves Pre-Authentication Problem • Works with existing 1999 authentication-association states David Johnston, Mobilian
TGe MAC Layering (02-439) David Johnston, Mobilian
Revised TGe/i MAC Layering David Johnston, Mobilian
EAPOL/.11 Encapsulation • 802.1X defines encapsulation for .3, .4 and .5. Suggests an LLC/SNAP header for .11 style MACs. • This encapsulation does not work for us. Instead: • 7.2.3.10 Define RSN Authentication Frame encapsulation: 0x0002, 0x0000, reserved, EAPOL frame • 7.3.1.1 Define ‘Authentication Algorithm Number = 2: RSN’ David Johnston, Mobilian
EAPOL/.11 Encapsulation • Controlled – Uncontrolled port differentiation is unnecessary. • 802.1X EAPOL messages come in MMPDUs and pass through the SME, where the 802.1X state machines are. • Data traffic passes through as MSDUs and can be filtered according to aExcludeUnencrypted • No change required from 1999 filtering • The 802.1X state machine variables are in the SME and in the MAC. No layer violations needed for the controlled port to be controlled. David Johnston, Mobilian
Table 19—Status codes Authentication Frame 7.3.1.1 Authentication Algorithm Number field The Authentication Algorithm Number field indicates a single authentication algorithm. The length of the Authentication Algorithm Number field is 2 octets. The Authentication Algorithm Number field is illustrated in Figure 24. The following values are defined for authentication algorithm number: Authentication algorithm number = 0: Open System Authentication algorithm number = 1: Shared Key Authentication algorithm number = 2: RSN All other values of authentication number are reserved. EAPOL 802.1X message information is only present in Authentication frames pertaining to the IEEE 802.1X Authentication algorithm. 4 802.1X message element David Johnston, Mobilian
Table 19—Status codes Authentication algorithm Authentication transaction sequence number Status Code Challenge text 802.1X Message Open System 1 Reserved Not Present Not Present Open System 2 Status Not Present Not Present Shared Key 1 Reserved Not Present Not Present Shared Key 2 Status Present Not Present Shared Key 3 Reserved Present Not Present Shared Key 4 Status Not Present Not Present RSN n (n = 1, 2, …) Status Not Present Present Authentication Frame (cont) Table 14 David Johnston, Mobilian
Table 19—Status codes Status Code Meaning 0 Successful 1 Unspecified failure 2-9 Reserved 10 Cannot support all requested capabilities in the Capability Information field 11 Reassociation denied due to inability to confirm that association exists 12 Association denied due to reason outside the scope of this standard 13 Responding station does not support the specified authentication algorithm 14 Received an Authentication frame with authentication transaction sequence number out of expected sequence 15 Authentication rejected because of challenge failure 16 Authentication rejected due to timeout waiting for next frame in sequence 17 Association denied because AP is unable to handle additional associated stations 18 Association denied due to requesting station not supporting all of the data rates in the BSSBasicRateSet parameter 19 RSN Authentication in progress 20-65,535 Reserved Status Codes David Johnston, Mobilian
MLME • Framework exists in MLME for carrying authentication messages • Not using them requires that authentication behaviour and semantics attached to these messages needs to be respecified • Using them means less has to be changed from the 1999 spec. • So: Extend the current mechanism David Johnston, Mobilian
MLME • MLME-AUTHENTICATE.request • Add RSNAuthenticationMessage • Add RSN_Authentication Type • Add frame format for above type • MLME-AUTHENTICATE.confirm • Add RSNAuthenticationMessage • Add RSN_Authentication Type • Add frame format for above type David Johnston, Mobilian
MLME • MLME-AUTHENTICATE.indication • Add RSNAuthenticationMessage • Add RSN_Authentication Type • Add frame format for above type • Create MLME-AUTHENTICATE.response • Generated by the SME on behalf of the 802.1X of the responder of the authentication service as a result of an MLME-AUTHENTICATE.request to authenticate with a specified peer MAC entity. David Johnston, Mobilian
Tx & Rx Behaviour • Rx MSDUs thrown away according to aExcludeUnencrypted • Tx MSDUs thrown away according to aExcludeUnencrypted • Authentication type 2 (RSN) MMPDUs passed on to 802.1X via the uncontrolled port. Type 0 and 1 (Open & Shared Key) passed on to open and shared key authentication respectively David Johnston, Mobilian
Legacy Behaviour • Legacy STA vs TSN AP • Attempt open or shared key auth. • Legacy STA vs RSN AP • Attempts to do open or shared key auth will fail. • RSN STA vs Legacy AP • See no RSNE. Ignore AP • TSN STA vs Legacy AP • See no RSNE. Try open or shared key auth • RSN or TSN STA vs RSN or TSN AP • See RSNE. Use negotiated RSN authentication David Johnston, Mobilian
Overall Layering Unchanged 802.1X controlled port implemented in Security Filtering process in MAC No 802.1X SAP No MLME-802.1X SAP Less code to write! 802.1X done here Uncontrolled port traffic over MMPDUs, direct into SME Existing MLME service carries authentication messages David Johnston, Mobilian
Authentication Usable with WEP • With RSN authentication being an extension of existing mechanisms, cipher type is orthogonal to authentication. it can be used as a software only rekeying mechanism for WEP. Thus providing a partial solution for legacy systems on which TKIP cannot be implemented. • On legacy hardware • Implement TSN authentication • Implement weak IV skipping • Implement frequent rekeying via 802.1X from a server • Script kiddy attacks are prevented on legacy systems (at least for a short while) David Johnston, Mobilian
API Issues • Most 802.1X host interaction reduced to configuration via managed objects. • 802.1X defines an SNMP mechanism • An 802.11 implementation will have a mechanism for configuring managed objects anyway • Imposes no complex/proprietary/ill-documented API to bolt to the top of the 802.1X_SAP • Mapping between OIDs and 802.1X managed objects (in OSs that do that sort of thing) need not change since the managed objects don’t change. David Johnston, Mobilian
Letter Ballot Comments Addressed • 2161 – Roaming unchanged • 1322, 229 – WEP, TSN, RSN interactions clear • 2300 – Authentication frames used • 1252 – The key transport can be moved into the MAC • 1479, 213, 2307, 533 – 802.1X isn’t upper layer any more • 1480, 2202, 1483, 1492 – Ports, filtering and pre-auth well defined • 2308 – 802.1X is in the SME • 2310 – Uncontrolled port is over MMPDUs • 1495, 1488, 1486, 2311 – Pre authentication uses existing mechanisms • 1485 – Existing state machine applies • 535 – Clear architectural relationships are defined • 1402 – No longer applicable • 588, 1032 – Layering violations removed • 1033 – Authentication works for WEP, TKIP and RSN David Johnston, Mobilian
How Big a Change is This? • What doesn’t change: • 802.1X remains the basis for authentication • EAPOL/EAP-TLS/PEAP methods remain • Controlled port remains but is more concisely defined • WRAP, TKIP, CCMP unchanged • What changes: • Some as yet undefined interfaces go away (802.1X_SAP, MLME-802.1X_SAP) • LLC Header inspection goes away • Filtering rules get simpler (but they aren’t properly defined anyway) • EAPOL Encapsulation Changes (use an MMPDU not MSDU) • Conclusion • The only significant implementation change is the encapsulation. This is not a big issue in implementations. Much of the rest is design by subtraction. David Johnston, Mobilian
Implementation Issues? • 802.1X in a host, across an interface from the SME • Need to signal EAPOL messages across interface • Need to signal critical variable changes across interface (portSecure) • Not different to current 802.1X_SAP and MLME-802.1X interfaces, but they become implementation specific • 802.1X in the SME, SME in the NIC • Design gets simpler. Variables directly available in the SME scope to direct management behaviour • 802.1X in the SME, in a host across an interface from an MPDU only transport in the NIC • Design gets simpler. Variables directly available in the SME to direct management behaviour • Reencapsulation • 802.1x must send frames using MLME.xyz rather than MA.UNITDATA.xyz. • Required Per MAC encapsulation. As currently required in 802.1x. David Johnston, Mobilian
The Text • Document 11-02-xxxr0 contains changes to draft D2.5 to incorporate the mechanisms outlined in this presentation related to moving 802.1x into the SME • Document 11-02-xxxr0 contains changes to draft D2.5 to incorporate the mechanisms outlined in this presentation related to encapsulation of 802.1x frames in management frames David Johnston, Mobilian
Motion #1 • Move that the editor incorporate into the draft the changes describes in document 11-02-xxxr0 (Relayering) David Johnston, Mobilian
Motion #2 • Move that the editor incorporate into the draft the changes describes in document 11-02-xxxr0 (Re-encapsulation) David Johnston, Mobilian
Thoughts For the Future • Are we using 802.1X? • We changed it. It is something else. • Should we give it a new name (802.11, section x.y) • Should we separate encapsulation of authentication and key exchange, so authentication can be updated while keeping 802.11 key exchange. E.G. Authentication type 3 frames (key exchange) happen as last phase of auth, after RSN authentication (802.1x) • Potential bolt-on authentication schemes might be… • 802.1X • Simple shared password scheme (home LANs?) • Wide open scheme (unsecured networks) • Proprietary schemes • IEEE standard AMP Protocols? P1363? David Johnston, Mobilian