Hi, the CUI study was updated and selected for production use later. You can have a look at chapter 3 of
http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-09-213-DJ3_1_1_RadSec_Standardisation_and_Definition_of_eduroam_Extensions_20091106091343.pdf and an addendum in section 3.1 of the follow-up report http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-10-304%20DJ3.1.2,1%20%20Roaming%20Developments%2024FEB11.pdf In that document, we also introduced a privacy-preserving log mechanism that works even if RADIUS/TLS with dynamic discovery is used (and hence there is no RADIUS server logs from a clearing house to parse any more). It's called "F-Ticks" (the Federated TICKer system) and you can read up on it in section 3.5 of that report. It very roughly works along the lines of SIP common log format (but I didn't know that one by the time I wrote up the F-Ticks structure). Greetings, Stefan Winter P.S.: yes, our URL length and PDF file names ... underperform. That's understood. :-) On 25.02.12 18:43, Klaas Wierenga wrote: > In the meanwhile perhaps worth looking at > http://www.eduroam.org/downloads/docs/GN2-08-243-DJ5-4-1-2_Advanced_Technologies_Overview_Second_Edition_20090204080004.pdf > section 2.2 on the use of pseudonyms in the Chargeable User Identifier > attribute. > > Klaas > > Sent from my iPad > > On 25 feb. 2012, at 18:24, Klaas Wierenga <[email protected]> wrote: > >> Fwiw, I have agreed with Stefan Winter and Tomasz Wolniewicz to write an >> informational draft on the design of eduroam, including how logging is >> handled using pseudonymous identifiers, now if only we manage to find some >> time to write it up..... >> >> Klaas >> >> Sent from my iPad >> >> On 25 feb. 2012, at 14:07, Stephen Farrell <[email protected]> wrote: >> >>> Well, regardless of venue, seeing a few drafts >>> that showed us good ways to handle privacy in IETF >>> protocols would be useful IMO. >>> >>> For example, the IESG recently reviewed the SIP >>> common log format. [1] As part of the review I asked >>> if the WG had considered privacy and the answer was >>> essentially no and nor had they thought about any >>> privacy-friendly ways to handle identifiers in >>> log files that might be exchanged between domains. >>> >>> It'd have been great to be able to say "go look >>> at RFC xxxx where it shows you ten possible ways >>> to do that." >>> >>> S >>> >>> [1] http://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/ >>> >>> >>> On 02/24/2012 10:33 PM, David Chadwick wrote: >>>> Hi Klaas >>>> >>>> I agree with you. It might that IRTF is more appropriate for some work >>>> items, but this is something the ADs can decide >>>> >>>> regards >>>> >>>> David >>>> >>>> On 24/02/2012 18:56, Klaas Wierenga wrote: >>>>> Hi Hannes, >>>>> >>>>> Perhaps I am mistaken, but it seems that there is a bit too much >>>>> focus on what is possible with *todays* technology. I would rather >>>>> like to focus on properties we would *like* to see, and possibly work >>>>> on those in the IETF (but most likely other fora).... But still that >>>>> is probably not for a terminology document, but I do think we need to >>>>> be able to express all desirable properties using the terms from the >>>>> terminology document. >>>>> >>>>> Klaas >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 24 feb. 2012, at 19:47, Hannes >>>>> Tschofenig<[email protected]> wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> this specific case seems to have pretty tough privacy requirements: >>>>>> you want to avoid having relying parties to know who the identity >>>>>> providers are AND also want to avoid letting identity providers >>>>>> know which relying parties data subjects talk to AND finally you >>>>>> want to avoid collusion among relying parties to learn more about >>>>>> data subjects. >>>>>> >>>>>> It is interesting to see how a set of privacy requirements produce >>>>>> a system that has questionable privacy properties... >>>>>> >>>>>> Ciao Hannes >>>>>> >>>>>> PS: Whenever one talks about trust it is useful to mention 'who is >>>>>> trusted by whom to do what'. >>>>>> >>>>>> On Feb 22, 2012, at 12:37 AM, David Chadwick wrote: >>>>>> >>>>>>> >>>>>>> On 20/02/2012 17:16, Rhys Smith wrote: >>>>>>>> On 15 Feb 2012, at 06:06, [email protected] >>>>>>>> <mailto:[email protected]> wrote: >>>>>>>> >>>>>>>>>> Well, even more, the idp should not know at all which rp I >>>>>>>>>> talk to in the first place. >>>>>>>>> It is a strong privacy reqirement. Ｉdoubt solutions in ABFAB >>>>>>>>> can provide this feature. >>>>>>>> Yes, ABFAB cannot do this natively. >>>>>>>> >>>>>>>> Though there are always ways around this. SAML cannot do this >>>>>>>> natively either, but the Cabinet Office (UK government) is in >>>>>>>> the middle of setting up a national federated infrastructure >>>>>>>> with exactly this properly, which it achieves by having a >>>>>>>> gateway in the middle which mediates all traffic. >>>>>>> Hmmm. the design of this is very questionnable (and opaque). Full >>>>>>> trust must be given to the gateway, without any assurance that it >>>>>>> is trustworthy. It is not even mentioned in the trust assurance >>>>>>> document. >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Note that this privacy requirement may well be asymmetric - >>>>>>>> there may be a difference between the IdP not being able to >>>>>>>> know about which RP the user is using, and the RP not knowing >>>>>>>> which IdP the user came from... >>>>>>>> >>>>>>>> R. -- Dr Rhys Smith Identity, Access, and Middleware >>>>>>>> Specialist Cardiff University& Janet - the UK's education and >>>>>>>> research network >>>>>>>> >>>>>>>> email: [email protected]<mailto:[email protected]> / >>>>>>>> [email protected]<mailto:[email protected]> GPG: 0xDE2F024C >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ ietf-privacy >>>>>>>> mailing list [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>>>>> -- >>>>>>> >>>>>>> ***************************************************************** >>>>>>> >>>>>>> >>>> David W. Chadwick, BSc PhD >>>>>>> Professor of Information Systems Security School of Computing, >>>>>>> University of Kent, Canterbury, CT2 7NF Skype Name: >>>>>>> davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: >>>>>>> +44 77 96 44 7184 Email: [email protected] Home Page: >>>>>>> http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research >>>>>>> Web site: >>>>>>> http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust >>>>>>> key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 >>>>>>> >>>>>>> ***************************************************************** >>>>>>> >>>>>>> >>>> _______________________________________________ >>>>>>> ietf-privacy mailing list [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>>>> _______________________________________________ ietf-privacy >>>>>> mailing list [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy > _______________________________________________ > ietf-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-privacy _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
