Choose timezone
Your profile timezone:
Token Trust & Traceability WG
→
Europe/Zurich
513/R-068 (CERN)
Description
Fortnightly for the risk assessment season.
Token Tracebility and Traceability WG
https://codimd.web.cern.ch/QjWFw81TRYypacVM81o_Wg?view
# TTT 11/11/25
Attending: Donald, Maarten, Mischa, Matt
Apologies: DaveK, Linda
## From last time
In an epic 90 minute session that still managed to overrun, we tackled the 6 different workflows and TR-4.
ML had a thought about last assessments, had 2 use cases that should be split further - ordinary users vs power users.
Ordinary users have a larger surface area, but probably don't have a lot of power. Few power users, somewhat less likely to get hacked. But if they do it's really bad.
Our current guidence is use the worst case - so we have high likelihood x high risk
Note 4e and 4f - very high (4e especially)
Need to re-assess
Action on Matt to split the rows for next time to enable a reassess.
## Last Stretch for the Preliminary Risk Assessment
Try the same with TR-5 - we'll likely only get part way through.
5a - Note that Storage should be added to the assets at risk
ML gives description, including benefits of long lived tokens with FTS.
Some discussion on impact, MS goes high due to the long lived. ML discusses narrow scope of token.
MS mentions scale of the work, hard to tackle mid way through.
DC notes that if implimented correctly need a lot of damage to do significant damage, and despite revocation there are other admin actions that could be done.
(Matt to fix the formatting on column F)
Onto 5b - short lived FTS style tokens.
Note storage.modify scope is currently needed.
MS makes a comment about the lack of revocation? Surely can revoke the refresh.
ML notes no workflow to do this at the moment, needs to be done by an admin.
MS - if there's no way of revoking a refresh token there's no point of a refresh.
ML - the FTS operated in this way has a lot more power, so worry if hacked.
IAM devs discovered have more "power" then needed, so disabled the ability to upscope tokens in future versions.
(will dig up notes)
Same liklihood as for 5a.
MS - notes difference between compromise of token using service and a leaking/theft of tokens.
Discussion of FTS workflows.
MS - in case of a service hack, no difference between the two.
Matt goes high. ML points out that pre-knowledge of the namespace required for an effective abuse. Will add this to the spreadsheet.
DC - again if multiple compromise will be detected by security monitoring.
Some discussion, but settle on a 3.
ML- 5a and 5b trade one risk for another.
Notes for future voting "3" is always a safe vote to cast. But need to avoid this.
MS - revocation is a powerful tool, that should be used. One of the reasons we have the flows, not having them impacts risk. Worried that giving a number would not encurage, say, use of storage. Single number can't paint the picture.
ML - correct summary, not a hard science, lots of guesstimating. Room for improvement. Hope for the troublesome cases to "bubble" to the top. But part of a complete picture.
Preliminary report sometime in December (hopefully) - report will incorperate spreadsheet into words.
Matt notes that impact will be community dependent
ML - indeed, this is quite WLCG/HEP
DC - numbers indeed aren't most important, discussion good.
## Presenting to the EGI CSIRT
Was going to discuss our risk assessment work, tackling the issue "per workflow".
## AOB/Next Meeting
Next meeting Friday 28th (no meeting in the regular slot this month)
Any more thoughts on CHEP? Make decision on this next meeting (which will give us 3 weeks to write and submit an abstract).
Matt will circulate something in the list, and ask Tom if he'll be able to present.
There are minutes attached to this event.
Show them.
