This page covers at least some of the costs which would be incurred as a result of a transition of our authentication systems from INF to EASE.
If it were the case that our KDCs held only user principals then things would be reasonably straightforward: we could declare a "flag day" and flip everyone over, probably overnight (ignoring long-running jobs and logged-in users). However, there are also host and service principals to consider.
These exist for a couple of reasons, and are fundamental to the Kerberos system. Host principals are automatically created when a (managed) machine is installed, on the authority of one of the Computing Team, who would use their own personal "admin" principal and its corresponding pass-phrase to verify that the machine is indeed what it is claiming to be.
The machine's host principal then allows it to register service principals, which allows a user to verify that the machine they are connecting to is indeed the one it claims to be, and that the service is one that it is expected to be providing. This provides strong mutual authentication between user and service: the service can trust that the user is who they claim to be by virtue of their successful use of their user principal, and the user can trust the service by virtue of its service principal which ultimately traces back to the person who installed the machine.
Thus, the transition from INF to EASE would require some member of the Computing Team to enter their admin principal and pass-phrase for every single managed machine, and the only safe time that this can be done is when the machine is being installed, as it is at that time in the least-unknown state.
The natural time to do this would be as part of the periodic upgrade process. We normally use a different login-screen background for this, to flag up the different distribution running, and that could be enhanced to provide a reminder as to whether INF or EASE were being used. This process can last for a year or more, however, and in the meantime there would be the likelihood of user-confusion. Alternatively, of course, a special re-install round could be done, which might result in a slightly shorter parallel-running time, but which might well be even more confusing as the other cues (different distribution, login screen etc) would not be present.
And in spite of any cross-realm trust links which exist between INF and EASE, it's likely that there would be some breakdown in our single-signon paradigm, requiring users to enter their usernames and passwords as they use services authenticating to one of INF or EASE from clients authenticating them against the other. This is bad from a security point of view, as it implicitly encourages users to enter their credentials in more than a very small number of places.
The mechanics of this would fall out in the wash, as a result of the need to reinstall each and every machine to effect the transition. The real additional cost here would be one of user-confusion.
As things stand it's straightforward to set up "Informatics-only" content, as authentication against the INF realm provides implicit authorization. If we used EASE, that would not be possible, and some other mechanism would need to be found.
That mechanism would then have to be applied to each and every page and site which currently simply require INF authentication. We could trawl for these on the managed web servers, but probably couldn't make blanket changes as each individual change should be approved by the page's owner to ensure that the authorization to be applied is what is really required.
INF iFriend users would have to re-register with the EASE Friend system. This would give them access to web pages. However, due to the implementation differences between the two, they would have no access to Kerbros-protected resources such as svn, ColTeX and AFS.