Child pages
  • ISISAuthnWithUnstableIP

The ISIS Jumping IP problem: Authentication for Users with Unstable IP Addresses

This article was originally posted on on August 23, 2003.

The following is taken from a post to the ISIS Developer's List from Albert Wu describing the various causes of the "unstable IP" problem. You can find the entire discussion thread in the list archive.

Sent: Mon Oct 20 18:33:15 PDT 2003
Subject: [isisdev-l] Looking for a better way to secure ISIS Session Ticket

It occurs to me that some folks here may not have the full background to this problem. It probably makes sense if I describe this "jumping IP" problem in more detail:

As I described in the original post, ISIS requires all requests for a user to come from the same IP address throughout a single ISIS session. Upon authentication, ISIS embeds the user's IP address inside the ISIS session ticket. It then requires each application to submit the user's IP address and the the ISIS session ticket during subsequent verifySession calls to confirm the ticket has not been hijacked from the user browser. This is largely a security mechanism to curb replay attacks.

This dependency on IP address, unfortunately, causes problems in certain unusual IP address configurations:

A: User comes from behind a NATted network or via a proxy server

This is the most common configuration where we experience problems. There are 3 problems here:

  1. Because the user is most likely sharing NAT or Proxy IP addresses with other users, we lose the ability to uniquely identify the individual machine. This DOES NOT cause ISIS authenticaiton to fail. However, it does look suspecious in our logs (Why are these 20 people logged in from the same IP address at the same time?)
  2. If the NAT or proxy server is dynamic, i.e., it assigns the user a different IP address within a user session, then we have the real problem. There are really 2 sub-scenarios here:
    1. The NAT or proxy maps the user to a different IP each time he makes a HTTP request.
    2. The NAT or proxy maps the user to a fix IP within a session to a particular host, but assigns the same user a different IP address when he visits a different web site.

In 2.2, because the ISIS login server is a different web site than applications it supports, the IP address don't match. In both cases, ISIS sees the ISIS session ticket being presented with a IP address other than the original during the verifySession call. This causes ISIS to reject the ticket and terminate the user session.

FYI, AOL is the primary guilty party with its dynamic proxies. The AOL software is hardcoded to use the AOL proxy server pool. Users can work around this by connecting to the Internet using the AOL software but uses his machine's IE or Netscape browser to surf the ISIS enabled sites (assuming those browsers are properly configured). To complicate things, we are seeing evidence that other ISP's and some private companies may be running similar dynamic proxies or NATs...

3. When a campus network is NATTed, if the network runs an ISIS enabled application within the NATTed network, that application likely sees the private IP being reported from the user machine while ISIS sees the public, NATTed one.

This is actually a very significant problem for ISIS. In case you didn't know, the entire Medical Enterprise network is moving to NATTed networks with private IP addresses behind its firewall. We are working with the Medical Enterprise on that...

B: User Machine has multiple IP addresses

Occasionally we encounter folks who have multiple network cards with multiple IP addresses on the machine. Although your operating system is supposed to pick one and use it consistently for outbound requests, we have seen evidence indicating otherwise.

C: User's Internet Connection is Interrupted and then Re-established

If a user's ISP connection (dial-up or otherwise) is interrupted while he is working with an ISIS enabled application, when the connection is re-established, he will likely receive a different IP address from his ISP. This is particularly likely to happen if the user's browser is set to auto-connect using a dial-up connection. The user may not realize that his connection was dropped and re-established.

  • No labels