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

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66