Protecting EAP the PIC approach ... PIC and PEAP - Ope

1

• The Insecurity of Tunnelled Authentication
  Protocols
• N. ASOKAN, VALTTERI NIEMI, KAISA NYBERG
• Nokia Research Center

2
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
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
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
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
Privacy requirements

• 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

7
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
• One-time passwords totally insecure if not
  protected. Typically tunnelled through TLS.
  Session keys derived from TLS (proprietary to
  PEAP or TTLS).
• EAP/SIM proprietary protection methods -
  network authentication, session key derivation
• A consistent method of session key derivation is
  desirable

8
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
Protecting EAP the PEAP approach
10
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
Protecting EAP the PIC approach
12
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 networks public key and link it to
  networks identity?
• How can user verify networks certificate?
• What about revocation?

13
PEAP/AKA- How it works
14
PIC EAP/AKA- How it works
15
PEAP/AKA- How it can fail
16
PIC EAP/AKA- How it can fail
17
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
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
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
General model of tunnelled authentication
Authentication Agent
Authentication Server
Front-end authenticator
Client
Tunneling protocol Server authenticated secure
tunnel establishment
secure tunnel
Authentication protocol Client 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

21
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
Why is cryptographic binding needed?

• To secure weak inner authentication protocols
  that use a weak key
• they MUST be used within a server authenticated
  tunnel, and
• 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
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.