Proposal to Reinstate IP Address Matching Rule in ISIS
Status
September 7, 2008
The changes have moved into production.
August 22, 2008
The changes are scheduled to release into production on September 7th, 2008. We will send details to the ISIS developers via the mailing list.
June 1, 2008
The ISIS team is wrapping up internal testing of the code changes. We expect to release the changes to open beta in test ISIS during the week of June 9th.
Overview
The IT Security Office recently concluded its analysis of ISIS and key ISIS enabled applications. Based on its results, the IT Security Office has asked us to reinstate the mandatory session termination rule when a user's IP address changes in between calls.
In ISIS 4, if a user's browser IP address changed within a session, we terminated the user's ISIS session. At the same time, we returned an error code of "604010" to the application via the web service response. This was a security measure to prevent ISIS ticket hijacking. However, that rule created a slew of login problems where valid user sessions were terminated.
In ISIS 5, we relaxed the rule to a warning. Instead of automatically terminating a user's session. We issued IP address change warnings to applications. The applications then in turn decided the appropriate course of action based on its security requirements. The change was designed to help reduce the amount of support calls applications were receiving from users' sessions terminating due to IP address changes. However, the Security Office has demonstrated that a hacker can hijack a user's session without triggering any kind of security alert response from any of the affected applications.
As a result of this analysis, we intend to reinstate the mandatory session termination in the next major ISIS update.
Proposed Changes
We propose the following changes to ISIS:
Bring back error code "604010".
In essence, we revert to the ISIS 4 behavior of automatically terminating a user session when we detect a change in the user's IP address. We will replicate the response in ISIS 4 where we expire the user session, and return an error code of "604010" in the web service response.
We understand that this change will cause some amount of user inconvenience. To mitigate some of the issues, we are proposing additional updates described below.
Improve error messages associated with "604010".
Because a number of applications echo the ISIS web service error messages directly to the user, we plan to modify the error message associated with "604010" to provide additional information, possibly a link to a page explaining what the user can do to troubleshoot the problem.
Note: this means that we might send different messages with the same error code, depending on what we can reasonably gleam from our end. For example, if an application sends us a semantically invalid IP address (e.g., 0.0.0.0, 255.255.255.255), we can return a different error message than a generic "IP address mismatch" error.
Call for Action: If you have ideas on what would be useful to display (or not to display) here, we very much appreciate your input...
Create a "How Do Deal with 604010 Error" guide.
Following the last point, we plan to create an online guide documenting the various conditions which may cause the 604010 error. We hope this guide helps the users and the help desk staff trouble shoot the problem and figure out a workaround. Again, we need your input here.
Implement a "Whitelist" to exempt selected networks from this IP checking rule.
There are several known campus networks configured with private IP address/NATs. These networks do not function well with IP-based security schemes used by ISIS. Specifically:
- A network issues private IP addresses, and maps them to public IP address for outgoing traffic (NAT).
- An ISIS application named X lives on that private network.
- When a user on that network attempts to sign on to X, ISIS records the user's NAT public IP address during login. However X sees and submits the user's private IP address to ISIS when making the web service call, thus causing an IP address conflict.
We are evaluating mechanisms to selectively exempt certain traffic from these network from being subjected to this IP checking rule. We want to be as fine grained as we can with our whitelisting mechanism so that we do not unnecessarily expose users from these networks to security vulnerabilities.
As we develop more detailed design in this area, we'll post it here for review and comment.
Implementation Timeline
We agree with the IT Security Office that this change needs to be implemented quickly. We plan to implement this change immediately following the end of the Spring Quarter 2008 (end of June 2008).
As is the case with any major ISIS system updates, we will make test version of this change available for public review at least 30 days prior to production implementation. We intend to have this updated version of ISIS available in our test environment by May 20, 2008.
To help us meet this schedule, please provide feedback ASAP. We need to freeze design details by the end of April 2008.
Feedback and Discussions
We would like to use the ISIS Developers Discussion List as the forum for discussing this change. Please post your comments/feedback to isisdev-l at lists.ucla.edu.
In addition, we also recommend that you login to spaces.ais.ucla.edu and "watch" this page so that you are automatically notified of changes to this page.
You may also contact Albert Wu (albertwu at ucla.edu) and Ross Bollens (bollens at ucla.edu).
Additional Information
The "jumping IP" problem had been discussed in past ISIS discussions. We've reposted several key documents from our older support web site for your reference: