Problem with Compound Authentication Methods

1
Problem with Compound Authentication Methods
Jesse Walker Intel Corporation (
jesse.walker_at_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
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
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
EAP-TTLS Normal WLAN Authentication
Supplicant
Authenticator
Client
AP
AAA-H Server
TTLS Server
Wireless Station
EAP
802.1X
RADIUS
EAP/Identity Request
EAP/Identity Response (anonymous_at_realm)
Tunnel establishment
Tunnel Keys Derived
Tunnel Keys Derived
EAP Method inside Tunnel
EAP/Identity Request
EAP/Identity Response (user id_at_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
5
EAP-TTLS based WLAN session stealing
lt- Rogue AP/Client -gt
AAA-H Server
TTLS Server
Client
MitM
AP
EAP/Identity Request
EAP/Identity Response (anonymous_at_realm)
Tunnel establishment
Tunnel Keys Derived
Tunnel Keys Derived
EAP-Method in Tunnel
EAP/Identity Request
EAP/Identity Response (user id_at_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
6
PEAP/EAP-AKA WLAN Session Stealing
lt- UMTS Tower/ WLAN Terminal -gt
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

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

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 dont support ciphering
• Not protected
• Eg. EAP-MD5

FIXABLE
FIXABLE BY USAGE RESTRICTION
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

11
Man-in-the-middle attack failure with solution
lt- Rogue AP/Client -gt
AAA-H Server
TTLS Server
Client
MitM
AP
EAP/Identity Request
EAP/Identity Response (anonymous_at_realm)
TLS Session establishment
Tunnel Keys Derived
Tunnel Keys Derived
EAP-Method in TLS Protected Session
EAP/Identity Request
EAP/Identity Response (user id_at_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
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
  authentication methods
• secure avoid MitM attack
• non-invasive avoid imposing restrictions on
  strong methods

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

14
References

• Nokia Research Center
• http//eprint.iacr.org/2002/163/
• http//www.saunalahti.fi/asokan/research/mitm.htm
  l
• Intel Corporation, Microsoft
• http//www.ietf.org/internet-drafts/draft-puthenku
  lam-eap-binding-00.txt

15
Backup
16
Tunneled Methods Generic Model
Client
Authentication Agent
Authentication Server
Front-end authenticator
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
17
Sequenced Methods Generic Model
Client
Authentication Agent 1
Authentication Agent 2
Front-end authenticator
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
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.