Chaining Challenge Responses

Question
1

I am attempting to setup privacyIDEA in a way that will ease our migration from RSA SecurID AM over to this solution. To do so, I need to be able to forward existing users with RSA tokens/on-demand to the RSA SecurID RADIUS server.

The existing token for RADIUS does not handle challenge responses, but I have updated the token class to allow these to work. However, it only works if the user already has setup their PIN. For users with a new PIN, the RADIUS server responds with two challenges. The first one asks for a new PIN, the second asks you to confirm that PIN.

Is there a way to chain/spawn another challenge from within the check_challenge_response event to handle this?

2

Hi droo,
what kind of authentication devices with RSA are you currently using? I thought the keyfob tokens?
How is there challenge response involved anyways?

Basically I would not recommend to use RADIUS tokens. THat is to cumbersome.
Take a look at the passthru policy. You define a RADIUS Server in privacyIDEA and simply forward all authentication requests of users, who have no tokens to RSA SecurID MA.

https://privacyidea.readthedocs.io/en/latest/policies/authentication.html#passthru
https://privacyidea.readthedocs.io/en/latest/faq/migration-strategies.html

Regards
Cornelius

3

We’re using a combination of software and hardware tokens. The issue arises with either the builtin RADIUS token or the passthru when the user’s PIN has been reset or a NextTokenCode is required since neither can properly handle the Access-Challenge chain that occurs.

Scenario 1 [PIN already set and token not out of sync]:

Access-Request (PIN+Passcode)
< Access-Accept
Works with both RADIUS token and passthru policy

Scenario 2 [PIN already set, but token is out of sync]:

Access-Request (PIN+Tokencode)
< Access-Challenge (Enter Next Token Code)
Access-Request (NextTokenCode)
< Access-Accept
Works with my modified radiustoken.py with challenges added. Does not work with pasthru

Scenario 3 [New PIN or PIN Reset]:

Access-Request (PIN Only)
< Access-Challenge (Enter a new alphanumeric PIN)
Access-Request (New PIN Only)
< Access-Challenge (Confirm the new PIN)
Access-Request (New PIN Only)
< Access-Challenge (Enter PIN+Tokencode)
Access-Request (New PIN+Tokencode)
< Access-Accept
Does not work with either since I’ve been unable to figure out a way to chain challenge request/responses

4

Would you care to share your changes, so that we could incorporate them into passthru?

5

Sure. However, note that I’ve only been programming in Python for about 3 days now so I’m sure I’m doing many things incorrectly. And I’m sure what I’m doing in the code is a complete and utter hack.

I overrode is_challenge_request, is_challenge_response, and authenticate to place some logic in there to allow for multiple chained challenges. It works in our environment with the RSA SecurID Auth Manager for hard/soft/ondemand tokens and also functions during PIN resets.

The below is my current commit and changes:


6

This looks interesting!
I think I would like to add such functionality to the RADIUS token (and maybe even to the forwarding policy - this might get tricky, because we do not have a token object!)

I see you saved several states of challenge response in the token object. Usually we save challenge dependnt stuff in the challenge table, not with the token object.

I will create an issue for this at github.
You can think about, if you want to create such a pull request yourself…
Thanks a lot
Cornelius