WP4 Gridification Security Components in the Fabric overview of the WP4 architecture as of D4.2

1. WP4 GridificationSecurity Components in the Fabricoverview of the WP4 architecture as of D4.2 for Gridification Task: David Groep hep-proj-grid-fabric-gridify@cern.ch

2. Fabric security components • External (“Grid”) components • issues relating to the three core Grid protocols (GRAM, GSIFTP,GRIP) • network issues (firewall admin, NAT) • fabric authorization interoperability (multi-domain, AAA, co-allocing) • Internal components • authenticated installation services • secure bootstrapping services

3. WP4 Subsystems and relationships (D4.2)

4. Job submission protocol & interface • Current design • Client tools connect to gatekeeper • GRAM (attributes over HTTPS) • Gatekeeper does authentication, authorization and user mapping • RSL passed to JobManager • Identified design differences • authorization and user mapping done too early in process • Identical components • Protocol must stay the same (GRAM) • Separation of JobManager (closer to RMS) and GateKeeper will remain • Issues: scalability problems with many jobs within one centre (N jobmanagers) authorization cannot take into account RMS state (budget, etc.)

5. Current design: Authorization and user mapping are combined (see next slide) Local local site policy in authorization Identified design points new component, taking concepts from generic AAA architectures coordinate with AuthZ group and GGF Identical components towards generic AAA architectures/servers(LCAS will be like an ASM) distributed AAA decisions/brokering concepts from new SciDAC/SecureGRID/AAAARCH work Authorization and AAA Accounting framework yet to be considered…

6. Credential Mapping • Current design: • Authorization and user mapping are combined • Gatekeeper map file with GridMapDir (on connection establishment) • Kerberos by external service (sslk5) • Identified design points • move to later in the process (after the authorization decision) • Extend for multiple credential types… • Identical components • gridmapdir patch by Andrew McNab • sslk5/k5cert service • Issues in current design • mapping may be expensive (updating password files, NIS, LDAP, etc.)

7. Local security service (FLIdS) • Current design: • Component is not Gridcomponent→not there • Technology ubiquitous (X.509 PKI) • Identified design points • Policy driven automatic service • policy language design (based on generic policy language or ACLs) • Identical components • PKI X.509 technology (OpenSSL) • use by GSI and HTTPS • Issues: • mainly useful in untrusted environments (e.g., outside a locked computer centre) • prevents CA overloading… Non-critical for grid servicesneeded for intra-fabric security

8. Information Services (GriFIS) • Current design: • MDS2.1: LDAP protocol with back-endsor F-Tree • Modular information providers • Identical components • NO fundamental changes by WP4 • GIS/Ftree and/or GMA/R-GMA or … • Just More information providers • Correlators between RMS, Monitoring and CDB (internal WP4 components) • Issues design • How will global scheduling decisions be made (AAA-wise)? • distributed AAA based on new standard • future for LCAS

9. Network access to large fabrics • Current Globus design • Is not in scope of Globus toolkit • Identified issues • Needed component for large farms • Needed for bandwidth provisioning,brokerage & selective firewall adminning • Farm nodes not visible from outside! • Identical components • 0st order: no functionality • 1st order: IP Masquerading routers • 2nd order: IP Masq & protocol translation (IPv6 → IPv4 and v.v.) • later: use of intelligent edge devices, managed bandwidth (and connections) per job, AAA interaction (with LCAS)

10. Intra-fabric security issues • How to install a node in an untrusted network environment • distribution of sensitive config data (SSH host keys) • integrity of configuration data • bootstrapping problem! • Secure install scenario requires a local quasi-CA(FLIdS = Fabric-Local Identity Service) • See use-case on next slide (don’t be terrified by the arrows…)

11. CFG Configuration Database LCA root cert CFG data ACLs 11: CFG web server can checkhostname in cert againstrequesting IP addressand check ACLs Secured http server 7: FLIDS checks signature of operator, and signsrequest with LCA key. Request DN namespace limited. 3:https server checks CFG data ACL(operator has all rights), can verify IDof operator using LCA root cert FLIDS engine 4: sens config data encryptedusing session key LCA cert and privkey Automated CA, Will sign when request Approved by `operator’ 2:agent makes https requestusing operator credentials New host to be installed 6: request sent to FLIDS engine,signed by operator key (in cleartext)(FLIDS hostname known from CFG data) 10: https requests to CFGauthenticated with newsigned host certificate 5: host generates key pair(but without a passphrase to protecting private part) 9: host checks signature on cert using the LCA root cert on the boot disk 8: signed host cert back to host (in clear) • Operator install disk: • kernel and init • CFG https agent • Signed cert of operator • Protected private key of operator • LCA root certificate 1:Operator boots system Bootstrapping a machine on a hostile net

12. Component Summary • LCAS • comprehensive local authorization taking RMS issues into account • accepted jobs WILL run • should evolve into an “ASM” to allow inter-domain co-allocation • LCMAPS • take as much as possible from existing gridmapdir work, generalize for K5 • FabNAT • 1st goal: solve addressing issue; later: managed firewalls etc; allow plug-in to LCAS • FLIdS • build secure fabrics on an insecure network (smaller uni’s etc.), prevent CA overload • Key is to stay compatible and interoperable! • GRAM protocol (& RSL) [Globus, GGF] • Information framework (GRIP, GMA, R-GMA, …) [Globus, GGF and EDG WP3] • All work on security in AAAARCH, PKIX, GGF sec. area, SecureGRID