<div dir="ltr"><div><div>Forgive my use of IKEv2 terminology in what is an IKEv1 problem.  Here's my understanding of XAUTH:<br><br></div>- initiator sends final SA exchange packet (in IKEv2 this is called AUTH so I'm calling it that)<br></div>- responder establishes connection and replies with its own AUTH reply<br><div><div>- initiator receives AUTH and brings up its end</div><br><div>However with XAUTH, the following also happens:</div><div><br></div><div>- responder follows AUTH packet with an XAUTH password request</div><div>- initiator receives XAUTH request and sends back XAUTH response</div><div>- responder receives XAUTH response, performs authentication and then responds with good/bad</div><div>- initiator finishes up</div></div><div><br></div><div>The problem is this violates one of the rules protocol design - the responder has sent the initiator the back-to-back packets:<br></div><div><br></div><div>- AUTH reply (a normal re-transmit)<br></div><div>- XAUTH request (an extra bonus retransmit)<br></div><div><br></div><div>and either could get lost.  Consequently, if there is no response for the XAUTH request, the responder re-transmits both.</div><div><br></div><div>Is this analysis in the ballpark; and is this how the protocol should work (or should just the XAUTH request be re-transmitted leaving the initiator to trigger AUTH request if AUTH reply is lost - more like what IKEv2 would do).<br></div><div><br></div><div>So the code I'm looking at to deal with this looks like:<br></div><div><br>bool resend_ike_v1_msg(struct state *st, const char *where)<br>{<br>    bool ret = send_or_resend_ike_msg(st, where, TRUE);<br>    if (st->st_state == STATE_XAUTH_R0 &&<br>        !LIN(POLICY_AGGRESSIVE, st->st_connection->policy)) {<br>        /* Only for Main mode + XAUTH */<br>        event_schedule_ms(EVENT_v1_SEND_XAUTH, EVENT_v1_SEND_XAUTH_DELAY, st);<br>    }<br>    return ret;<br>}<br><br></div><div><div>where it sends out the AUTH reply (an st_event), and a short while later sends out an XAUTH request (an st_send_xauth_event, recent changes mean it is generated from scratch and doesn't replace the AUTH reply?).</div><div><br></div><div>With this, the problem I'm seeing is that when the initiator comes back with its XAUTH reply, the responder, in  xauth_launch_authent() needs to cancel both the RETRANSMIT and the SEND_XAUTH but it only cancels the first and only when PAM.  This lets SEND_XAUTH fire repeatedly and even after PAM finishes and the final reply sent, and its code uses change_state() to blungeon the state back to XAUTH_R0 resulting in much confusion.</div><div><br></div><div>Andrew<br></div></div></div>