1 / 17

Problem with Compound Authentication Methods

Problem with Compound Authentication Methods. Jesse Walker Intel Corporation ( jesse.walker@intel.com ) ACKNOWLEDGEMENTS: N.ASOKAN, KAISA NYBERG, VAL T TERI NIEMI, HENRY HAVERINEN, NOKIA JOSE PUTHENKULAM, VICTOR LORTZ, FARID ADRANGI, INTEL CORPORATION

lapham
Download Presentation

Problem with Compound Authentication Methods

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. Problem with Compound Authentication Methods Jesse Walker Intel Corporation ( jesse.walker@intel.com ) ACKNOWLEDGEMENTS: N.ASOKAN, KAISA NYBERG, VALTTERI NIEMI, HENRY HAVERINEN, NOKIA JOSE PUTHENKULAM, VICTOR LORTZ, FARID ADRANGI, INTEL CORPORATION BERNARD ABOBA, ASHWIN PALEKAR, DAN SIMON, MICROSOFT IETF #55, ATLANTA

  2. Problem = Man-in-the-Middle Attacks Compound Methods = Tunneledor Sequenced Methods • where there is no strong mutual authentication • where the keys derived from mutual authentication are not the keys used for ciphering the link • where tunnel termination is not on the real endpoints (client or server) • where the authentication protocol derives no keys We focus mainly on tunneled EAP authentication methods IETF #55, ATLANTA

  3. WLAN Man-in-the-Middle Attack • Assumptions: • Rogue AP/Suppliant combo device acts as man-in-the middle • Real Supplicant/Server supports any unprotected EAP type without tunnel protocol • Observations • WLAN Session stolen by the attack • EAP-TTLS, PEAP, PIC, PANA over TLS, XAUTH… all susceptible IETF #55, ATLANTA

  4. EAP-TTLS Normal WLAN Authentication Supplicant Authenticator Client AP TTLS Server AAA-H Server Wireless Station EAP 802.1X RADIUS EAP/Identity Request EAP/Identity Response (anonymous@realm) Tunnel establishment Tunnel Keys Derived Tunnel Keys Derived EAP Method inside Tunnel EAP/Identity Request EAP/Identity Response (user id@realm) EAP/ Request / Method Challenge EAP/Response/Method Response EAP/ Success Inner Method Keys Derived Tunnel Keys Inner Method Keys Derived & Not Used WLAN Session IETF #55, ATLANTA

  5. EAP-TTLS based WLAN session stealing <- RogueAP/Client -> TTLS Server AAA-H Server Client MitM AP EAP/Identity Request EAP/Identity Response (anonymous@realm) Tunnel establishment Tunnel Keys Derived Tunnel Keys Derived EAP-Method in Tunnel EAP/Identity Request EAP/Identity Response (user id@realm) EAP/ Request / Method Challenge EAP/Response/ Method Response EAP/ Success Inner Method Keys Derived Tunnel Keys Inner EAP Method Keys Derived & Not used WLAN Session Stolen IETF #55, ATLANTA

  6. PEAP/EAP-AKA WLAN Session Stealing <- UMTS Tower/ WLAN Terminal -> IETF #55, ATLANTA

  7. Tunnels Problem Analysis • One-way authenticated tunnel • Even secure inner methods are vulnerable when composed incorrectly. • Man-in-the-middle can trick client into believing it is a server • Session keys derived from tunnel protocol only. • Keys derived in inner EAP method (e.g., Method Keys) are not used. • Client policy of not always using tunnels causes failure • Any Client EAP method not cryptographically bound to Tunnel Session Keys potentially vulnerable • All non-ciphered/non-protected links fully vulnerable IETF #55, ATLANTA

  8. Solution Requirements • Fixes to existing EAP methods not ok • Fixes to new EAP methods maybe ok • Fixes to Tunnel methods maybe ok • Should work for different tunnel termination models • Should not bring new requirements for other protocols (eg. RADIUS ) • Forward Evolution for protocols with fix • Backwards compatibility for fixed protocols • Simplicity for fix (low compute costs & roundtrips) • Upgraded EAP Base protocol maybe ok IETF #55, ATLANTA

  9. EAP Methods classification • Methods which support ciphering • Derive session keys • Do key distribution to Access points using RADIUS attributes • Eg. EAP-MSCHAPv2, EAP/SIM, EAP/AKA • Methods which don’t support ciphering • Not protected • Eg. EAP-MD5 FIXABLE FIXABLE BY USAGE RESTRICTION IETF #55, ATLANTA

  10. Solution Concept • Compound MACs • MACs computed from safe one-way derivation from keys of all EAP methods • Compound Keys • Bound Key derived using safe one-way derivation from keys of all EAP methods • Additional strong mutual authentication round trip with acknowledged success message • Success Message with Client MAC • Success-Ack Message with Server MAC over Client MAC IETF #55, ATLANTA

  11. Man-in-the-middle attack failure with solution <- RogueAP/Client -> TTLS Server AAA-H Server Client MitM AP EAP/Identity Request EAP/Identity Response (anonymous@realm) TLS Session establishment Tunnel Keys Derived Tunnel Keys Derived EAP-Method in TLS Protected Session EAP/Identity Request EAP/Identity Response (user id@realm) EAP/ Request / Method Challenge EAP/Response/ Method Response EAP/ Success Inner EAP Method Keys Compound MAC Success Inner EAP Method Keys Compound MAC Failure Crypto Binding Attack Detected No Keys Sent No WLAN Access IETF #55, ATLANTA

  12. Why cryptographic binding? • Methods that use a weak keys • MUST be used within a server authenticated tunnel, and • MUST NOT be used without tunnel to authenticate same client • #2 drastically reduces use of legacy auth. protocols • MUST NOT be imposed on protocols that use strong keys • Tunneling protocols (PEAP, POTLS etc.) address #1 • But they treat the inner protocol as a blackbox (any EAP type) • Hence the need for optional binding of tunnel and EAP method • This allows tunneling protocols to • generic: handle both weak and strong authenticationmethods • secure: avoid MitM attack • non-invasive: avoid imposing restrictions on strong methods IETF #55, ATLANTA

  13. Recommendations to EAP WG • Tunneled and Sequenced Protocols have evolved from NEED • Problem needs to be fixed • Best fix would be • in EAP base protocol, and • in tunneling protocols • Recommend formation of design team to study proposed fixes and recommend solution for EAP base protocol IETF #55, ATLANTA

  14. References • Nokia Research Center • http://eprint.iacr.org/2002/163/ • http://www.saunalahti.fi/~asokan/research/mitm.html • Intel Corporation, Microsoft • http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt IETF #55, ATLANTA

  15. Backup IETF #55, ATLANTA

  16. Tunneled Methods Generic Model Client Front-end authenticator Authentication Agent Authentication Server Stage 1: Tunnel Method Server authenticated for secure tunnel establishment secure tunnel Stage 2: Client Authentication Method Performs Client/User Authentication Ciphered Link Tunnel Keys Terminology Tunnel endpoint is authentication ”agent” Authentication protocol endpoint is authentication ”server” ”Front-end” authenticator is end of access link to be authenticated Agent and Server may be co-located IETF #55, ATLANTA

  17. Sequenced Methods Generic Model Client Front-end authenticator Authentication Agent 1 Authentication Agent 2 Authentication Server …. Protocol Sequence 1 Client AND/OR Server Authentication Protocol Sequence 2 Client AND/OR Server Authentication … Protocol Sequence N Client AND/OR Server Authentication Open Link No Session Keys Terminology ”Front-end” authenticator is end of access link to be authenticated Intermediate endpoint in sequence is an authentication ”agent” Final authentication endpoint is authentication ”server” Agents and Server may be co-located. IETF #55, ATLANTA

More Related