1 © nokia mitm.ppt (v0.2) / 6-nov-02 / kaisa nyberg (nrc/mnw), n.asokan (nrc/com) the insecurity of...
TRANSCRIPT
1 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
The Insecurity of Tunnelled Authentication Protocols
N. ASOKAN, VALTTERI NIEMI, KAISA NYBERG
Nokia Research Center
2 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Remote Authentication Methods
• Two network access scenarios•Subscription based – there is a home network
•Alternative access based – there is no home network
In both cases the local authentication agent (e.g., AAAL) contacts some back-end authentication server to verify authenticity of mobile client
3 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Remote Authentication Methods
• Two cryptographic scenarios•Public key based •Secret key based
In both cases authenticity of mobile client is based on some secrets it has
4 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Remote Authentication Methods
• At least two session key scenarios•Session credentials for mobile client – goal is service level session security, or session connection security with a different party
•Session connection security, e.g., communication security in link, transport and/or network layer
•…
In all cases session keys are derived as a result of successful authentication between mobile client and an authentication agent
5 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Remote Authentication Methods - EAP
• Extensible Authentication Protocol (EAPblack boxeneral protocol framework that supports
• multiple authentication mechanisms • allows a back-end server to implement the actual mechanism
• authenticator simply passes authentication signaling through
• EAP was initially designed for use with PPP network access• But has been adapted by for many types of access
authentication• WLAN (IEEE 802.1X), Bluetooth, …
• And even other applications• charging, authorization
• EAP consists of • several Request/Response pairs; Requests are sent by network
• starts with EAP-Request/Identity sent by network• ends with EAP-Success or EAP-Failure sent by network
• But drawbacks of EAP prompted attempts to secure it
6 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
• Confidentiality of the identity of the mobile client on the air interface
• Prevention of linking between pairs of authentication messages involving the same mobile client
• Confidentiality against radio interface eavesdropping for data exchanged during the authentication protocol
Existing EAP based authentication methods fail…
Privacy requirements
7 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Different session key derivation methods
• Many legacy protocols for mobile client authentication• Encapsulated in EAP types
• EAP does not provide a standard way for deriving session keys that can be used for message authentication or encryption
• Examples: 1. One-time passwords – totally insecure if not
protected. Typically tunnelled through TLS. Session keys derived from TLS (proprietary to PEAP or TTLS).
2. EAP/SIM – proprietary protection methods - network authentication, session key derivation
A consistent method of session key derivation is desirable
8 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Protecting EAP- the PEAP approach
• Designed to protect any EAP method for client authentication.
• Provides client anonymity.• Backend server authenticated to client based
on public key of server.• Designed to provide mutual authentication.• EAP protocol runs within a protected TLS tunnel.• Designed to provide unified method for session
key derivation. • Session keys derived from TLS: e.g., protection
of subsequent session is based on the same secrets as the TLS tunnel.
9 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Protecting EAP – the PEAP approach
+-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ | | | |<======>| | | | EAP Conver |sation | | | | |<================================>| Backend | | Client | (over PPP, | 802.11, |etc.) | Server | | | | |<=======| | | | | NAS | Keys | | | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | EAP API | EAP API | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | EAP | | EAP | | Method | | Method | | | | | +-+-+-+-+-+ +-+-+-+-+-+
10 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Protecting EAP – the PIC approach
• Bootstraps IKE (JFK etc) from any EAP protocol – intended for remote access to VPN gateways
• Designed to protect any EAP method for client authentication
• especially password-based authentication
• Provides client anonymity
• Server authenticated to client based on public key of server.
• Provides unified method for credential transport
• Tunnel protocol: simplified unilateral version of ISAKMP (Layer 3)
• Session credentials for IPSec SA created by Back-end server transported to client through the protected tunnel
• A main design goal is not to require changes to legacy protocols
11 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Protecting EAP – the PIC approach
|====| |======================| |====| AS |=====| Back-End Auth Server | || |====| || |======================| || || || || || || |====| || || |== (Optional) ===| CA | || || |====| || || ========== || (optional | Client |===|| link) ========== || || || |====| |====| GW | |====|
12 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
PIC and PEAP - Open issues
• If it can be done, at what cost and under what assumptions on the use of PK?
•DoS attacks on access network?•DoS attacks on radio interface?•Additional roundtrip necessary?•How to obtain network’s public key and link it to network’s identity?
•How can user verify network’s certificate?•What about revocation?
13 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
PEAP/AKA- How it works
Secured by TLS tunnel
2. TLS(EAP-Response/AKA-challenge (RES))
Establishing a PEAP tunnel (server authenticated)
Terminal WLAN Server
HSS
2. TLS(EAP-Response/Identity (IMSI))
1. (…, EAP-Request/Identity message, …)
2a. MAP(Send_Auth Params: IMSI) [or DIAMETER]
2b. MAP (AKA authentication quintuplets)
3. TLS(EAP-Request/AKA-challenge (RAND, AUTN))
TLS-protocol based on network certificate
AP
WLAN_Master_session_keys (based on TLS tunnel keys)
14 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
PIC EAP/AKA- How it works
Secured by PIC SA
2. PIC(CREDENTIAL-REQUEST(PKCS-10 req), EAP-Response/AKA-challenge (RES))
2c. PKCS-10 req
Establishing a PIC SA (server authenticated)
UE Au HSS CA
2. PIC(EAP-Response/Identity (IMSI))
1. (…, EAP-Request/Identity message, …)
2a. MAP(Send_Auth Params: IMSI) [or DIAMETER]
2b. MAP (AKA authentication quintuplets) 3. PIC(EAP-Request/AKA-challenge (RAND, AUTN))
2d. cert 3. PIC(CREDENTIAL-RESPONSE(cert), EAP-Success)
15 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
PEAP/AKA- How it can fail
Secured by TLS tunnel (only server authenticated)
2. TLS(EAP-Response/AKA-challenge (RES))
Establishing a PEAP tunnel (server authenticated)
Terminal WLAN Server
HSS
2. TLS(EAP-Response/Identity (IMSI))
1. (…, EAP-Request/Identity message, …)
2a. MAP(Send_Auth Params: IMSI) [or DIAMETER]
2b. MAP (AKA authentication quintuplets) 3. TLS(EAP-Request/AKA-challenge (RAND, AUTN))
MitM
3. RAND, AUTN
2. RES
TLS-protocol based on network certificate
IMSI_Request
IMSI
AP
WLAN_Master_session_keys (based on TLS tunnel keys)
Stolen WLAN link
16 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
PIC EAP/AKA- How it can fail
Secured by PIC SA (only server authenticated)
2. PIC(CREDENTIAL-REQUEST(PKCS-10 req), EAP-Response/AKA-challenge (RES))
2c. PKCS-10 req
Establishing a PIC SA (server authenticated)
UE Au HSS CA
2. PIC(EAP-Response/Identity (IMSI))
1. (…, EAP-Request/Identity message, …)
2a. MAP(Send_Auth Params: IMSI) [or DIAMETER]
2b. MAP (AKA authentication quintuplets) 3. PIC(EAP-Request/AKA-challenge (RAND, AUTN))
2d. cert 3. PIC(CREDENTIAL-RESPONSE(cert), EAP-Success)
MitM
RAND, AUTN
RES
IMSI Request
IMSI
17 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Analysis of the problem• Outer protocol (e.g., TLS) and inner protocol (e.g., EAP AKA) are
both secure! It is the composition that is insecure.• Inner protocol is a legacy remote client authentication protocol
(EAP/SIM, EAP/AKA) –typically used also without TLS tunnelling, also without ANY tunnelling
• MitM can initiate untunnelled authentication with the client: e.g., set up a false cellular base station to ask for IMSI and then for RES.
• Even if inner protocol is used exclusively in tunnelled mode, authentication of tunnel relies solely upon client.
• E.g., user may accept an unknown certificate! This is not acceptable to network operators.
• Session keys are derived from tunnel protocol only (e.g., TLS Master Key generated using tunnel protocol; same key as used to create tunnel).
• Keys derived in inner protocol (e.g., AKA Master Keys) are not used.
18 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Impacts of failure
• Under passive (eavesdropping) attacks:• Tunnelling provides some protection of user identity
– however link-layer addresses are revealed anyway!
• Under active (man-in-the-middle) attacks: Tunnelled authentication protocols
• fail to protect user identity (e.g., IMSI in EAP AKA or EAP SIM)
• allow attacker to masquerade as the victim (e.g., and hijack her WLAN link)
• risk link confidentiality • with EAP SIM as auth. protocol, are weaker than
plain EAP SIM • with EAP AKA as auth. protocol, are much weaker
than plain EAP/AKA
19 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Conditions for failure
• A tunnelled authentication protocol is insecure unless
• if the outer protocol does perform mutual authentication
• not true for PEAP in server-authenticated mode, or PIC.
• if the keys used for a particular subscription are not used in the legacy untunnelled mode (even if other subscriptions may be used in this mode)
• not true for integrated terminals (e.g., GPRS/WLAN)
• not true when the same general purpose smartcard (SIM/UICC) is used with separate single-purpose terminals (e.g., WLAN, GPRS)
20 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
General model of tunnelled authentication
• Terminology
• tunnel endpoint is authentication ”agent”
• authentication protocol endpoint is authentication ”server”
• ”front-end” authenticator is a pass-through server
• Agent and Server may be co-located
ClientAuthentication
AgentAuthentication
Server
Tunneling protocolServer authenticated
secure tunnel establishment
Authentication protocolClient authentication
secure tunnel
Front-endauthenticator
21 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Proposed solution• Create cryptographic binding between tunnelling protocol and
authentication protocol:
METHOD 1: Use a one-way function to compute session keys from tunnel secrets (e.g.TLS master key) and auth. protocol secrets (e.g. IK,CK).
METHOD 2: Compute a MAC over client-specific text (e.g, challenge, PIC credential request, …), using a MAC key derived as session key in Method 1. MAC is verified by agent or server. Now tunnel is secure for handling of session keys or credentials.
• In both methods, auth. protocol secrets must be sent from server to agent (or tunnel secrets must be sent from agent to server)
• Both methods rely on the authentication protocol producing a session key as well (under some assumptions, also possible to use a long-term key)
22 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Why is cryptographic binding needed?
• To secure weak inner authentication protocols that use a weak key1. they MUST be used within a server authenticated tunnel,
and2. they MUST NOT be used outside such a tunnel
• Assumption #2 drastically reduces use of legacy auth. protocols• it MUST NOT be imposed on protocols that use strong keys
• Tunneling protocols (PEAP, POTLS, PIC etc.) address issue #1• But they treat the inner protocol as a blackbox (any EAP type)
• Therefore tunnelling protocols SHOULD allow optional cryptographic binding of the outer and inner protocols
• This allows tunnelling protocols to• generic: handle both weak and strong authentication
protocols• secure: avoid MitM attack• non-invasive: NOT have to impose unnecessary restrictions
on good protocols
23 © NOKIA MitM.PPT (v0.2) / 6-Nov-02 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM)
Conclusions• Composing two secure protocols may result in an
insecure protocol• Using tunnelling to “improve” a remote
authentication protocol is very common• Known vulnerable combinations:
•HTTP Digest authentication and TLS•PEAP and any EAP subtype•PIC and any EAP subtype•POTLS (v0.0) and any EAP subtype•… (obviously not limited to the examples in these slides)
• The proposed solutions can be used to fix the problem
•the exact fix needs to be tailored to the specific protocols.