Wrong otp response without fail count increase privacyidea 3.5.1

Question
,
1

Hello,

I have a strange problem with radius authentication from the PaloAlto GlobalProtect. Usually it works fine, but sometimes we have failed authentication with a reason wrong OTP. I am sure that the OTP is correct. Also, the failcount is not increasing in this case. If I put really wrong OTP then failcount increases.

In radius logs I can see that there are two radius requests from the PaloAlto with the same username and password - I guess this is because one request is sent for globalprotect portal and the second one for the globalprotect gateway. And the first request receives authentication accept, the second one receives authentication rejected. Time interval between these two requests is 4 seconds. Below is an example:

Thu Apr 1 10:36:07 2021 : Info: rlm_perl: state sent to privacyidea:
Thu Apr 1 10:36:07 2021 : rlm_perl: urlparam pass = mypin044399
Thu Apr 1 10:36:07 2021 : rlm_perl: urlparam user = myusername
Thu Apr 1 10:36:07 2021 : rlm_perl: urlparam client = 192.168.25.10
Thu Apr 1 10:36:07 2021 : Info: rlm_perl: Request timeout: 10
Thu Apr 1 10:36:07 2021 : Info: rlm_perl: Not verifying SSL certificate!
Thu Apr 1 10:36:08 2021 : Info: rlm_perl: elapsed time for privacyidea call: 6.335049
Thu Apr 1 10:36:08 2021 : rlm_perl: Content {“detail”: {“message”: “matching 1 tokens”, “otplen”: 6, “serial”: “TOTP000038DE”, “threadid”: 140067579815360, “type”: “totp”, "
Thu Apr 1 10:36:09 2021 : Info: rlm_perl: privacyIDEA access granted

Thu Apr 1 10:36:11 2021 : Info: rlm_perl: state sent to privacyidea:
Thu Apr 1 10:36:11 2021 : rlm_perl: urlparam pass = mypin044399
Thu Apr 1 10:36:11 2021 : rlm_perl: urlparam user = myusername
Thu Apr 1 10:36:11 2021 : rlm_perl: urlparam client = 192.168.25.10
Thu Apr 1 10:36:12 2021 : Info: rlm_perl: Request timeout: 10
Thu Apr 1 10:36:12 2021 : Info: rlm_perl: Not verifying SSL certificate!
Thu Apr 1 10:36:12 2021 : Info: rlm_perl: elapsed time for privacyidea call: 5.849115
Thu Apr 1 10:36:12 2021 : rlm_perl: Content {“detail”: {“message”: “wrong otp value”, “otplen”: 6, “serial”: “TOTP000038DE”, “threadid”: 140067579815360, “type”: “totp”}, “id”: 1, “jsonrpc”: “2.0”, “result”: {“status”: true, “value”: false}, “time”: 1617266172.7674997, “version”: “privacyIDEA 3.5.1”, “versionnumber”: “3.5.1”, “signature”:
Thu Apr 1 10:36:12 2021 : Info: rlm_perl: privacyIDEA Result status is true!
Thu Apr 1 10:36:12 2021 : Info: rlm_perl: privacyIDEA access denied
Thu Apr 1 10:36:12 2021 : Info: rlm_perl: return RLM_MODULE_REJECT
Thu Apr 1 10:36:21 2021 : Info: rlm_perl: elapsed time for privacyidea call: 9.401188
Thu Apr 1 10:36:21 2021 : rlm_perl: Content {“detail”: {“message”: “wrong otp value”, “otplen”: 6, “serial”: “TOTP000038DE”, “threadid”: 140067579815360, “type”: “totp”}, “id”: 1, “jsonrpc”: “2.0”, “result”: {“status”: true, “value”: false},
Thu Apr 1 10:36:21 2021 : Info: rlm_perl: privacyIDEA Result status is true!
Thu Apr 1 10:36:21 2021 : Info: rlm_perl: privacyIDEA access denied
Thu Apr 1 10:36:21 2021 : Info: rlm_perl: return RLM_MODULE_REJECT

So, first of all it is strange that for the same username/password the privacyidea responds with accept and reject during the 4 second interval, is it a feature and can be configured somehow?
And the second question is about why privacyidea doesn’t increase fail count for such rejects.

2

Tested from the shell with command http --verify no POST https://localhost/validate/check
and it is clear, that if I check the same OTP for a second time then I receive a reject with a wrong OTP, even if this OTP is still correct.
Not sure if this is a correct behavior or some bug. And looks like a bug that fail count doesn’t increase

3

Read RFC6238. For the understanding when and OTP value is valid and when not.
pro tip: One Time Password indicates, that it can only be used once.

Your PaloAlto seems to be configured with 5 seconds and 3 retries which is the default but a terrible idea.
You misperception regarding the failcounter seems to arise from timing issues with multiple requests from the palo alto.

4

Thanks a lot for the answer. I have read RFC6238 and found only explanation how time step should be used. Pro tip: A time-based variant of the OTP algorithm provides short-lived OTP values © So, it doesn’t mean that it can be used only once, but that it can be used during the short time interval.
But in our case the privacyidea rejects a valid OTP received in the correct time step because it is received not for the first time, and I haven’t found anything about it in RFC6238. Is it a special security feature of the PrivacyIdea or explained in some different RFC?

And still, not clear why it doesn’t increase the fail counter. It sends reject with a reason wrong OTP, it shows failed authentication for the token in the token audit, but the fail count is not increased.

5

yes, and you are right about palo alto timeout, thanks again. It was a standard, so it is possible that it couldn’t wait for the respond and send another request. Usually, it is enough to use default timeout, but, I guess, in case of OTP the server should calculate the code and it takes more time, still need to investigate it.

6

Take a lock at the end of RFC 6238 Section 5.2:

The verifier MUST NOT accept the second attempt of the OTP after the successful validation has
been issued for the first OTP, which ensures one-time only use of an OTP.

Actually privacyIDEA provides an authcache to allow authentication using the same OTP.

This could happen depending on the configuration.

7

Thanks a lot for clarifying. It is my bad, I just read that the user may send second time the same top and didn’t read the last sentence.

But it means that the error message is a bit confusing, because the status is failed not because of the wrong OTP, but because the valid OTP was used for a second time.
If this depends on the configuration, does it mean that there is a configuration option that in default privacyidea configuration doesn’t increase failcount field?