identity leak

Sun, Jul 10, 2005

There’s been talk recently of IP address matching at an SP to bypass the WAYF, i.e. an SP gathers your IP address and uses it to look up your IdP from an agreed internal list.

I had a good think the other night and I think that referrers and IP addresses are instances of what I would call “Identity Leak”.

The Shibboleth profile does not allow an SP to aggregate attributes from mutliple IdPs to try to eventually identify a user. However, the underlying HTTP headers do identify you. For example, the referrer tells the SP the domain you’re coming from - your affiliation. It’s bypassed your IdP’s ARP.

The worst case is the IP address. It can identify YOU! Your machine has become part of your attribute profile but it’s not in any ARP and you can’t control it’s release. How can it identify you as an individual? Through “Attribute Scatter” - see the Loughborough slides. The SP has your IP address. It then sends an Attribute request to your AA without any AttributeDesignator nodes - the result is everything your AA can release about you comes back. If that info contains your IP address and name - then you’re identified.

The WAYF can’t do address matching as it doesn’t get referrer/IP stuff from the SP but it could. You could pass these as extra GET params without breaking the Shibboleth implementation but you’d be breaking the spirit of the Shibboleth profile by encouraging an SP to gather what is in effect identity information from the HTTP headers. What if a federation contract stated that no identity information must be extracted from the headers?

The only identity information that ends up in the headers is put there by the IdP. Not the SP.

I think we should leave address/referrer matching alone for the moment. Perhaps there’s a better way to bypass the WAYF. A way that doesn’t go against Shibboleth.

comments powered by Disqus