|Applies To||RSA Product Set: Authentication Manager, SecurID|
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.1.0, 8.1.1, 8.1 SP1
Platform (Other): null
O/S Version: ESXi 5.0
Product Name: null
Product Description: null
|Issue||If there is more than a 35 second gap between the user entering their On-Demand Authentication (ODA) credentials and the user entering their PIN, authentication will fail without an error in the authentication activity log. The /opt/rsa/am/server/logs/imsTrace.log will show the following highlighted errors if verbose logging is enabled.|
authmgr.internal.agent.server.DatagramHandlerImpl, DEBUG, rsa8appliance.lab.fp.f5net.com,,,,Failed to process request from client
per AM-28606 imsTrace log if enabled for verbose will now show:
“SessionID cannot be found for new PIN mode, maybe port is changed to : <New Source UDP port>”
To enable verbose logging,
Note: Both On-Demand Authentication and Next Tokencode Mode require two inputs, the second being a tokencode, and both are affected by this issue
The F5 is doing Network Address Translation (NAT) of the agent as it forwards authentication packets to the Authentication Manager server.
|Cause||The F5 (or any NAT router/firewall) has a UDP timeout, which is approximately 34 seconds on version 11.5 and at least 60 or slightly more with version 11.6. After this timeout the source UDP port is changed, as the NAT views it as another connection. This causes problems with the RSA authentication session which assumes the source port will remain the same for the Next Tokencode request as it was for the PIN or first tokencode.|
Here’s a summary trace on the agent side. The agent's IP address is 10.5.5.100 with a source port of 59997. It is sending authentication requests to the Authentication Manager server (172.31.45.54) to destination UDP port 5500:
In frames 7 - 11 the Next Tokencode Mode requests are transmitted four times on a five second timeout. There is no response seen from the Authentication Manager server.
When the same packets go through the NAT translation agent 10.5.5.100:59997 is translated to 172.24.102.213:60400 and the Authentication Manager server remains 172.31.45.54:5500
The problem is that NAT has a time-out for UDP translated packets When that time-out is exceeded, the source UDP port is changed. In this example the NAT changes the port from 60400 to 53640.
The RSA agent API uses the same source UDP port through the entire authentication process until Next Tokencode Mode is entered. The problem is that the RSA server uses the source UDP port as part of the session ID to keep track that this Next Tokencode request is related to the previous tokencode.
When the source UDP port changes, Authentication Manager flags this packet as rogue and drops it from any authentication request in case it is part of a DOS attack. This action will place the "SessionID cannot be null" entry into the imsTrace.log. Since the request is dropped, there will be no entry for the transaction in the authentication activity log.
F5 confirms that this UDP timeout is about 30 seconds in version 11.5 and about 60 seconds in version 11.6.
|Resolution||There may be Two/Three ways to fix this;|
1. Upgrade to v11.6
2. Configure either the ‘preserve strict’ or ‘SNAT automap’ on the F5 – Support links below.
3. Last resort, you might need an iRule to do this since it’s UDP and not TCP
Review the articles below to avoid using NAT or to increase the NAT UDP time-out. On the F5 device you can use SNAT (Secure Network Address Translation) automap or the option to preserve the strict value configured for the source port. SNAT automap is what people usually try first
The F5 version 11.6 will give you a longer UDP NAT time-out, at just over 60 seconds which may be enough time to avoid this.
|Workaround||This problem is only seen when there is a Network Address Translation (NAT) router or firewall between the F5 agent and the Authentication Manager server(s). This problem may be related to the RSA agent API, as it was reproduced by F5 with the RSA Authentication Agent for Windows 18.104.22.168, but only if NAT was enabled between the authentication agent and the Authentication Manager server(s). F5 used a pfSense router/firewall for the NAT, so one work-around is to avoid using NAT between an F5 and the Authentication Manager server(s).|
F5 also reports that version 11.5.x gives about a 35 second window between entering the PIN and entering TokenCode for OnDemand, but that window increases to 60 seconds with F5 version 11.6. A second work-around would be to upgrade the F5 to version 11.6 to have the larger 60 second time-out.
Users can close the browser after entering their PIN when the Enter Next Tokencode prompt first appears then open a new F5 login session and enter that tokencode instead of their PIN. This will not be considered a tokencode reuse because the first time the tokencode was sent without a valid session ID, so it never was processed by the Authentication Manager server and therefore, it has not been used. This situation shows the difference between the time-out to enter an On Demand code – the 35-60 second F5 situation described in the KB vs. the normal 2-3 minute window of a valid tokencode for Next Tokencode Mode, and the expiration time-out of the On Demand code itself, which is often 30 minutes. In other words, the tokencode is still good even when the login fails this way or especially when the login fails this way and is still good for up to 30 minutes. Alternatively, users can be told to enter their tokenvodes as fast as they can.
Related work-arounds for other F5 problems include:
|Notes||Screen caps of a standard authentication are shown below. Looking at the data captured from a tcpdump filtered for the UDP 5500 authentication traffic we see the only readable byte is at Frame 45 (offset 0x2A), the first byte of UDP data payload. The highlighted information is 67, a time request to the Authentication Manager server. The rest of the payload is encrypted. |
From the agent side we see 5B, a lock request in Frame 47 which prepares the Authentication Manager server(s) for an authentication request. This enables the adjudicator service to send the authentication request to only one server in the deployment, which prevents passcode reuse attacks.
In the next screen cap, Frame 49 shows an authentication request (5C). In this trace the is PIN being entered.
Frame 67 shows the server response (6C).
A packet capture showing the issue with the F5 is below:
Note that message ID 62 is what is used to define a request for Next Tokencode or NTC, which is how On-Demand Authentication works: