RFC: OpenConnect enhancements

[Kevin Cernekee]

On Sun, Sep 30, 2012 at 12:13 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> 1) SecurID integration - is it your current line of thinking that
>> SecurID tokencode input should just be handled via "--passwd-on-stdin"
>> (possibly autogenerated by an external program), or did you still want
>> to explore the idea of adding the tokencode calculation right into
>> OpenConnect?
>
> The --passwd-on-stdin option doesn't work for that. Sometimes, SecurID
> authentication will ask you for *two* codes in succession, and there's
> also a delay between the program being spawned and the SecurID code
> being required. That could be a long time if it's waiting for the user
> to accept an unknown SSL certificate, for example.

OK.  I think there are at least a couple of different cases to cover here:

1) Base case - manual entry (no OTP, or no SW token).  Very common.

2) Software token - enter a single tokencode and then log on.  Very common.

3) Enter two tokencodes - clocks have drifted enough that the server
wants to resync, so it asks for a second tokencode.  Relatively
uncommon, but it happens.

4) Tokencode rejected (for whatever reason) - try again.

5) New token activation/replacement - rare but complicated:

Set your software token PIN to 0000 (!) and enter tokencode
Enter next tokencode
Do you want to enter your own PIN? y/n

No:

Are you prepared to accept a system-generated PIN? y/n
[...]

Yes:

Enter your new PIN
Reenter PIN


I haven't really paid enough attention to notice whether the VPN
client has enough information to distinguish #3-#5.  What I do know is
that the text prompts are configurable at the gateway side, and might
show up in different languages, and could vary based on the type or
version of gateway equipment.

Another consideration is that too many failed attempts will probably
get the user's account locked out.  So maybe #1-#2 can be covered
"well enough" with existing features (--passwd-on-stdin, assuming
there are no hiccups like unrecognized SSL certs).  #3 could benefit
from extra logic in OpenConnect (maybe scanning for "NEXT" in the
prompt string?), and #4-#5 should always be done by hand.

> I'd really like to see a proper implementation of the SecurID algorithm
> in a (separate) library. We know how the old 64-bit one works, and it
> really shouldn't be that hard to work out how the new 128-bit AES-based
> one works either. Then hook it in to OpenConnect to generate a code when
> needed.

Any preferences on how to handle:

a) Configuration - if there is an external tokencode generator program
that stores the token info in the user's home directory, do you want
OpenConnect to be able to read the existing rc file?  Or should the
token seed be provided to OpenConnect directly?

b) Distribution - assuming the algorithm is only ~1000 lines or so,
would you prefer to treat it as an external package, or just copy it
into the tree?

c) Protection of the seed and/or PIN, when stored locally?

>> 2) lwIP SOCKS proxy - do you think it is a good idea to add David
>> Edmondson's ocproxy/ocvpn (or a reasonable facsimile) to the main
>> OpenConnect repo, possibly under a contrib/ directory?  Or is this
>> better off living as a separate project?
>
> It's not OpenConnect-specific, so I think I'd prefer it to be in a
> separate repository. It'd be good to get vpnc and other clients working
> with it at some point. But definitely we should document its use and
> link to it from the OpenConnect web site.

I spent some time hacking on it today, and posted the changes here:

https://github.com/cernekee/ocproxy/commits/master

This now seems to work reasonably well with Dante, e.g. "socksify
telnet foo.somedomain.com".  Since ocproxy only passes TCP, I told
Dante to fake out gethostbyname(), and just pass the hostname string
in the SOCKS connection request instead.

tsocks and Opera were both able to connect through the proxy, but they
ran their DNS lookups locally, so addressing internal hosts by name
was problematic.

I am still concerned about memory usage, which keeps growing with each
connection.  Maybe the thread startup/teardown should work from a
fixed "pool" like Apache does; currently it is dynamic.