Subject Re: Scope spoofing - Scoping Policy Framework?
From Niels van Dijk <niels.vandijk@xxxxxxxxxx>
Date Thu, 12 Nov 2015 10:28:22 +0100

Hash: SHA1

Hi Kristof,

In theory I agree with your write-up, however in practice there are
several issues.

One scenario we should include is where a proxy could be delivering
many scopes on behalf of IdPs behind the proxy. THis is common for
Hub-n-Spoke federations, but also exists in e.g. Uk Access federation
where some proxies like eduServe exist. Also IdP as a Service
scenarios could be serving multiple scopes.

Another scenario is where institutions cold have multiple 'brands'
attached which are served from the some IdP.

I am not saying the scenarios above are conflicting with your
description, its just that whatever we come up with should also fit thes

By the way, if we are discussing scope, we should probably also add
SchacHomeOrganisation into the discussion. We are for example
expecting the scope to match the SHO.

Please also find some comments and questions (to you and Tom) inline

On 12-11-15 01:17, Tom Scavo wrote:
> Hi Kristof,
> On Wed, Nov 11, 2015 at 8:29 AM, Kristof Bajnok <bajnokk@xxxxxxx>
> wrote:
>> As far as I know there are no policy requirements in eduGAIN for 
>> registering scopes for IdP and AA entities. IMHO there should be 
>> something. Currently we have this text in `All scopes
>> used by the Identity Provider MUST be under a DNS domain which is
>> possessed by the operating organisation.' I know it is not 
>> generic enough, so a better statement should be composed for
>> eduGAIN.
> FWIW, I don't think this is an eduGAIN issue. As I see it, eduGAIN
> is service, not a policy making body.

eduGAIN is clearly a service with a trust framework attached to it.
That description could potentially be adapted. I do agree howver it's
probably better to discuss this in a broader scope liek e.g. REFEDs
and ten adopt whatever the outcome is of that.

>> But which document should deal with this issue?
> Well, I'm not sure it's the right problem to solve. There are
> three important uses of domains in IdP metadata: entityID, scope,
> and endpoints. All three are important, I think.

All are important, but they are rather different things from a trust
perspective. IdP metadata has 2 roles here:
- - make things discoverable,
- - add trust.
The entityid and endpoints are part of the technical setup and a
technical responsibility of the IdP itself. They can be verified in
and trusted from the IdPs own metadata.
A claim on scopes is discoverable with the metadata however not
verifiable from the IdP metadata, it needs a third party.

>> One possible countermeasure is to run periodic checks on the
>> metadata aggregate. Its main advantage is that it can be
>> implemented as part of the eduGAIN operations effort.
> I don't think the eduGAIN operators are in a position to claim
> much about a scope in metadata. I don't see how anyone but the
> metadata registrar can make such claims.

Indeed, and as such we for example have a registry of all domain names
an IdP may claim as a scope/SHO. In oractice we have seen very few
cases where the same technical instance wanted to claim different/
multiple scopes

>> However, there is no authoritative source that could determine
>> whether one entity is entitled to claim the use of a scope or
>> not. Some fuzzy guess could be made but that guess can be both
>> false positive or negative.
> Yes, that's true. When a registrar publishes an IdP entity
> descriptor, the registrar is implicitly making a claim about the
> domains in that metadata. If we standardize anything, it should be
> the essence of that claim.
>> First, it limits the scope to be a real domain name.
> That horse has already left the barn, I'm afraid. In the case of 
> eduPersonUniqueId, the scope actually is a DNS domain.

eduPerson says: "The "scope" portion MUST be the administrative domain
of the identity system where the identifier was created and assigned. "

Technically that could be "@idp.local" however we would not allow
that. Typically we prefer this to be the domain part of the FQDN of
the institution. But exceptions exist, e.g. when an IdP has outsourced
its IdP.

Also, a scope from an NL based IdP could include .nl .com, .org, .edu
etc. Not an issue perse,  just noting that a per country scenario
would probably not work.

>> Second, it has problems with delegation and proxying.
> Yes, it is well known that scoped attributes do not traverse a
> gateway or proxy very well. That is "by design," I think.

Not perse, that is an implementation choice of a SP proxy. I know of
proxy products that happily retain original scope.
There is also a potential issue with IdP proxies, see my note above


- -- 

Please note:
On January 1st, 2015 SURFnet moved to a new office.
New Visiting address: Kantoren Hoog Overborch (Hoog Catharijne)
Moreelsepark 48, 3511 EP Utrecht
Postal address: PO Box 19035, 3501 DA Utrecht
New Telephone: +31 88-7873000
Version: GnuPG v2.0.22 (GNU/Linux)