At UCAR, our security staff has a good relationship with our library. The librarians and their sysadmins are sympathetic to not using IP addresses as authenticators.

Tor is just one education point. Others are visitor networks, guest machine networks, proxies deliberately opened up to gain access to subscribed journal sites from staff homes or research program field projects, and so forth.

We thus work with the library and vendors for arranging authenticated access using two-factor/one-time-password devices or reusable credentials (passwords or certs), when possible. Some vendors have been willing to do user logins and authentication. Kerberos with pre-auth default via timestamps seems to be a win for opening up for this without allowing offline cracking of tickets.

Of course, most vendors are, well, vendors, and want us to re-engineer our entire network to fit their notions of access control via IP. For those, security staff and the library deal with the problems as they present. We explain that not all of our network allocations are for staff members--even the most blinded vendor seems to be able to understand "that part is like an ISP for scientists from other institutions".

Because journal sites are the biggest IP-as-authenticator offenders, the library keeps a list of subnets with majority staff, with visitors, and with guests for those vendors to use, depending on the license terms for the info service. The library errs on the side of openness (they are, after all, librarians) until someone complains.

They do tell vendors about which IPs are Tor nodes. Also, we have in the past suggested that the vendors check the consensus and ask for secondary institutional authentication if someone is coming from a current Tor exit on a port allowed via the exit policy. No reachable vendor staff have been able to understand that advice yet, to the best of my knowledge. But we'll continue trying, as engagement opportunities present themselves.

Richard