Skip to content

Main EAP methods

EAP methods supporting key derivation.

EAP-TLS (RFC 5216)

  • establishes an TLS session
  • no actual payload within the TLS session supported; clients can only be authenticated through client certificate (or, theoretically, other TLS authentications)
  • client certificate send in cleartext - identity leaks to MITM
    • TODO: do implementations support client cert after renegotiation to protect client identity?

EAP-TTLS (RFC 5281)

  • EAP messages include fields for fragmentation, and a version field
  • establishes an TLS session
  • if authentication from TLS handshake wasn’t sufficient “phase 2” follows:
    • uses radius messages (AVPs, “attribute-value-pairs”)
    • Tunneled Authentication Protocols:
      • nested EAP: this time no key derivation is needed
      • CHAP PPP CHAP
        • MD5 challenge-response, requires plaintext password on server
      • MS-CHAP MS-CHAP
        • uses shorter challenges than v2
        • protocol supports both LM and NT responses
      • MS-CHAPv2
        • see EAP-MSCHAPv2 below for MSCHAPv2; password reset supported by the protocol here too
      • PAP
        • plaintext password(s)
        • multiple password prompts possible (e.g. HOTP/…)

EAP-PEAP

Protected EAP:

  • never became an RFC
  • PEAPv1 draft-josefsson-pppext-eap-tls-eap-05.txt
    • HTML-rendered old version of draft not available
  • PEAPv0 draft-kamath-pppext-peapv0
    • spec describes differences to PEAPv1; PEAPv0 seems to be Windows XP only?
    • uses method type 33? (to wrap TLVs ???)
  • PEAPv2 draft-josefsson-pppext-eap-tls-eap-10
    • not used; drafts 06..10 describe PEAPv2, 00..05 PEAPv1
    • would use TLV as inner protocol instead of EAP?
  • similar to TTLS, but always uses EAP as tunneled authentication protocol
  • as the specs are heavily outdated, they require outdated TLS ciphersuites
    • PEAPv1: TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA
    • PEAPv2: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    • one might even read it as “is required to allow TLS1.0”…

EAP-MSCHAPv2

MS-EAP-Authentication:

  • draft-kamath-pppext-eap-mschapv2-00.txt
    • HTML-rendered old version of draft not available
  • draft-kamath-pppext-eap-mschapv2
    • any important changes compared to -00 ?
  • type 26; type 29 “EAP-MSCHAP-V2” is not known by wpa_supplicant
  • based on MSCHAPv2
    • requires NT-Hash (MD4 of UCS-16) of password on server (also sufficient on client -> pass-the-hash attacks)
    • builds challenge as SHA1 hash over authenticator and peer challenges (random data) and username
    • pads NT-Hash to 21 bytes (appends 5 zero bytes) and split into 3 7-byte “keys”
    • “encrypts” challenge in 3 blocks (each 8 byte) with DES; each block with one key -> 24-byte Response
    • although challenges are documented as 16 octects, they are probably only 8 bytes hex-encoded
  • has protocol support to change expired passwords
  • key derivation in RFC 3079 ??
    • unclear whether/how EAP requirements are fulfilled.
  • example setup: freeradius -> winbindd -> AD

EAP-FAST (RFC 4851)

Flexible Authentication via Secure Tunneling:

  • similar to EAP-TTLS - uses (locally defined) TLVs for tunnel authentication (inspired by PEAPv2)
  • PAC: “Protected Access Credential”
  • see EAP-TEAP below for more details
  • EAP-FAST seems to be available in wpa_supplicant (network-manager), but EAP-TEAP not?

EAP-TEAP (RFC 7170)

  • TLV (inner (TLS protected) and outer (unprotected, only specific TLVs allowed))
    • EAP-Payload TLV for nested EAP (e.g. EAP-MSCHAPv2 or EAP-GTC)
    • Basic-Password-Auth TLVs for plaintext username + password (optional prompt)
    • PAC-TLV to provision PAC
    • PKCS#10 (CSR) TLV to request (-> PKCS#7 TLV as response?)
    • Trusted-Server-Root TLV ??
  • standard-tracks version of EAP-FAST
    • differences?
      • TLS >= 1.2
      • uses TLS key derive functions?
      • outer TLVs (before TLS session establishment to hint identities)
      • Basic password authentication on the TLV level
      • small differences in TLV types
      • Identity TLVs
  • PAC: “Protected Access Credential”
    • Three parts
      • PAC-Key: TLS master secret
      • PAC-Opaque: data the clients sents through SessionTicket to TLS server (server-encrypted+authenticated data: TLS master secret, client identity, …)
      • PAC-Info: optional meta data
        • lifetime (unix epoch, uint32_t… in 2014. wtf)
    • PAC-TLV sent by server: (re?)provision client
    • .pac Fileformat? unclear (probably a PAC TLV, but with or without header?)
  • servers must support TLS renegotiation
    • this allows initial connection without TLS SessionTicket / client certificate -> hide client identity
    • in protected connection: renegotiate with client cert (or SessionTicket - is this even possible?)
    • client support unclear

EAP-NOOB (RFC 9140)

Nimble Out-of-Band Authentication:

  • secure onboarding of certain IoT devices

EAP-PWD (RFC 5931)

  • uses Dragonfly handshake, similar to SAE (WPA3-PSK)
  • Password Preprocessing Methods
    • client needs to support preproccesing of whatever is stored serverside (plaintext password on server obviously allows for any preprocessing)
    • serverside data IS the relevant shared secret, whether hashed or not (-> pass the hash attacks)
    • RFC 8146 “Support for Salted Password Databases”