Hi Sam, 

Further to this discussion (just to roll back a few messages), can we get some sort of consensus on the attribute's name? I'm assuming that:

a) It's a VSA similar to SAML-AAA-Assertion
b) Its value will be required to be scoped (value@idp-realm)
c) Scoping will be done by the IdP, and its value may not be changed in transit (i.e. similar compliance as CUI?)
d) The SP (or RP) will need to check that it is scoped and potentially whether the scope matches the realm of the original outer access request
e) The less configuration the better, so adoption into the FreeRADIUS code sooner is better

Does that about sum it up?

Stefan

-----Original Message-----
From: Moonshot community list [mailto:[log in to unmask]] On Behalf Of Gabriel López
Sent: 23 April 2014 09:00
To: [log in to unmask]
Subject: Re: Attribute filtering / access control with moonshot


Hi,

	Reading the thread one may think that there is a clear understanding of the requirements for this attribute, as Sam pointed out. It also seems clear that if CUI is used then it has to be modified in idP and/or SP, and there is some rejection to include new moonshot-attributes.
	But in order to deploy moonshot/abfab, radius already has to allow/add new moonshot-attributes, such as SAML-AAA-Assertion, GSS-Acceptor-Service-Name, etc,
	So, I don't see any big inconvenient to add a new one to resolve the conflict.

	Best regards, Gabi.
	

El 23/04/14 08:50, Stefan Winter escribió:
> Hi,
> 
>> I think an approach very similar to this would be fine.
>> I think this sort of thing could go well in an APC policy statement.
>>
>> I would prefer that we use a different attribute for the following
>> reasons:
>>
>> * CUI is based on Operator-Name.  It's much easier for us to base
>>   something on Gss-Acceptor-Realm.
> 
> Small correction here: CUI *in eduroam* is based on Operator-Name.
> That's a policy decision taken by eduroam, it is not mandated as per 
> RFC. RFC4372 specifically states:
> 
> "The CUI support by RADIUS infrastructure is driven by the business 
> requirements between roaming entities."
> 
> For eduroam, the business requirement is that values change per 
> Operator-Name. For other uses, you are free to have different 
> requirements. Like Gss-Acceptor-Name :-)
> 
>> I agree that CUI is a useful thing to be using today.  I explicitly 
>> want to break compatibility with that when we move to something pure 
>> moonshot because I don't see a way to maintain that compatibility 
>> without introducing real probabilities of insecurity.  If I'm missing 
>> something and there is a migration strategy that adds value, then 
>> re-use of CUI makes more sense to me.
> 
> I think I need to make a point about eduPersonTargetedID and that it's 
> not as perfect in reality as the spec might lead one to think it is.
> 
> It's all good and fine that the spec forbids re-use and requires 
> persistence. Reality (as in for example simpleSAMLphp-1.12.0) shows 
> that this guarantee is not always implemented. Take a look at 
> simplesamlphp-1.12.0/modules/core/lib/Auth/Process/TargetedID.php
> 
> It first retrieves the scopes, user id and a secret salt from config, then:
> 
>                 $uidData = 'uidhashbase' . $secretSalt;
>                 $uidData .= strlen($srcID) . ':' . $srcID;
>                 $uidData .= strlen($dstID) . ':' . $dstID;
>                 $uidData .= strlen($userID) . ':' . $userID;
>                 $uidData .= $secretSalt;
> 
>                 $uid = hash('sha1', $uidData);
> 
> And then sends that on the wire. I don't see it
> a) storing the generated tuple in a database to prevent a hash 
> collision later in time
> b) asking a database if it has thrown dice badly and did produce a 
> hash collision to a value used earlier in time
> c) checking in a database if the same tuple has resulted in a 
> different value at earlier occasion (maybe due to a different hash, or 
> change of secret salt), and using that older value instead if found
> 
> So, the "MUST NOT" re-use is actually "PROBABLY DOES NOT (depending 
> how lucky we are)" re-use. And the "persistent" nature is more like 
> "mostly persistent, unless something changes".
> 
> This has worked for years without people raising eyebrows (actually, I 
> recall one instance where someone changed their hashes and this 
> resulted in authorisations being lost... so it is an issue of sorts). 
> But it's the reality out there; and I think it's unfair to blame CUI 
> for doing the same.
> 
> Actually, CUI spelling in bold letters that there is no guarantee is 
> at least not as surprising as thinking that there are some, and later 
> not getting those guarantees delivered. :-)
> 
> I'm looking only at one implementation here; one might argue that it's 
> simply a buggy one. It's also a popular one though, so it speaks for 
> some significant amount of deployed reality.
> 
> Greetings,
> 
> Stefan Winter
> 


--
--------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain
Tel: +34 868888504
Fax: +34 868884151
email: [log in to unmask]

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238