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.
