TEE: TLS Authentication Using EAP draft-nir-tls-eap-02.txt

1
TEETLS Authentication Using EAPdraft-nir-tls-ea
p-02.txt

• Yoav Nir
• Yaron Sheffer (presenter)
• Hannes Tschofenig
• Peter Gutmann
• IETF-70, Vancouver, Dec. 2007

2
Reminder

• A TLS Extension
• EAP transported within TLS handshake messages
• Finished message means both handshake and
  authentication are complete, and regular data
  can flow

3
Why This is a Good Idea

• EAP support in operating systems is constantly
  improving (802.11i, 802.1X etc.)
• EAP provides multiple methods for user auth in
  the enterprise environment
• PEAP variants, SecureID, and a bunch of
  experimental stuff
• IPR-related issues with password auth,
  unfortunately
• Potentially more general than GSS-API, which is
  typically only used for Kerberos
• TLS used in a new product category SSL VPNs
• Both clientless and thin clients
• Not standardized, yet
• EAP applicable to network access
  authentication, highly applicable to SSL VPNs
• Implement in the thin client if successful, move
  to OS infrastructure

4
Why Not at the Application Layer

• EAP transport would need to be standardized
• As well as EAP-TLS channel binding
• Do we want to allow the application access to
  raw credentials
• Ideally the OS provides the UI, possibly with a
  trusted path
• Can enforce policy and select mechanisms better
  if auth done at same layer as TLS
• E.g. server auth in TLS, client auth in EAP
• Or anonymous in TLS, mutual auth in EAP
• APIs need to be extended to enable channel
  binding
• Per RFC 5056, the unencrypted Finished message(s)

5
Thank you!yaronf_at_checkpoint.com