RFC: OpenConnect enhancements

[David Woodhouse]

On Sat, 2012-09-29 at 20:29 -0700, Kevin Cernekee wrote:
> David W,
> 
> I was wondering if I could get your opinion on a couple of items
> mentioned in TODO, contribute.xml, and nonroot.xml:
> 
> 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.

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.

We no longer use SecurID here, so this isn't a high priority for me.

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

> 3) "Better support for Cisco Secure Desktop" - were you thinking in
> terms of creating a fully open source CSD clone, bundling a script
> that merely spoofs the "good" response, or something else?

I don't really know, to be honest. Best phrased as 'do something that
makes me less queasy about the whole thing'.

Some kind of tool which lets you run it in isolation and work out what
it's doing when it goes wrong would be nice. It does go wrong quite
often. And yeah, being able to capture a 'good' response from a
successful run and then just post that in future would also be good.

I'm not sure a full clone makes a huge amount of sense, although it
would be cute. Perhaps the set of things it tests on Linux is small
enough that it *isn't* a completely insane proposition to implement and
keep up to date?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120930/e2975b55/attachment.bin>