1. IETF-70 EAP Method Update (EMU)
Chair: Joe Salowey

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 Method Requirements

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
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 ) (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