RFC 2284bis Open Issues

1. RFC 2284bis Open Issues http://www.drizzle.com/~aboba/EAP/eapissues.html http://www.levkowetz.com/ietf/drafts/eap

2. Issue Statistics • 30 issues filed and solved since December • Rate 1 issue per every 3 days (!) • During the last month every 2.5 days (!!) • WG has been very active wrt 2284bis in 2003 • 6 rejects out of 30 • Issue rejection rate 20% (bad sign) • During the last month 66% (good sign)

3. Recent Issues

4. Believed Closed? • 74 - Treatment of MICs not clear • Resolution: • Methods can silently discard invalid messages (peer and authenticator) • Add an appendix to discuss per-packet vs. per-fragment • Rest is method specific • 91, 92 - Various errors in definitions • Resolution: Clarified text • 94, 96 - Is EAP a lockstep protocol? • Resolution: Can not send a new request until old one answered • Also applies to Notification, Success, Failure (!) • RFC 2869bis also clarified

5. Open Issues

6. 80 - Success indications and policy • Problem: • Is satisfied policy enough or do we need a SUCCESS packet? • Arguments: • A SUCCESS packet might never come if its lost • OTOH, alternative indications have already been discouraged • If no sequences, then its easy to use method success indications • Key synchronization may depend on SUCCESS • Resolution: • (1) Require a SUCCESS packet always • Have to rerun if the SUCCESS packet is lost • (2) Don’t require a SUCCESS packet • Security effects? But SUCCESS packet’s aren’t authenticated anyway... • (3) Require a SUCCESS packet unless you had an alternative success indication • E.g. mutual authentication. Without sequences, there’d be no legal way to fail after this

7. 97 - Strict mode • Problem: • Should a method be able to disable "other inputs" while working? • Type (sequences etc) • Code (success, failure) • Arguments: • Disabling useful or not? Full Denial-of-Service protection not achievable? • Many implementations do this, but built into the EAP MUX, not method specific • Resolution: 1) No strict mode 2) Limited strict mode, in the state machine 3) Limited strict mode, method specific • Methods may to go into "strict mode” where state machine discards other inputs • RFC 2284 methods do not use strict mode 4) General filters

8. 97 (continued) -Related Notification Issue • Problem: • Are Notifications used by RFC 2284 methods? • Are implementers doing this? • Arguments: • Is it necessary to specify which methods provide Notifications? • Strict mode and notifications do not work together • If peer is strict and authenticator sends a Notification => hang • Resolution: • Allow notifications to be used, but not mandate them for specific methods? • State the limitation for strict mode in the document

9. 87 - Type change during method(related to sequences) • Problem: • Can you change to a new method in the middle of another method? • Arguments: • Related to the question of sequences. Useful or not? • Current implementations would hang • Plans for support in implementations? • RFC 2284 forbids this or not? • Non-authentication methods in scope of the WG or not? • Some vendors are probably going to find such methods useful • EAP has already a lot of interoperability issues, this would add to them • Desire to avoid the kitchen-sink protocol syndrome; EAP is for authentication; schedule pressure for 2284bis

10. 87 (continued) • Resolution: • A single authentication method, Identity, Notification can be sequenced • MUST NOT/SHOULD NOT do multiple authentication methods • Should we explain what happens when going against the SHOULD NOT?

11. 87 and Sequences -SHOULD NOT vs. MUST NOT • SHOULD NOT + Allows the use of sequences in special cases • MUST NOT + Eliminates the possibility of interoperability problems + Eliminates the question of binding problem in 2284 + Simplifies the state machine (Tunnel methods could still allow sequences)