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>
