TEE: TLS Authentication Using EAP draft-nir-tls-eap-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)

Thank you!