oath-toolkit-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OATH-Toolkit-help] OATH Toolkit 2.6.0


From: Simon Josefsson
Subject: Re: [OATH-Toolkit-help] OATH Toolkit 2.6.0
Date: Tue, 19 May 2015 22:30:18 +0200
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)

David Woodhouse <address@hidden> writes:

> On Tue, 2015-05-19 at 21:35 +0200, Simon Josefsson wrote:
>> Would you be ok with doing this in a separate library, say, liboathpskc,
>> or something?  (Then I could move the liboath usersfile handling to that
>> library too, which is something I have been wanting to drop from
>> liboath.)
>
> Yes, absolutely. I think that makes sense.
>
>> > Somewhat more out of scope, but it would also be *really* neat to be
>> > able to import tokens from other things, like the Java monstrosity that
>> > is McAfee Pledge :)
>> 
>> If the higher library was a bit more generic, that would be fine.  Right
>> now it would feel ugly to add that to libpskc. 
>
> Agreed.
>
>>  It should probably not
>> be called liboathpskc then, but maybe something like libotp or lib2fa or
>> something.  I suspect there is some overlap with other existing projects
>> there though, but I'm happy to reinvent the wheel if there isn't a
>> suitable wheel around.
>
> I am not aware of a suitable existing wheel. It'd be great to have
> something higher-level that makes use of liboath/libpskc and perhaps
> also libstoken

So it is really a generic library for computing OTPs from various
sources (usersfile, PSKC, stoken, etc) then?

> — and I can donate my Yubikey OATH code from
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/yubikey.c
> under any reasonable licence that's required too.

Heh, nice snippet.  Talking to devices to get OTPs seems like a slightly
different use-case.  I'm not sure it makes sense to have both in the
same library -- I could see that you would want to compute OTPs on a
server and then you don't want all dependencies you have on a client.

Maybe the design goal is this:

libotp-client
- Generate OATH HOTP/TOTP(/OCRA?) from usersfile with liboath
- Generate SecurID token using libstoken
- Generate OATH HOTP/TOTP by talking to YubiKey NEO OATH applet over CCID

libotp-server
- Well, I guess all of the above except the CCID part...

I'm not sure the client/server split makes sense, but I can easily see a
CCID dependency for the library becoming an issue at some point.

Of course, a related use-case is to _validate_ (not compute) the OTP in
various formats in a library using a generic interface.

Can you tell me more how you would use this?  I'm not exactly sure how
you could generalize OTP-generation in a library that still makes sense
to an application.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]