1. November 18, 2002 IETF #55, ATLANTA1 Problem with Compound Authentication Methods Jesse Walker Intel Corporation ( jesse.walker@intel.com )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

2. November 18, 2002 IETF #55, ATLANTA2 Problem = Man-in-the-Middle Attacks Compound Methods = Tunneled or 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

3. November 18, 2002 IETF #55, ATLANTA3 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

4. November 18, 2002 IETF #55, ATLANTA4 EAP-TTLS Normal WLAN Authentication 802.1XRADIUS EAP Wireless Station EAP/Identity Request EAP/Identity Response (anonymous@realm) Tunnel establishment EAP/Identity Request EAP/Identity Response (user id@realm) EAP/ Request / Method Challenge EAP/Response/Method Response EAP/ Success EAP Method inside Tunnel SupplicantAuthenticator WLAN Session Tunnel Keys ClientAPAAA-H ServerTTLS Server Inner Method Keys Derived & Not Used Inner Method Keys Derived Tunnel Keys Derived

5. November 18, 2002 IETF #55, ATLANTA5 EAP-TTLS based WLAN session stealing EAP/Identity Request EAP/Identity Response (anonymous@realm) Tunnel establishment EAP/Identity Request EAP/Identity Response (user id@realm) EAP/ Request / Method Challenge EAP/Response/ Method Response EAP/ Success EAP-Method in Tunnel WLAN Session Stolen Tunnel Keys ClientMitM AAA-H Server TTLS Server AP Inner EAP Method Keys Derived & Not used Tunnel Keys Derived Inner Method Keys Derived

6. November 18, 2002 IETF #55, ATLANTA6 PEAP/EAP-AKA WLAN Session Stealing

7. November 18, 2002 IETF #55, ATLANTA7 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

8. November 18, 2002 IETF #55, ATLANTA8 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

9. November 18, 2002 IETF #55, ATLANTA9 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

10. November 18, 2002 IETF #55, ATLANTA10 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

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

12. November 18, 2002 IETF #55, ATLANTA12 Why cryptographic binding? Methods that use a weak keys 1.MUST be used within a server authenticated tunnel, and 2.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 authentication methods –secure: avoid MitM attack –non-invasive: avoid imposing restrictions on strong methods

13. November 18, 2002 IETF #55, ATLANTA13 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

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

15. November 18, 2002 IETF #55, ATLANTA15 Backup

16. November 18, 2002 IETF #55, ATLANTA16 Tunneled Methods Generic Model 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 ClientAuthenticationAgentAuthenticationServer Stage 1: Tunnel Method Server authenticated for secure tunnel establishment Stage 2: Client Authentication Method Performs Client/User Authentication secure tunnel Front-endauthenticator Ciphered Link Tunnel Keys

17. November 18, 2002 IETF #55, ATLANTA17 Sequenced Methods Generic Model ClientAuthentication Agent 1 Authentication Agent 2 Protocol Sequence 1 Client AND/OR Server Authentication Protocol Sequence 2 Client AND/OR Server Authentication Front-endauthenticatorAuthenticationServer Protocol Sequence N Client AND/OR Server Authentication …. … No Session Keys Open Link 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.