If you are experiencing authentication errors
Please notify us immediately by writing to trilt@bufvc.ac.uk. An explanation of how this problem occurred and what is being done is available below. So far only a small number of institutions has been affected but we take this very seriously and are working with all partners to have this complex problem solved as soon as possible.

Friday 12 March 2010
SDSS have now tested the proposed solution successfully. They will be emailing IdPs soon but in the meantime you please read the documentation with the required modifications.

Thursday 11 March 2010
We continue waiting for documentation and testing from the Federation (SDSS). Testing has begun, however.

At this moment it does look like some Identity Providers’ implementations need fixing as per the message below. If this process takes much longer we will attempt to see if there is any action that we can implement that will circumvent the problem, at the moment it is not clear how this is possible without compromising security but all options are being considered.

Wednesday 10 March 2010
This is the background for the current authentication problem, in broad terms both the Federation (SDSS) and Eduserv are in agreement about this:

In August 2009 a vulnerability was found in SSL (TLS) (further details can be found here: http://www.phonefactor.com/sslgap). Essentially this means a “man-in-the-middle” attacker is able to inject arbitrary data if an existing secured session is renegotiated by either the server or the client. Due to the nature of this vulnerability the only immediate fix was to entirely disable all renegotiation.

It was believed when this attack was first identified that Shibboleth installations would not be affected. The reasons for this being two-fold:

1. A “standard” Shibboleth install (by where the back channel runs on a designate virtual host), does not require renegotiation by either party (client/server).
2. If an Identity Provider had installed in a “non-standard” way (the back channel runs on the same virtual host as the browsers facing part – SingleSignOn service), where renegotiation is required, the fix implemented by RedHat (http://kbase.redhat.com/faq/docs/DOC-20491) still permitted server initiated renegotiation if the “SSLVerifyClient” directive was explicitly placed within a <Directory> or <Location> block (this is exactly what the “non-standard” install does).

Point 1 above still stands, however it has been discovered that point 2 does not. Specifically Apple recently applied a security fix (http://support.apple.com/kb/HT4004) which entirely disables renegotiation. This means that service providers running on Mac OS (e.g. BUFVC) are unable to renegotiate the SSL connection (the client will just not do it) when attempting to query the back channel in a “non-standard” IdP deployment, thus disabling access to end users.

Identity providers who have deployed in the “non-standard” configuration may have to add the additional virtual host and completely protect it with the “SSLVerifyClient” directive, and update the UKFederation metadata.

Actions being taken: SDSS are working on reproducing this issue and thus documenting the workaround, they should have documentation ready by 11/3/09. Please do not attempt to solve this independently without contacting them.

We are waiting confirmation of the fix anxiously. It is important that this is verified and works for all IdPs as the SSL vulnerability and subsequent patches are likely to bring this problem to other service providers, not just the BUFVC.

Tuesday 9 March 2010
BUFVC has contacted all off-air recording representatives that are experiencing problems with authentication and issued BUFVC usernames and passwords so that they can access protected resources such as TRILT. If you require access and are currently unable to login as usual please contact trilt@bufvc.ac.uk

Monday 8 March 2010
We continue working with the Federation (SDSS) and Eduserv to resolve this problem, the cause has now been identified and its details will be published tomorrow. We also hope to have a  solution tested and proposed by SDSS tomorrow which will be sent to those institutions having problems. This page will also be updated.

Friday, 5 March 2010
We remain concerned that a small number of our members institutions haven’t been able to access our databases via federated access management since late Tuesday 2 March 2010. We are working closely with the SDSS/Federation and Eduserv to identify the problem and the solution. There has been progress and it seems that we have been able to identify the most likely problem and SDSS are going to test a possible solution on Monday 8 March. We will send all affected institutions an email when we have more information, if not immediately with the tested solution, at least with a detailed technical description of the problem.

Essentially this problem has come to light because of a SSL security patch. This patch will become more prevalent in coming weeks/months and so it will be likely to affect other service providers’ resources in the future. Unfortunately we are at the front of the wave in this respect.

If you need any support from BUFVC please call us and we will conduct your research and/or television & radio programme orders on your behalf. We would appreciate if you could spread the word to other colleagues that may use our resources.

For more information or support please get in touch with trilt [at] bufvc.ac.uk