1 / 15

IETF-70 EAP Method Update (EMU)

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)

hue
Download Presentation

IETF-70 EAP Method Update (EMU)

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. IETF-70EAP Method Update(EMU) Chair: Joe Salowey (jsalowey@cisco.com)

  2. 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)

  3. Charter Update

  4. 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

  5. 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.

  6. 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.

  7. 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.

  8. 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

  9. Tunnel Method Presentations

  10. Tunnel MethodRequirements

  11. 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

  12. 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 (REQUIRED) 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)

  13. 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:

  14. Charter Update

  15. 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

More Related