Refeds


Subject Scope spoofing - Scoping Policy Framework?
From Kristof Bajnok <bajnokk@xxxxxxx>
Date Wed, 11 Nov 2015 14:29:10 +0100

Hi all,

my theorem in brief: scopes play a key role in federated access control
therefore steps should be taken in order to prevent scope spoofing in
interfederation context.

By scopes I mean the use of the proprietary shibmd:Scope metadata
extension, because both Shibboleth and SimpleSAMLphp SPs are able to
verify scoped attribute values with metadata. I think the use of scopes
is quite common in federations.


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 eduID.hu:
`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.
But which document should deal with this issue?

However, I think scope spoofing is a more threatening attack vector than
simply rely on policy to prevent them to happen.

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. 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. There might be an eduGAIN scope
registry database instead, but that would be an administration
nightmare, I'm afraid.

Or, on the other hand, SP software could implement something like Sender
Policy Framework (SPF) does for mail. That would mean that domain owners
could register RR records to their DNS containing the entityIDs that are
entitled to use the domain name as a scope. Although I think it would be
a more or less secure and maintainable solution, there are a couple of
disadvantages with this, even beyond the trivial one (lack of
implementation, slow acceptance). First, it limits the scope to be a
real domain name. Second, it has problems with delegation and proxying.

I'm finishing here because I haven't been thinking too much about this.
I just wanted draw your attention to this topic and I'm interested in
your thoughts. Is this something that needs some more effort to work out
and/or standardise?

Best regards,
Kristof