<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hello,<o:p></o:p></p>
<p class="MsoNormal">We have a situation where a Juniper Networks switch is configured in a ‘Server Fail Fallback’ mode. See:<o:p></o:p></p>
<p class="MsoNormal"><a href="http://www.juniper.net/techpubs/en_US/junos12.2/topics/task/configuration/802-1x-server-fail-fallback-cli.html">http://www.juniper.net/techpubs/en_US/junos12.2/topics/task/configuration/802-1x-server-fail-fallback-cli.html</a><o:p></o:p></p>
<p class="MsoNormal">In this mode, the switch sends an ‘EAP-Success’ to the device in response to just an ‘EAP-Request-ID’, without going through the full cycle authentication.<o:p></o:p></p>
<p class="MsoNormal">Roughly, the transaction looks like this:<o:p></o:p></p>
<p class="MsoNormal">1) Switch: ===> EAP-Request-ID<o:p></o:p></p>
<p class="MsoNormal">2) Device:===> EAP-Response-ID<o:p></o:p></p>
<p class="MsoNormal">3) Switch: ===> EAP-Success<o:p></o:p></p>
<p class="MsoNormal">4) Device goes to a FAILURE state<o:p></o:p></p>
<p class="MsoNormal">Notice there is no ‘EAP-Request-MD5/TLS’ coming in from the switch.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The device, running a wpa_supplicant (0.5-10) lands here:<o:p></o:p></p>
<p class="MsoNormal">-- eap.c: SM_STEP(EAP)<o:p></o:p></p>
<p class="MsoNormal">{<o:p></o:p></p>
<p class="MsoNormal">…<o:p></o:p></p>
<p class="MsoNormal"> else if (sm->methodState != METHOD_CONT &&<o:p></o:p></p>
<p class="MsoNormal"> ((sm->rxFailure &&<o:p></o:p></p>
<p class="MsoNormal"> sm->decision != DECISION_UNCOND_SUCC) ||<o:p></o:p></p>
<p class="MsoNormal"> (sm->rxSuccess && sm->decision == DECISION_FAIL &&<o:p></o:p></p>
<p class="MsoNormal"> (sm->selectedMethod != EAP_TYPE_LEAP ||<o:p></o:p></p>
<p class="MsoNormal"> sm->methodState != METHOD_MAY_CONT))) &&<o:p></o:p></p>
<p class="MsoNormal"> (sm->reqId == sm->lastId ||<o:p></o:p></p>
<p class="MsoNormal"> eap_success_workaround(sm, sm->reqId, sm->lastId)))<o:p></o:p></p>
<p class="MsoNormal">==> SM_ENTER(EAP, FAILURE);<o:p></o:p></p>
<p class="MsoNormal">..<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">At this point, sm->rxSuccess *is* true but sm->decision == DECISION_FAIL, due to initial condition. This effectively decides the final state transition, in this case, a FAILURE. rxReq is also false but ignored here.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Although eap.c appears to correctly implement the intent of rfc4137 (specifically page 8 Figure 3: “EAP Peer State Machine”) this obviously contradicts the expectations from the switch folks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Questions:<o:p></o:p></p>
<p class="MsoNormal">- Has anyone experienced this? If so, how was that handled?<o:p></o:p></p>
<p class="MsoNormal">- Is this a limitation of rfc 4137 or the implementation? (or both).<o:p></o:p></p>
<p class="MsoNormal">If answer is ‘no’ to all, I would like to know how this configuration can be supported.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Otherwise, I can share a patch for review, which addresses this scenario.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Appreciate your time,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Courier New";color:black">----------------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Courier New";color:black">Shahid Mahmood<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Courier New";color:black">Avaya Inc, Canada</span><o:p></o:p></p>
</div>
</body>
</html>