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

2. David Groep – WP4 gridification security components and D4.2 – 2002.03.04 - 2 Fabric security components u External (“Grid”) components n issues relating to the three core Grid protocols (GRAM, GSIFTP,GRIP) n network issues (firewall admin, NAT) n fabric authorization interoperability (multi-domain, AAA, co-allocing) u Internal components n authenticated installation services n secure bootstrapping services

3. David Groep – WP4 gridification security components and D4.2 – 2002.03.04 - 3 WP4 Subsystems and relationships (D4.2)

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

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

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

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

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

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

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

11. David Groep – WP4 gridification security components and D4.2 – 2002.03.04 - 11 Bootstrapping a machine on a hostile net New host to be installed CFG Configuration Database Secured http server LCA root cert Operator install disk: -kernel and init -CFG https agent -Signed cert of operator -Protected private key of operator -LCA root certificate CFG data ACLs LCA cert and privkey FLIDS engine Automated CA, Will sign when request Approved by `operator’ 1:Operator boots system 2:agent makes https request using operator credentials 3:https server checks CFG data ACL (operator has all rights), can verify ID of operator using LCA root cert 4: sens config data encrypted using session key 5: host generates key pair (but without a passphrase to protecting private part) 6: request sent to FLIDS engine, signed by operator key (in cleartext) (FLIDS hostname known from CFG data) 7: FLIDS checks signature of operator, and signs request with LCA key. Request DN namespace limited. 8: signed host cert back to host (in clear) 9: host checks signature on cert using the LCA root cert on the boot disk 10: https requests to CFG authenticated with new signed host certificate 11: CFG web server can check hostname in cert against requesting IP address and check ACLs

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