[jira] [Commented] (GUACAMOLE-1056) Add support for tracking the time drift between guacamole and TOTP-tokens

["Mike Jumper (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136238#comment-17136238 ] 

Mike Jumper commented on GUACAMOLE-1056:
----------------------------------------

I was initially wary of these proposed changes, but [RFC 6238 contains a recommendation for a similar mechanism to manage drift|https://tools.ietf.org/html/rfc6238#section-6]:

{quote}
h2. 6.  Resynchronization

Because of possible clock drifts between a client and a validation server, we RECOMMEND that the validator be set with a specific limit to the number of time steps a prover can be "out of synch" before being rejected.

This limit can be set both forward and backward from the calculated time step on receipt of the OTP value.  If the time step is 30 seconds as recommended, and the validator is set to only accept two time steps backward, then the maximum elapsed time drift would be around 89 seconds, i.e., 29 seconds in the calculated time step and 60 seconds for two backward time steps.

This would mean the validator could perform a validation against the current time and then two further validations for each backward step (for a total of 3 validations).  Upon successful validation, the validation server can record the detected clock drift for the token in terms of the number of time steps.  When a new OTP is received after this step, the validator can validate the OTP with the current timestamp adjusted with the recorded number of time-step clock drifts for the token.

Also, it is important to note that the longer a prover has not sent an OTP to a validation system, the longer (potentially) the accumulated clock drift between the prover and the verifier.  In such cases, the automatic resynchronization described above may not work if the drift exceeds the allowed threshold.  Additional authentication measures should be used to safely authenticate the prover and explicitly resynchronize the clock drift between the prover and the validator.
{quote}

Given the above, I think the idea is OK as long as the maximum allowed drift is configurable.

> Add support for tracking the time drift between guacamole and TOTP-tokens
> -------------------------------------------------------------------------
>
>                 Key: GUACAMOLE-1056
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1056
>             Project: Guacamole
>          Issue Type: Improvement
>          Components: guacamole-auth-totp
>            Reporter: Stefan
>            Priority: Minor
>
> Tokens/Display cards which generate codes directly on the device have an internal clock. According our investigates it seams to be normal that a time drift of 2 second per week seems to be in a common range. At some point the time drift of these token is to high so the TOTP- extensions rejects the generated codes. Because it is not possible to correct the on an easy way, we will add a tracking of this time drift.
> We added a new attribute for storing the value of the time drift next to the TOTP-Key. The module will accept 3 codes, one previous, one on time and one in the future. Depending on the accepted code the value will be decremented (previous) or incremented (future) or unchanged (on time). The new value will be used to compensate the timedrift on the next login.
> The changed code will follow the next days.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)