RFC 2716 bis Wednesday, July 12, 2006 Draft-simon-emu-rfc 2716 bis-02. txt Dan Simon Bernard Aboba IETF 66, Montreal, Canada
Document Status l Changes from RFC 2716 l -02 l l l 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 [RFC 4346] 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 [RFC 4346] from [RFC 2246], added reference to [RFC 3280]. -01 l l l Section 2. 5: Addition of key derivation formulas from Key Framework Appendix Section 4. 1: Security claims Section 4. 3: Certificate usage restrictions
Document Status (cont’d) l Changes from RFC 2716 l -00 l Broadening of PPP-specific focus l Reference Update (Normative vs. Informative) l Section 2. 4: Update of Identity Verification based on RFC 3748 advice (e. g. EAP-Identity/Response used only for routing). l Section 2. 6: Removal of lower layer ciphersuite and compression negotiation via TLS
Open Issues l l l From Joe l What if the alt. Subject. Name extension is empty? Should the subject. Name be used instead? How is the ID represented? l What if there is more than one alt. Subject. Name? Does order matter? From Sam l 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 l Clarification of client certificate auth requirement. l Server authentication failure and EAP-Failure packet. l Addition of difference list from RFC 2716.
Open Issues (cont’d) l l Mandatory-to-Implement ciphersuites – 3 DES/HMAC-SHA 1 failed interoperability tests. Privacy
Thinking About Privacy l Transition assumptions l Server is upgraded to support privacy first. l Clients are gradually upgraded, so they are mixed legacy/upgraded clients. l Privacy support is a binary switch on the upgraded client. l l If configured for privacy, client sends an anonymous identity (e. g. “anonymous@realm” or “@realm”) in the EAP-Response/Identity. Requirements for backward compatibility l Upgraded client requiring privacy must fail to connect to a legacy server without privacy support. l Upgraded client not configured for privacy must connect successfully to a legacy server without privacy support. l Legacy client not configured for privacy must connect to an upgraded server without privacy being negotiated.
Recommended Approach l Server always requests a client certificate l Client not configured for privacy sends the client certificate. l l EAP-TLS conversation continues as normal. Client desiring privacy ignores the request. l l Server supporting privacy brings up the TLS channel, then asks requests a client certificate again. If client does not respond, server terminates the connection.
Evaluation l l l Upgraded client not configured for privacy must connect successfully to a legacy server without privacy support. l OK. Client answers the server certificate request, no change. Upgraded client requiring privacy must fail to connect to a legacy server without privacy support. l 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. l OK. Client answers the initial server certificate request, privacy not negotiated.
Next Steps l l Close the open issues, issue new version. Implementation survey l l l Initial solicitation on the list garnered 4 responses Need info on interoperability issues, implemented features and ciphersuites. Potential for interoperability testing if needed.
Feedback?
Скачать презентацию RFC 2716 bis Wednesday July 12 2006 Draft-simon-emu-rfc
b31d9cd639b2767a1b5e5d486ae0cae2.ppt