[RFC/RFT] stoken and xmlconfig changes

[David Woodhouse]

On Sat, 2014-08-02 at 17:33 -0700, Kevin Cernekee wrote:
>  - Allow --token-secret to point to a file, so that SDTID XML tokens
> can be used directly.

For HOTP we have different requirements for file handling — we actually
need to be able to write the counter *back* to the file. So I'm not sure
your "read it from the file in main.c" is quite what we need.

I haven't quite worked out how to handle this.

HOTP and TOTP keys can be stored in a PSKC file (RFC6030), but we don't
really support that — we only support the key/counter being passed on
the command line in the form '--token-str 0123456789abcdef:22'.

For HOTP in particular though, we do *need* to be able to store the
current vaule of the counter. And the natural place to do that is in a
PSKC file — just bumping the value of the <Counter> field of the file
each time we generate a code.

Of course in some cases it *won't* be a PSKC file; something like
NetworkManager could have the HOTP token in our raw "key:counter"
format, and after authenticating it'll want to store it back to NM's
secret store in *that* form.

It's really annoying that oath-toolkit has two separate libraries
liboath (for generating/validating tokens), and libpskc (for
loading/parsing the files) with absolutely *no* coherency between the
two. There's no easy way to use the two together for the simple case of
"generate a token using the key described in the PSKC file, and update
the counter in the file as you do so."

So I'm still vacillating slightly about how to handle this in
OpenConnect. One option is to push the filename into libopenconnect and
have libopenconnect be responsible for updating the contents of the file
where necessary.

But then again, for the NetworkManager use case we're still going to
have to provide a library API for "give me back the counter so that I
can store it", because it won't be in a separate file.

So maybe we can leave *all* the PSKC handling in main.c, and just use
that simple API from the library. But then that means other GUI users
*can't* use our PSKC file support....

As I said, vacillating :)

Perhaps I should follow your lead and allow the PSKC XML to be passed in
as the "string". And then just add a function or callback for the
library to give it *back* again. The library will hand it back in the
same form (raw/PSKC) that it received it.

Of course, with a PSKC file the token-mode argument is redundant. The
PSKC file *specifies* the algorithm. And if you get a SDTID file that's
fairly unambiguous too. Should we look at making the token-mode
optional, or phasing it out entirely?

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