1 / 12

EAP-TTLS draft-funk-eap-ttls-v0-02.txt draft-hanna-eap-ttls-agility-00.txt

EAP-TTLS draft-funk-eap-ttls-v0-02.txt draft-hanna-eap-ttls-agility-00.txt. emu wg, IETF 70 Steve Hanna, shanna@juniper.net. EAP-TTLS. TLS-based tunneled EAP method Phase 1: like EAP-TLS Phase 2: AVP exchange Supports Tunneled authentication via many methods

smithtjulie
Download Presentation

EAP-TTLS draft-funk-eap-ttls-v0-02.txt draft-hanna-eap-ttls-agility-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EAP-TTLSdraft-funk-eap-ttls-v0-02.txtdraft-hanna-eap-ttls-agility-00.txtEAP-TTLSdraft-funk-eap-ttls-v0-02.txtdraft-hanna-eap-ttls-agility-00.txt emu wg, IETF 70 Steve Hanna, shanna@juniper.net

  2. EAP-TTLS • TLS-based tunneled EAP method • Phase 1: like EAP-TLS • Phase 2: AVP exchange • Supports • Tunneled authentication via many methods • Multiple forms of authentication • Endpoint integrity checks • Other extensions • Documented in Internet-Drafts since 2001 • Widely implemented and deployed (eduroam, etc.) • Cited by SDOs like WiMAX & 3GPP • Heading for RFC status EAP-TTLS for IETF EMU WG

  3. EAP-TTLS AVPs • Diameter AVP format • 32-bit type, 24-bit length • M bit for Mandatory to support • V bit and Vendor-ID for vendor-specific AVPs • RADIUS and Diameter attributes carry over • Easy to integrate with RADIUS servers • Can translate AVPs into RADIUS packets • Easy to tunnel existing EAP methods • Easy to tunnel non-EAP authentication • Easy to add new capabilities EAP-TTLS for IETF EMU WG

  4. Changes in eap-ttls-v0-02 • Added IANA Considerations • Updated references • Minor clarifications in response to reviews EAP-TTLS for IETF EMU WG

  5. eap-ttls-agility-00 • Optional AVPs for use with EAP-TTLS • Provide • Cryptographic algorithm agility • Cryptographic binding of inner and outer auth • Intermediate key confirmation • Protected results EAP-TTLS for IETF EMU WG

  6. Cryptographic Algorithm Agility • EAP-TTLSv0 already fairly agile • Uses TLS ciphersuite negotiation • But MSK and EMSK computation algorithm always uses TLS 1.1 PRF (based on SHA-1 and MD5) • Solution • New MSK-Computation AVP to negotiate alternative MSK and EMSK computation algorithms • New MSK and EMSK computation algorithm (“Mixed”) • Uses TLS PRF (negotiable in TLS 1.2) • Based on new Composite Key, which mixes in MSKs exported by inner authentications EAP-TTLS for IETF EMU WG

  7. Cryptographic Binding ofInner and Outer Authentications • Protect against MITM attacks like [Asokan] • Mixed MSK computation gives some protection • But only after EAP authentication completed, so... • Key-Confirmation-Option AVP • Negotiates use of Key-Confirmation AVP • Key-Confirmation AVP • Server MAY send any time, MUST send at end • Server sends POP for Composite Key • Client responds with similar POP EAP-TTLS for IETF EMU WG

  8. Secure Completion • Ensure secure completion of handshake • Detect truncation attacks • Detect forged EAP-Success or EAP-Failure • Secure-Completion-Option AVP • Negotiates use of Secure Completion • TTLS-Success and TTLS-Failure AVPs • Final exchange WITHIN tunnel EAP-TTLS for IETF EMU WG

  9. Evaluation Against Requirements • Transport of encrypted password for support of legacy password databases: YES 2. Mutual authentication (specifically authentication of the server): YES 3. Resistance to offline dictionary attacks, man-in-the-middle attacks: YES 4. Compliance with RFC 3748, RFC 4017 and EAP keying (including EMSK and MSK generation): YES 5. Peer identity confidentiality: YES EAP-TTLS for IETF EMU WG

  10. Evaluation Against Requirements 6. Crypto agility and ciphersuite negotiation: YES w TLS 1.2 7. Session resumption: YES 8. Fragmentation and reassembly: YES 9. Cryptographic binding: YES 10. Password/PIN change: YES when authentication method supports EAP-TTLS for IETF EMU WG

  11. Evaluation Against Requirements 11. Transport Channel binding data: Can support with new AVPs 12. Protected result indication: YES 13. Support for certificate validation protocols: YES w TLS CertStatus extn 14. Extension mechanism: YES EAP-TTLS for IETF EMU WG

  12. Summary • EAP-TTLS • Well-established EAP method • Specified in Internet-Drafts since 2001 • Widely implemented • Used by other standards bodies • No known substantial IPR problems • Meets all stated requirements • Easy to integrate with RADIUS servers • Offers many other features • Tunneled authentication via many methods • Multiple forms of authentication • Endpoint integrity checks (for NEA) EAP-TTLS for IETF EMU WG

More Related