Re: [OATH-Toolkit-help] PAM unable to resolve symbol: pam_sm_setcred

[Simon Josefsson]

Rien Broekstra <address@hidden> writes:

> On 4/29/2011 9:33 AM, Simon Josefsson wrote:
>
> [snip: totp validation approach]
>
>> Sounds fine to me.  We could call oath_totp_validate twice, first for
>> the last_otp and then for the current OTP, and compare the return code
>> and make sure that if last_otp is within the search window, it is older
>> than the current OTP.  But we could also create a more flexible
>> oath_totp_validate() variant that takes the last_otp function and does
>> everything in one go.
>
> I think I'd prefer the latter.

I had a look at implementing the former approach first, and it didn't
work: the return code is the absolute value of the window position, so
there is no way to know which one is older without knowing the sign.
Maybe we want to change the APIs to fix that anyway though...

>> This discussion has been good, now it is only a A Small Matter Of
>> Programming...
>
> I can give it a try if you want?

Please do, I've ran out of time for this today.  I ran into a small
issue when I started to work on the second approach.  Look at today's
APIs:

int
oath_totp_validate (const char *secret,
                    size_t secret_length,
                    time_t now,
                    unsigned time_step_size,
                    time_t start_offset,
                    size_t window,
                    const char *otp)
int
oath_totp_validate_callback (const char *secret,
                             size_t secret_length,
                             time_t now,
                             unsigned time_step_size,
                             time_t start_offset,
                             unsigned digits,
                             size_t window,
                             oath_validate_strcmp_function strcmp_otp,
                             void *strcmp_handle)

Adding a new one based on the former is easy, like this:

int
oath_totp_validate_last (const char *secret,
                    size_t secret_length,
                    time_t now,
                    unsigned time_step_size,
                    time_t start_offset,
                    size_t window,
                    const char *prev_otp,
                    const char *otp)

However I couldn't think of a simple way to resolve the second
interface.  I'd appreciate your additional ideas here...

Maybe it is easier to fix the API to return sign of the window position
as well (separate parameter), and use my former idea.

Back in my head has been to split out the HMAC secret from the
validation functions too: I'd like to have a callback interface for
that, so applications can use a HSM via PKCS#11 to store the HMAC
secrets.  This may have some impact on which validation algorithm we use
too, but I'm not sure of the details.

/Simon