1 / 35

802.1X Misuses

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

armani
Télécharger la présentation

802.1X Misuses

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 802.1X Misuses David Johnston david.johnston@ieee.org David Johnston, Mobilian

  2. 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

  3. 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

  4. 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

  5. Hence - Klein Layering: David Johnston, Mobilian

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. TGe MAC Layering (02-439) David Johnston, Mobilian

  15. Revised TGe/i MAC Layering David Johnston, Mobilian

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. Motion #1 • Move that the editor incorporate into the draft the changes describes in document 11-02-xxxr0 (Relayering) David Johnston, Mobilian

  34. Motion #2 • Move that the editor incorporate into the draft the changes describes in document 11-02-xxxr0 (Re-encapsulation) David Johnston, Mobilian

  35. 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

More Related