1 / 7

EAP State Machines (draft-ietf-eap-statemachine-04)

EAP State Machines (draft-ietf-eap-statemachine-04). John Vollbrecht, Pasi Eronen, Nick Petroni, Yoshihiro Ohba. Status. 2nd WGLC ended on March 8th Minor changes incorporated in -03 IETF last call ended on May 13th Approved as informational by IESG on June 1st. Status, part 2.

annanderson
Download Presentation

EAP State Machines (draft-ietf-eap-statemachine-04)

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. EAP State Machines(draft-ietf-eap-statemachine-04) John Vollbrecht, Pasi Eronen, Nick Petroni, Yoshihiro Ohba EAP WG, IETF 60

  2. Status • 2nd WGLC ended on March 8th • Minor changes incorporated in -03 • IETF last call ended on May 13th • Approved as informational by IESG on June 1st EAP WG, IETF 60

  3. Status, part 2 • Since then, several issues contributed by Florent Bersani • 247 and 251: Editorial comments • Handled in –04 • 250: Technical comments and requests for clarification • Some things clarified in –04 • Comment #12 included in 251 • 251: next slide… EAP WG, IETF 60

  4. Issue 251 part 1: 1X-REV • 1X-REV sends canned success/failure if port status is administratively changed • These are not really part of an EAP conversation, but use 802.1X EAPOL frames • Perhaps using eapolLogoff would have been better, but too late to change now • Conclusion: no action required? EAP WG, IETF 60

  5. Issue 251 part 2: peer • Success and Failure following EAP Identity Request/Response exchange are allowed in RFC3748 • And even mentioned explicitly in an example about guest access • The peer can, of course, have a policy requiring authentication of the server • The state machine allows this • Conclusion: no changes required? EAP WG, IETF 60

  6. Issue 251 part 3: authenticator • Authenticator state machine does not explicitly prohibit canned messages. • Proposed change: “Policy.getDecision MUST comply with RFC3748 restrictions about canned Success and Failure messages.” • There’s similar text at Policy.getNextMethod about method sequences • This could be viewed as a minor clarification that can be done at AUTH48 EAP WG, IETF 60

  7. Next steps • Publish this as RFC • PostScript/PDF version requires some work by the authors EAP WG, IETF 60

More Related