[PATCH] Fix stoken support for Juniper VPN

[Daniel Lenski]

On Tue, Apr 10, 2018 at 2:26 PM, Andy Wang <dopey at moonteeth.com> wrote:
>
> Another follow up on this.  Is there something I should change to get
> this considered for inclusion?

I don't know if there are any developers who have access to a Juniper
VPN with RSA soft-token in order to test this but…

> On Wed, Dec 20, 2017 at 9:05 PM, Andy Wang <dopey at moonteeth.com> wrote:
> > On Wed, Nov 22, 2017 at 8:33 PM, Andy Wang <dopey at moonteeth.com> wrote:
> >> Allow using stoken code for frmLogin form type.
> >> Ensure stoken seed is properly prepared using block copied from Cisco
> >> VPN support in auth.c
> >>
> >> Signed-off-by: Andy Wang <dopey at moonteeth.com>
> >> ---
> >>  auth-juniper.c | 11 ++++++++++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/auth-juniper.c b/auth-juniper.c
> >> index 4b889d6..d818cf3 100644
> >> --- a/auth-juniper.c
> >> +++ b/auth-juniper.c
> >> @@ -77,7 +77,8 @@ static int oncp_can_gen_tokencode(struct openconnect_info *vpninfo,
> >>
> >>         if (strcmp(form->auth_id, "frmDefender") &&
> >>             strcmp(form->auth_id, "frmNextToken") &&
> >> -           strcmp(form->auth_id, "ftmTotpToken"))
> >> +           strcmp(form->auth_id, "ftmTotpToken") &&
> >> +           strcmp(form->auth_id, "frmLogin"))
> >>                 return -EINVAL;
> >>
> >>         return can_gen_tokencode(vpninfo, form, opt);

The concern here would be the frmLogin is the "default" login form for
Juniper. If there's a form field in frmLogin with type="password" …
how can openconnect distinguish whether this is the token field, or
the "normal" password field?

I believe most Juniper VPNs using RSA/stoken would use the token in a
secondary login form, with one of the form names that are already in
the source code.

There are a few reports on the mailing list of VPNs like yours where
the token-code goes in the "primary" password field, rather than a
specifically-identified "secondary" token field. No solution
implemented yet, but see David's proposal for a more general-purpose
solution here:
http://lists.infradead.org/pipermail/openconnect-devel/2017-August/004450.html

> >> @@ -570,6 +571,14 @@ int oncp_obtain_cookie(struct openconnect_info *vpninfo)
> >>         char *form_id = NULL;
> >>         int try_tncc = !!vpninfo->csd_wrapper;
> >>
> >> +#ifdef HAVE_LIBSTOKEN
> >> +        if (vpninfo->token_mode == OC_TOKEN_MODE_STOKEN) {
> >> +                ret = prepare_stoken(vpninfo);
> >> +                if (ret)
> >> +                        goto out;
> >> +        }
> >> +#endif
> >> +
> >>         resp_buf = buf_alloc();
> >>         if (buf_error(resp_buf))
> >>                 return -ENOMEM;
> >> --
> >> 2.14.3
> >>

This one seems like a simple oversight that would be required for
_any_ Juniper VPN to use stoken correctly. Thumbs up.

Dan