[Swan-dev] xauth protocol and retransmits

[Andrew Cagney]

Forgive my use of IKEv2 terminology in what is an IKEv1 problem.  Here's my
understanding of XAUTH:

- initiator sends final SA exchange packet (in IKEv2 this is called AUTH so
I'm calling it that)
- responder establishes connection and replies with its own AUTH reply
- initiator receives AUTH and brings up its end

However with XAUTH, the following also happens:

- responder follows AUTH packet with an XAUTH password request
- initiator receives XAUTH request and sends back XAUTH response
- responder receives XAUTH response, performs authentication and then
responds with good/bad
- initiator finishes up

The problem is this violates one of the rules protocol design - the
responder has sent the initiator the back-to-back packets:

- AUTH reply (a normal re-transmit)
- XAUTH request (an extra bonus retransmit)

and either could get lost.  Consequently, if there is no response for the
XAUTH request, the responder re-transmits both.

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).

So the code I'm looking at to deal with this looks like:

bool resend_ike_v1_msg(struct state *st, const char *where)
{
    bool ret = send_or_resend_ike_msg(st, where, TRUE);
    if (st->st_state == STATE_XAUTH_R0 &&
        !LIN(POLICY_AGGRESSIVE, st->st_connection->policy)) {
        /* Only for Main mode + XAUTH */
        event_schedule_ms(EVENT_v1_SEND_XAUTH, EVENT_v1_SEND_XAUTH_DELAY,
st);
    }
    return ret;
}

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?).

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.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20171019/026136b1/attachment.html>