Skip to end of metadata
Go to start of metadata

Jumping IP problem revisited: 2 proposals

This article was originally posted to mi6.ais.ucla.edu on February 16, 2004.

The following is taken from a post to the ISIS Developer's List from Albert Wu summarizing two alternative approaches to addressing the "unstable IP" problem. You can find the entire discussion thread in the list archive.

Sent: Mon 2/16/2004 6:23 PM

As many of you know by now, an important security mechanism of ISIS is that it requires a user to come from the same IP address throughout a single ISIS session. It was a measure implemented to prevent replay attacks.

Unfortunately, this security mechanism has also caused some users to not be able to log in due to a variety of legitimate reasons. To quickly recap, if a user's environment meets these criteria, ISIS cannot validate the user's session:

  • The user is coming in from a ISP via dynamically load balanced proxy servers or NAT servers. AOL, portions of Earthlink, and several corporate networks are known examples.
  • The user is using a machine with multiple IP addresses.
  • The user has a private IP address issued by a campus network and is visiting a campus application residing on a private IP network. In this case, ISIS sees the user's public NATTed IP while the application sees the user's private IP.

Regardless of the cause, this dependency on user IP address is causing increasing number of users to not able to use the ISIS service. The College folks proposed a workaround last December . Others on this list proposed asking the affected user to first connect to a campus VPN server (which in theory would show the user with a VPN assigned IP).

There didn't seem to be overwhelming support for either solution. Both would have required a user trying to visit a web application to take somewhat awkward actions to login. Combined with the fact that ever increasing number of the networks are now NATTing and/or using proxy servers, Depending on the user's IP address to fend off replay attacks is becoming less effective. It's time we take a different approach:

To that end, we have 2 alternate proposals (both have been proposed before by various parties, I am bring them forward with minor modifications):

I: Issue one-time use ISIS tokens

These would either be in-place-of or in-addition-to the current ISIS ticket.

Scenario:

Each time an application calls verify, it must submit this token, ISIS validates this token and returns a new token to replace the old one. Since each token can only be used once to call ISIS, any attempt to reuse the token (such as would be the case in a replay attack) would be immediately discovered.

Pros:

  1. This is a completely IP independent model.
  2. Similar mechanisms are used by other WebISO implementations and emerging standard protocols such as Shibboleth.

Cons:

  1. The application will need to take on an active role to manage the ticket/token, i.e., each application will need to write the new one time use token to some public store (cookie cache?) so that the next application can use it.
  2. If a user opens multiple windows within a single browser instance and started rapidly multi-tasking (get grades, get class schedule, check English 3 assignment, download History 10 notes...), this model can break since multiple applications may submit the same valid token.
  3. It'll be very difficult to provide a backward compatible mode.

II: Remove IP checking during ticket validation.

Depend instead on auditing to detect potential replay attacks.

Scenario:

Maintain the current ISIS programming interface (ala web service). The application still submits the user's IP during a verifySession call. However, rather than killing the user's session when the IP addresses don't match, ISIS will instead validate the ticket while issuing a warning in the returning XML document.

Pros:

  1. This is a far less intrusive approach. We will not need to break the current ISIS programming mode. This means applications won't break after implementation (Backward compatibility is a good thing...)
  2. Conceptually and programmatically this is an easier mechanism to implement.
  3. Each application can decide how important it is to implement code to guard against replay attacks.

Con:

  1. We shift from an active security model to a much more passive one. Unless applications implement additional checks, a replay attack may go un-noticed. We can mitigate this to some extend by monitoring on the ISIS server end...

Conclusion

At this point, I am leaning toward II. It eliminates a thorny ISIS usability problem without significantly weakening the ISIS security model. It is also a far less intrusive change requiring far less changes from the application side.

We are currently ramping up for a major ISIS update for the summer (more on that shortly). I'd like to be able to address the jumping IP problem in this coming release. Please help us by providing your feedback to this list. We will make a go/no-go decision on our implementation features list items during the first week of March. Hopefully this one makes it.