1. DJRA3.1 issues Olle Mulmo

2. 1.1 Security architecture definition
“A set of features and services that tackles a set of requirements and can handle a set of use cases”
...yuck...
service == almost anything in this context
Not only enabling stuff, but also disabling stuff
Application sandboxing
Incident response propagation
Logging & auditing
???
<event>, <date> - 2

3. 1.2 Our philosophy Be modular Be agnostic Be standard
To what extent are we considering out-of-the-box interoperability with others?
OMII going the SAML-behind-PERMIS route (GT3.3 callout)
OSG ?
My take on this: Have the hooks ready, but others have to provide plugins for alternatives to proxy certs and VOMS
<event>, <date> - 3

4. Section 2: Background Not sure about this whole section at all
Section 2.1 motivates VO vs federation
Sections 2.2 and 2.3 could go away
2.2 be part of something else
Is it all introduction?
<event>, <date> - 4

5. 3. AUP and SLAs Where do we introduce them?
<event>, <date> - 5

6. 3.3 footnote GGF says < 0.1 MSec for this type of creds (~24 hours)
LCG maximum allowed proxy validity?
<event>, <date> - 6

7. 3.4 Communicate AuthN
Remove
<event>, <date> - 7

8. 3.7 Security Considerations, AuthN
CA operations
Revocation timeliness
<event>, <date> - 8

9. 4. User key management Outline: Missing
4.1 Repudiation Concerns of SIPS services
4.2 Credential Stores
4.3 Security Consideration
Move 4.1 content here?
Missing
Key hygiene
Reference to OTP work
Other?
<event>, <date> - 9

10. 5. Data key management Scenario getting clearer?
The big issue is with long-term storage
Transient or OOB copies not considered as bad
Key servers: M-of-N solutions
Support 1-of-1 but think M-of-N from the start
Can existing software
<event>, <date> - 10

11. 5. Data key management Data has owner (the creator)
Owner creates, registers and manages encryption keys
Data will be enveloped
XML signature?
References to key server(s) locations embedded in envelope
(+) Self-contained, No additional metadata
(-) Data size increase 33% + header
(-) Harder to stream the data encryption/decryption process
<event>, <date> - 11

12. 5. Data key management M-of-N key servers
owners give access control to “community”
metadata
data =
data
Stored using “normal”
data management
owner
<event>, <date> - 12

13. Is this OK? Solves the problem of plaintext long-term data storage
No way to improve this system in the future
Is this OK with app people anyhow?
Issues with key servers
Is it a VO or infrastructural service?
Other concerns?
<event>, <date> - 13

14. 6. AuthZ Problems / issues?
Need to resolve IETF agent/pull/push terminology... do we explain them correctly and are we really using the agent model?
<event>, <date> - 14

15. 7.1 AuthZ framework design
Yuri has issues...
chaining of PIP/PDP
“evidence” vs “context”
...
<event>, <date> - 15

16. 7.2 TODO: Need a volunteer
“Make sure the components here fulfil the requirements and allow us to do as much as we can do with LCG2 today”
<event>, <date> - 16

17. Service AuthZ chains
TODO: Is permit-override the right construct? In general, people use deny-overrides.
A permit-overrides chain will be provided as the default policy-combining algorithm. If a permit decision is found in the chain, further evaluation stops and the user is granted access. More elaborate chains may be implemented in the future allowing a more declarative rule combining configuration where AND, OR, and NOT operators may be utilized on the result of PDPs.
<event>, <date> - 17

18. 8.1 Securing hosted-to-native interface
setuid functionality stressed on in text
Exactly what do we need here?
If we can circumvent reinventing sudo, we should
Lots of (bad) experience in GT development – leverage
<event>, <date> - 18

19. 8.2 Data sandboxing Meta-Q: Is it possible to make sure that
Access via GridFTP
Access via submitted job
Access via DM APIs
...
always generate the same access privileges?
<event>, <date> - 19

20. 8.3 Networking
<event>, <date> - 20

21. 9. Logging and audit No explicit audit tooling Bad?
<event>, <date> - 21

22. 10. Use cases and control flows
Good examples?
<event>, <date> - 22

23. 11. Security Considerations
Have to work with the assumption that the system WILL break or be broken
What should we stress on?
“Cutting of the arm” abilities
incident response propagation
local site policy configuration possibilities
<event>, <date> - 23