March 17, 2003 IETF #56, SAN FRANCISCO1 Compound Authentication Binding Problem (EAP Binding Draft) Jose Puthenkulam Intel Corporation ( ) ACKNOWLEDGEMENTS: ASHWIN PALEKAR, DAN SIMON, BERNARD ABOBA – MICROSOFT VICTOR LORTZ, FARID ADRANGI, JESSE WALKER - INTEL CORPORATION N.ASOKAN, KAISA NYBERG, VALTTERI NIEMI, HENRY HAVERINEN - NOKIA JOE SALOWEY, NANCY CAM-WINGET – CISCO, JARI ARKKO – ERICSSON MOHAN PARTHASARATHY – TAHOE NETWORKS Copyright © 2003, The Internet Society

March 17, 2003 IETF #56, SAN FRANCISCO2 Agenda Compound Methods Motivation Problem Summary Solutions Conclusion/Next Steps

March 17, 2003 IETF #56, SAN FRANCISCO3 Compound Methods Definition: Multiple authentication methods used in concert for a single purpose –Tunneled methods –Sequenced methods Typical Purposes –Network access authentication & authorization –Security Association establishment for protecting data traffic –Service access authentication & authorization –…

March 17, 2003 IETF #56, SAN FRANCISCO4 Motivation for Compound Methods using Tunnels Securing legacy methods in new environments Ease of deployment for securing legacy methods Providing consistent security properties and other features for different methods Securing multiple credentials in sequences

March 17, 2003 IETF #56, SAN FRANCISCO5 Problem = Man-in-the-Middle Attacks Focus is on Compound Tunneled Methods that support –single inner method –sequence of inner methods Non-tunneled Compound Sequences are also potentially vulnerable but not addressed –problem space unbounded? further study needed

March 17, 2003 IETF #56, SAN FRANCISCO6 Example WLAN Attack Scenario EAP/Identity Request EAP/Identity Response Tunnel establishment EAP/Identity Request EAP/Identity Response (user EAP/ Request / Method Challenge EAP/Response/ Method Response EAP/ Success EAP-Method in Tunnel WLAN Session Stolen Tunnel Keys ClientMitM Home AAA Server Tunnel Server AP Inner EAP Method Keys Derived & Not used Tunnel Keys Derived Inner Method Keys Derived

March 17, 2003 IETF #56, SAN FRANCISCO7 Problem Conditions Dual role man-in-the-middle attacker (rogue authenticator + rogue supplicant) Credential and authentication method re- use with and without tunnels Use of one-way server authenticated tunnel Use of tunnel session keys alone and no inner method session keys All conditions have to be true for the attack

March 17, 2003 IETF #56, SAN FRANCISCO8 Solution Requirements Fixes to existing EAP methods not ok Fixes to new EAP methods maybe ok Fixes to Tunnel methods 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

March 17, 2003 IETF #56, SAN FRANCISCO9 Solution Concepts All methods –Use separate credentials inside and outside tunnels –Use methods inside tunnels always Key deriving methods –Can use cryptographic binding Binding can provide stronger authentication & session keys Avoids policy synchronization issues Preserves deployment convenience of one-way authenticated tunnels

March 17, 2003 IETF #56, SAN FRANCISCO10 Solution Mechanisms Recommended Policy restrictions –For non-key deriving methods client & server policy Use separate credentials inside/outside tunnels Use methods inside tunnels always Cryptographic Binding –Compound Keyed MACs Keyed MACs computed from safe one-way derivation from keys of all inner methods and tunnel method Additional mutual authentication round trip (binding phase exchange) with keyed MACs –Compound Session Keys Bound Key derived using safe one-way derivation from keys of all inner methods and tunnel method

March 17, 2003 IETF #56, SAN FRANCISCO11 Binding Phase Exchange with Compound Keyed MACs Binding Request B1 Binding Response B2 [VERSION,S_NONCE,……….. B1_MAC] [VERSION,C_NONCE,……….. B2_MAC] CMK_B1 (B1_MAC Key) Compound MAC Key Derivation S_NONCE TSK ISK1….ISKn Compound MAC Key Derivation S_NONCE C_NONCE TSK ISK1….ISKn CMK_B2 (B2_MAC Key) TSK = Tunnel Session Keys ISKi = Inner Session Keys for each method ‘i’ where i = 1..n C_NONCE = 256 bit random number derived on client S_NONCE = 256 bit random number derived on server Note: Sufficiency of 2-way handshake is based on binding using fresh session keys

March 17, 2003 IETF #56, SAN FRANCISCO12 Thwarting the attack with binding EAP/Identity Request EAP/Identity Response TLS Session establishment EAP/Identity Request EAP/Identity Response (user EAP/ Request / Method Challenge EAP/Response/ Method Response EAP/ Success EAP-Method in TLS Protected Session No Keys Sent ClientMitM Home AAA Server Tunnel Server AP Inner EAP Method KeysBinding Request B1 (B1 MAC) Binding Response B2 (B2 MAC) Attack Detected No WLAN Access Crypto Binding Inner EAP Method Keys Tunnel Keys Derived Binding Phase Exchange Crypto Binding

March 17, 2003 IETF #56, SAN FRANCISCO13 Solution Approaches Add Binding Phase to EAP base protocol or Tunnel Protocol –Already need for protected success/failure indication identified –Binding Phase exchange can also include the protected success/failure indication –Method Key export interface available –Cryptographic binding can give stronger keys Add Policy rules to Client and Server –Provides fix for non-key deriving methods

March 17, 2003 IETF #56, SAN FRANCISCO14 Conclusion/Next Steps Conclusion –Request approval for draft as EAP working group item Next Steps –Close on some of the outstanding Issues on EAP Issues list –Catalog new issues from comments on mailing list

March 17, 2003 IETF #56, SAN FRANCISCO15 References “Compound Authentication Binding Problem”, Puthenkulam, J., Lortz, V., Palekar, A., Simon, D., puthenkulam-eap-binding-02.txthttp:// puthenkulam-eap-binding-02.txt “Man-in-the-Middle in Tunnelled Authentication Protocols”, Asokan, N.,Niemi, V., Nyberg, K.,

March 17, 2003 IETF #56, SAN FRANCISCO16 Backup

March 17, 2003 IETF #56, SAN FRANCISCO17 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

March 17, 2003 IETF #56, SAN FRANCISCO18 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 …. … Session Keys (Which method ?) Ciphered 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.