Martin Bishop <martybishop@yahoo.com> queried the Listocracy: >A customer of mine is planning to launch a public web server for >online electronic commerce. The system is already built and already in >use internally for three months now so it has been adequately tested >before external users start using it. Users are all authenticated with >SecurID tokens, which is implemented with a SecurID Agent running on >the web server. The web server and ACE servers are at the moment in >the same (internal) subnet without even a router between them and all >works fine. > >Now, as we go public, we will move the web server from internal >network to a DMZ (if you will -:). We have already decided to use an >application gateway firewall and that the web server will reside on >its third network interface. [... snip ...] >While testing, we successfully managed to move the web server to the >desired location (3rd interface), but we are having serious problems >with SecurID authentication that we can't seem to solve. I think the interaction between the ACE/Client (embedded in your web server) and the ACE/Server is probably being tangled up because your firewall is "translating" and changing the IP address of ACE/Client. The ACE protocol -- which manages the client/server exchange for the authentication query and the ACE/Server's response -- continuously authenticates the parties to the c/s interaction by including in the exchange a MAC (which is calculated from, among other things, the IP address of the ACE/Client which initiates the request for the user authentication service.) What I suspect is happening is that your ACE/Client (in the web server) is calculating the MAC with its own IP address, while the ACE/Server tries to re-calculate and confirm the same MAC with what _it_ sees as the requesting client's address. Unfortunately, if your firewall or a switch has been translating IP addresses in the middle of the exchange, the MAC values do not match. The ACE/Server sees the specific SecurID authentication as OK, but the Server is forced to invalidate the authentication call because it can not guarantee the integrity of the ACE client/server interaction. Can you set up your firewall so that it does not do an address translation for the interaction between the webserver and the ACE/Server? That is the easiest solution, if it is possible. If you can't do that, there are some other technical options, but they may involve tradeoffs that you should discuss privately with your SDTI Sales Support Engineer (SSE). Suerte, _Vin >The problem is that, the _first_ SecurID authentication works fine but >all subsequent authentication attempts fail. If we want it to work >again, we have to remove the "securid" file from the web server >(actually from the ACE agent) and uncheck "Secret Already Sent" (or >something similar) on the ACE server. When we do this, the next >authentication attempt will succeed, but again the subsequent ones >will fail. > >Another interesting thing is that all these subsequent authentication >attempts that the ACE Agent sees as unsuccessful (and tells that to >our web application) are described as SUCCESSFUL in ACE server logs. >So it would be logical to conclude that somehow the response from ACE >server is either changed (probably by the firewall generic proxy) or >misinterpreted by the ACE Agent for some reason. >Furthermore, due to the fact that ACE Agent and Server exchange the >"secret" value along with the first authentication attempt it could be >that this value (that is used for encrypting subsequent auth. >requestst) is somehow corrupted. > >Unfortunately, we don't have enough insight into the SecurID >Agent-Server communication protocol to figure out how to solve this >problem but I'm sure that we're not the first ones who would want to >set up a system like that. So if any of you know any answers, your >suggestions will be highly appreciated. If you reply to the list, >_please_ reply to me personally also. > >Thanks for your time and best regards, > >Marty Bishop ----- "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _ A Thinking Man's Creed for Crypto _vbm. * Vin McLellan + The Privacy Guild + <vin@shore.net> * 53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:21:40 PDT