1. RFC 2716bis Wednesday, July 12, 2006 Draft-simon-emu-rfc2716bis-02.txt Dan Simon Bernard Aboba IETF 66, Montreal, Canada

2. Document Status Changes from RFC 2716 -02 Section 2.5: Added EAP-TLS key hierarchy diagram, EMSK formula corrected (no longer broken into halves), added definition of Session- Id, clarified that PRF in [RFC4346] is used (e.g. not version specific). Section 2.6:Added mandatory-to-implement ciphersuites. Section 4.6: Added section on packet modification attacks. Changed TLS protocol references to [RFC4346] from [RFC2246], added reference to [RFC3280]. Section 2.5: Addition of key derivation formulas from Key Framework Appendix Section 4.1: Security claims Section 4.3: Certificate usage restrictions

3. Document Status (cont’d) Changes from RFC 2716 -00 Broadening of PPP-specific focus Reference Update (Normative vs. Informative) Section 2.4: Update of Identity Verification based on RFC 3748 advice (e.g. EAP-Identity/Response used only for routing). Section 2.6: Removal of lower layer ciphersuite and compression negotiation via TLS

4. Open Issues From Joe What if the altSubjectName extension is empty? Should the subjectName be used instead? How is the ID represented? What if there is more than one altSubjectName? Does order matter? From Sam Does multiple layers of negotiation with EAP-TLS introduce a vulnerability? Can a peer or server negotiate a weaker authentication method via TLS than via EAP? From Vidya Clarification of client certificate auth requirement. Server authentication failure and EAP-Failure packet. Addition of difference list from RFC 2716.

5. Open Issues (cont’d) Mandatory-to-Implement ciphersuites – 3DES/HMAC-SHA1 failed interoperability tests.  Privacy

6. Thinking About Privacy Transition assumptions Server is upgraded to support privacy first. Clients are gradually upgraded, so they are mixed legacy/upgraded clients. Privacy support is a binary switch on the upgraded client. If configured for privacy, client sends an anonymous identity (e.g. “anonymous@realm” or “@realm”) in the EAP-Response/Identity. Requirements for backward compatibility Upgraded client requiring privacy must fail to connect to a legacy server without privacy support. Upgraded client not configured for privacy must connect successfully to a legacy server without privacy support. Legacy client not configured for privacy must connect to an upgraded server without privacy being negotiated.

7. Recommended Approach Server always requests a client certificate Client not configured for privacy sends the client certificate. EAP-TLS conversation continues as normal. Client desiring privacy ignores the request. Server supporting privacy brings up the TLS channel, then asks requests a client certificate again. If client does not respond, server terminates the connection.

8. Evaluation Upgraded client not configured for privacy must connect successfully to a legacy server without privacy support. OK. Client answers the server certificate request, no change. Upgraded client requiring privacy must fail to connect to a legacy server without privacy support. OK. Client does not answer the initial server certificate request, legacy server will fail authentication. Legacy client not configured for privacy must connect to an upgraded server without privacy being negotiated. OK. Client answers the initial server certificate request, privacy not negotiated.

9. Next Steps Close the open issues, issue new version. Implementation survey Initial solicitation on the list garnered 4 responses Need info on interoperability issues, implemented features and ciphersuites. Potential for interoperability testing if needed.

10. Feedback?