IETF-70 EAP Method Update (EMU) Chair: Joe Salowey (jsalowey@cisco.com)

Agenda 1. Administrivia (5 min) 2. Draft updates (10 min) 3. Charter Discussion (40 min) 4. Tunneling Method presentations (30 min) - EAP-TTLS (15 min) (Steve Hanna) - EAP-FAST (15 min) (Gene Chang) 5. Tunneling methods Requirements Discussion (60 min)

Charter Update

Charter Revision Summary Add charter item for tunnel EAP method Modify password based item to make use of tunnel method Modify "enhanced TLS" item to focus on adding channel bindings to a TLS based mechanism Updated milestones Include requirements draft milestone

Charter Update - A mechanism to support extensible communication within a TLS protected tunnel to support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and to support additional inner authentication mechanisms. This mechanism must be capable of supporting channel bindings.

Charter Update Cont. - Enhanced functionality to enable a TLS-based EAP method to support channel bindings. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. This item should not generate a separate method rather it should be based on EAP-TLS or the TLS based tunnel method in preceding deliverable.

Charter Update Cont. - A mechanism that makes use of existing password databases such as AAA databases. This item will make use of the above tunnel method.

Charter Milestones Dec 2007 Submit Strong Shared Secret Mechanism to IESG Feb 2008 Tunnel Method requirements first draft submitted May 2008 Tunnel Method first draft submitted June 2008 Submit Password method extensions to tunnel method June 2008 Submit Extended TLS method extensions to tunnel method Mar 2009 Submit Tunnel Method to IESG Apr 2009 Submit Enhanced EAP-TLS to IESG Apr 2009 Submit Password based method to IESG

Tunnel Method Presentations

Tunnel Method Requirements

Requirements Areas 1. Changes to current requirements (required to meet 3748, 4017, eap keying etc.) 2. Tunneling EAP methods for authentication (eg, chaining, result indication, etc.) 3. Additional data that needs to be tunneled (channel binding, etc.) 4. Extensibility 5. Additional requirements for the tunnel itself

Requirements from Password Method 1. Transport of encrypted password for support of legacy password databases (REQUIRED) 2. Mutual authentication (specifically authentication of the server) (REQUIRED) 3. resistance to offline dictionary attacks, man-in-the-middle attacks 4. Compliance with RFC 3748, RFC 4017 and EAP keying (including EMSK and MSK generation) (REQUIRED) 5. Peer identity confidentiality (REQUIRED) 6. Crypto agility and ciphersuite negotiation (REQUIRED) 7. Session resumption (no password needed) (REQUIRED) 8. Fragmentation and reassembly (REQUIRED) 9. Cryptographic binding (REQUIRED if additional inner mechanisms are supported) 10. Password/PIN change (DESIRABLE) 11. Transport Channel binding data (REQUIRED) 12. Protected result indication (REQUIRED) 13. Support for certificate validation protocols (DESIRABLE) 14. Extension mechanism (in support of 10 - 12) (REQUIRED)

Charter Update All mechanisms standardized by this group must meet RFC 3748, RFC 4017, and EAP keying requirements (pending RFC status). This group is chartered to work on the following types of mechanisms:

Charter Update

Requirements TLS community review Privacy Protection of EAP headers Internationalization must be consistent with NAI, human typed passwords, and prompts. Consider errors and other indications. Constrained devices