Alex Hague <[EMAIL PROTECTED]> queried the FW Listocracy:
>Has anyone managed to get secureID authentication working through a
>NAT'ing firewall ? How do others on the list secure their extranets ?
Hi Alex,
Your assumptions about why you have had a problem passing the ACE
client/server protocol through your NATing Firewall -- to support RSA
SecurID authentication -- are, unfortunately, right on target. You wrote:
>I think that problem is our Firewall using MAT / NAT. Unfortunately we are
>unable to use anything but NAT when coming from the DMZ to the internal
>network. It's my guess that the secureID agent includes it's IP Address in
>the information being sent to the ACE server, and of course the IP Address
>that the information comes from is actually the firewall's internal
>interface.
In the ACE client/server interaction, a MAC is used to check the
validity of the "OK" response sent from the ACE/Server (behind the
firewall) to your ACE/Agent.
Predictably, because of the NAT, the message can not be authenticated.
There are ways to get around this, but you will probably need
direct support with RSA's local office or its NZ reps.
Your RSA Sales Support Engineer (SSE), or RSA's Customer Support,
should be able to offer you the traditional work-around -- although I can't
say whether it would be appropriate, since I don't understand your threat
environment.
Alternatively, they may suggest you wait for the new ACE/Server
5.0, now in beta, and expected to be released sometime in the next couple
of months. The 5.0 ACE/Server is harbinger for a whole new suite of
ACE/Agents and proxies. ACE 5.0 will also introduce a new ACE
client/server protocol which -- by rumor at least -- may allow you to
sidestep the NAT issue completely.
There are a dozen big ACE 5.0 beta sites out there, but I don't
think they are allowed to comment about the new technology until it is
announced. I'm a consultant to RSA myself (so please appropriately
discount my remarks), but I don't know enough about the new products to
offer meaningful feedback. You really do need to talk to some well-informed
RSA folk, either in RSA Sales or Customer Support: <www.rsasecurity.com>.
The traditional fix for this problem was clever, but it also had
some inherent limitations.
The ACE/Server has historically managed backwards compatibility --
through a decade's worth of ACE/Agents -- by checking the version number in
the sdconf.rec file in the ACE/Agent. IP addresses were introduced into
the ACE client/server exchange with, I think, the ACE/Server v. 2.3, to
provide an additional level of security for the interaction.
RSA's Customer Support engineers have a trick whereby they can
build the crucial ACE file (sdconf.rec) on a pre-2.3 ACE/Server -- but with
your information -- and then graft that file on to your more-modern
ACE/Agent.
The net effect would be that one or more of your ACE/Agents would
be seen as a pre-2.3 Agent by your ACE/Server, so (to maintain
compatability) the ACE/Server would not include the MAC check.
Since it sacrifices some security, this is not a universal
fix. Quite frankly, it is not always appropriate. If the new ACE
protocol finally does away with this problem while maintaining full and
appropriate security, as I expect, there will probably be a lot of happy
campers out there among RSA's huge installed base.
Surerte,
_Vin
PS. As I hope is self-evident, only RSA speaks for RSA.
-----------------------
Mr. Hague wrote:
>Detail:
>
>We're investigating an extranet solution. We have our internet servers on a
>DMZ and are going to add an extranet server to the DMZ. We already have a
>SSL Relay (Apache compiled with mod-ssl, mod-proxy and mod-rewrite) which we
>use for our OWA server. We plan to use the SSL-Relay to encrypt our extranet
>traffic and I don't expect to have any problems doing this. The platform for
>the actual extranet will be IIS 4 on NT 4.
>
>The area that is proving to be a bit difficult is authentication. We don't
>want to have the extranet server on our internal network (which we would
>have to do if we wanted to authenticate against domain accounts, or have a
>huge hole in the firewall between the DMZ and the internal network ! (not an
>option)).
>
>We've come up with the following possible solutions:
> 1 - Have a generic username and password for access to the extranet
>(this would just mean a user account on the Extranet box)
> 2 - Assign each extranet user a username and password (multiple
>accounts on the extranet box)
> 3 - Some sort of proxy / replication of domain account information
>to the extranet box
> 4 - secureid authentication
>
>Of these options we've decided that the only one that provides good security
>4. To issue secureid tokens to our extranet users and to use the ACE IIS
>plugins to authenticate them. We can successfully set everything up on the
>internal network, but as soon as we put a firewall in between it all stops
>working. We're opening up port 5500 UDP from the DMZ to the internal
>network, but there's no joy. We've used a sniffer to check that this (port
>5500 UDP) is the only port being used.
>
>I think that problem is our Firewall using MAT / NAT. Unfortunately we are
>unable to use anything but NAT when coming from the DMZ to the internal
>network. It's my guess that the secureID agent includes it's IP Address in
>the information being sent to the ACE server, and of course the IP Address
>that the information comes from is actually the firewall's internal
>interface.
>
>I'm looking for suggestions on:
> 1 - Anything that I can try to get the secureID authentication
>working through a firewall
> 2 - How other people on the list secure their extranet (pros/cons of
>methods that have been chosen and relevant network design / structure)
> 3 - Anything else that maybe relevant
>
>Looking forward to the responses,
>Alex
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
