Eap STate machin E d Esign tea M

Eap STate machin. E d. Esign tea. M (ESTEEM) Draft http: //www. ietf. org/internet-drafts/draft-ietf-eap-esteem-00. txt Team members Bernard Aboba, Jari Arkko, Paul Congdon, Rodrigo Garces, Robert Moskowitz, Yoshihiro Ohba, Bryan Payne, Nick Petroni, Joseph Salowey, John Vollbrecht, Jesse Walker, Glen Zorn Goal Fix state machine so that it is compatible with IEEE 802. 1 aa and RFC 2869 Bis, and that it correctly handles optional identity exchange, method sequences, re-authentication, retransmission, . . . Operation Position papers, weekly conferences, minutes, esteem draft, input to issues and state machine drafts

ESTEEM Position Papers • Issues with the EAP State Machine • Comparison of EAP state machines with RFC 2284 bis Yoshihiro Ohba Bryan Payne, Nick Petroni • EAP State Machine Completeness Jari Arkko • When can notif/nack/. . . be sent? Bernard Aboba • Communication between the Method and EAP layer • EAP switch and multiple methods Bernard Aboba John Vollbrecht

ESTEEM Decisions Basic issues – Allow notification in any state; can’t be Nakked – EAP layer (not method) handles duplicate detection and id numbers (#25) – Follow IEEE 802. 1 aa format in state machine definition Identity requests – Identity request/response can only appear between methods – Our preference is that identity requests be optional. – Leaning towards making Nak disallowed for Identity Request Success and failure indications – – – If an authenticated indication exists, should not believe alternative indications Link-layer indications provided to EAP MUST be processed (#2) Unprotected success indications are only accepted after method is complete (#2) Peers should be able to accept Failure in unauthenticated state Authenticated indications require support for sequences or tunnels (#10) Sequences – Methods can’t be executed in parallel; Nak if received – No pre-negotiation of method sequencing capability, just Nak afterwards (#7)