1. WP7: Security Coordination Group (SCG)
David Kelsey (CCLRC-RAL, UK)

2. Outline SCG Objectives SCG Achievements Lessons learned Future
Overview
Authentication
Authorization
Requirements analysis
Lessons learned
Future
Exploitation
Summary

3. SCG Objectives No single work-package to tackle Grid security
But WP2 has a security task and team
Security Coordination Group (SCG) was formed in late 2001
Task 7.4 (TA) in WP7 started in month 13
Mandate of SCG (sub-group of WP7)
To produce the Deliverables of WP7 on Security (task 7.4)
To help coordinate security activities in WPs 1 to 7
To liaise with WP6 CA & Authorization groups (and others)
To contribute to the architecture of the EU DataGrid (ATF)
SCG has larger scope than foreseen in TA task 7.4
At least one representative per middleware WP
Collaboration with DataTAG and national Grid projects

4. SCG Achievements - overview
Authentication: Certification Authorities (CAs) for EDG and others
WP6 Certificate Authorities Coordination Group
DataGrid Security Requirements (D7.5, May 2002)
112 requirements in many areas…
Authentication, Authorization, Auditing, Non-repudiation, Delegation, Confidentiality, Integrity, Network, Manageability, Usability, Interoperability, Scalability, Performance, Robustness
Several joint meetings with WP8, 9 and 10 for VO use cases
Security Design (D7.6, March 2003)
Successful implementation, integration and deployment of many security components
Final Security Report (D7.7, January 2004)
includes comparison with initial requirements

5. Overview of the EDG Security Components (D7.6)CA
proxy cert:
request
dn, cert, Pkey,
VOMS cred.
(short lifetime)
certificate:
dn, ca, Pkey
certificate
VOMS
user
delegation:
re-newal
VOMS cred:
cert+key
request
VO, group(s),
(long lifetime)
MyProxy
role(s)
delegation:
cert+key
(short lifetime)
proxy cert
proxy cert
proxy cert
proxy cert
proxy cert
auth
auth
auth
auth
auth
TrustManager
TrustManager
mod_ssl
GSI
GSI
authz
pre-process:
pre-process:
authz
parameters->
pre-process:
WebServices Authz
parameters->
obj.id + req. op.
parameters->
LCAS
dn,attrs,acl, req.op
obj.id + req. op.
obj.id + req. op.
dn,attrs,acl, req.op
->yes/no
->yes/no
map
map
dn -> DB role
authz
LCMAPS
authz
authz
dn -> userid, krb ticket
obj.id -> acl
dn,attrs,acl, req.op
GACL:
GACL:
obj.id -> acl
obj.id -> acl
doit
->yes/no
dn,attrs,acl, req.op
dn,attrs,acl, req.op
doit
->yes/no
->yes/no
doit
doit
doit
coarse grained
fine grained
fine grained
fine grained
coarse grained
(e.g. Spitfire)
(e.g. RMC)
(e.g. GridSite)
(e.g. SE, /grid)
(e.g. gatekeeper)
Java
web C

6. Authentication A PKI with Certification Authorities (CAs) for
EU DataGrid
EU DataTAG
EU CrossGrid
LHC Computing Grid project (LCG)
Global service for particle physics
Includes North America and Asia
The same CA’s also used by many national projects
France, Italy, Netherlands, Nordic countries, Spain, UK, …
This PKI is used for cross-authentication by applications spanning several Grids

7. DataGrid PKI History Started planning the PKI in Autumn 2000
First meeting of WP6 CA group in December 2000
Requirements
Use Globus Toolkit and GSI (X.509 PKI)
Users – require single sign-on
One identity certificate for use in many different Grids
Only support Grid Authentication
No long-term encryption, digital signing, …
Pre-existing Certification Authorities in some countries
For other purposes and/or larger communities
Czech Republic, France, Italy, Portugal, UK,…

8. Early PKI Decisions Keep Authorization and Authentication separate
Authorization not stable enough and too VO-specific
One Grid electronic identity
For use in many Grid projects (EU and national)
For user convenience
Would one CA be enough? NO
Hierarchy or cross-signing? NO
What is the most appropriate scale?
One CA per country
Define “minimum requirements” for EDG-approved CA’s

9. CA Approval process
“Minimum requirements” document
Evaluation of policy and procedures (CP/CPS) and presentation to WP6 CA meeting
no physical audit
Concentrate on
Registration Authority procedures
Operational procedures of the CA
Unique Distinguished Names within the whole PKI
Concerns about scalability
Regional PMAs
CAs could be run by NRENs

10. Approved CAs Certification Authorities “Catch-all” operated by CNRS
21 CAs span:
Europe
North America
Asia
~ 3000 certificates issued
“Catch-all” operated by CNRS
Under consideration
Belgium
Hungary
Israel
Japan
Pakistan
ArmeSFo
Armenia
HellasGrid
Greece
ASGCCA
Taiwan
INFN
Italy
CERN
Switzerland
LIP
Portugal
CESNET
Czech Rep.
NIKHEF
Netherlands
CNRS
France
NorduGrid
Nordic Countries
CyGrid
Cyprus
PolishGrid
Poland
DOE
USA
Russia
FNAL
SlovakGrid
Slovakia
GermanGrid
Germany
Spain
GridCanada
Canada
UKeScience UK
Grid-Ireland
Ireland
The number of certificate authorities continues to expand. The CA coordination group will move under the auspices of EGEE. The overall coverage of users is significantly higher as CNRS CA signs requests for several countries and ASGCCA also covers China.

11. Authorization (AuthZ) overview
The Authorization model
Build on the GSI-based authentication
Global AuthZ by one or more VOs
Local site/resource-based AuthZ
Early DataGrid VO management system: “VO-LDAP”
New AuthZ system: VOMS
policy or ACL based local access control
coarse and fine grained solutions
DataGrid security components:
GSI/LCAS/LCMAPS for C/C++ services
edg-java-security for Java web services
mod_ssl/GACL for Apache based web services
Services can either use the grid-mapfile or use VOMS credentials
Modified MyProxy service for credential renewal (incl AuthZ)

12. “Authorization Directory”
VO-LDAP
grid-mapfile generation
CN=Mario Rossi
o=xyz, dc=eu-datagrid, dc=org
CN=Franz Elmer
CN=John Smith
Authentication Certificate
ou=People
ou=Testbed1
ou=???
o=testbed, dc=eu-datagrid, dc=org
CN=Franz Elmer
ou=People
CN=John Smith
VO Directory
“Authorization Directory”
mkgridmap
grid-mapfile
local users
ban list

13. Virtual Organization Membership Service (VOMS)
Joint development with DataTAG
Issues signed credentials to prove group/role/VO membership
Moved to standard RFC 3281 Attribute Certificate format
The AC is included as a non-critical extension of the user’s proxy certificate
Backwards compatible
Core service: standalone daemon for the “login”
Administered by the VO manager
Administrative service: web service with API, command line and web user interface
for administration and registration
VOMS migration tools for grid-mapfiles and VO-LDAP servers

14. Local Site Authorization (WP4)
Local Centre Authorization Service (LCAS)
Handles authorization requests to local fabric
decisions based on user proxy certificate and job specification
supports grid-mapfile mechanism.
Plug-in framework (hooks for external authorization plugins)
allowed users, banned users, available timeslots, GACL
plugin for VOMS (to process authorization data)
Local Credential Mapping Service (LCMAPS)
provides local credentials needed for jobs in fabric
mapping based on user identity, VO affiliation, local site policy
plug-ins for local systems (Kerberos/AFS, LDAP nss)

15. edg-java-security (WP2)
Trust manager
GSI compatible authentication (supporting proxy chain)
Adapters to HTTP and SOAP
Currently deployed for Tomcat4
VOMS credential verification
Authorization Manager
Authorization and mapping for Java services
Plug-in framework for maps: database, XML file and for backward compatibility: grid-mapfile
Handles VOMS attributes

16. proxy cert (short life) authz cert (short life)
VOMS “Login” CA
low frequency
high frequency
The VOMS credential is backward compatible with GSI
user
user cert (long life)
VO-VOMS
voms-proxy-init
proxy cert (short life)
user requests a certificate (once in every two-three years)
user sends the requests to the CA, which sends back the signed certificate
conversion to browser digestable PKCS12 format
registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!)
generats a proxy certificate (24 hours lifetime)
host/service requests a certificate
host/service sends the requests to the CA, which sends back the signed certificate
retrival of the trusted CA certificates and their CRLs (automatically updated every night/week)
generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week)
user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently)
Real life example:
The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country.
The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life.
edg-voms-proxy-init -voms iteam
/tmp/x509_up<UID> (normal proxy location)
backward compatible proxy format
authz cert (short life)

17. Old-style GSI Service CA service
low frequency
high frequency
host cert (long life)
service
Backward compatible on the service side
crl update
VO-VOMS
VO-VOMS
Old-style services still use the gridmap-file for authorization
gridftp
EDG 1.4.x services
EDG 2.x service in compatibility mode
no advantage, but everything works as before...
mkgridmap
VO-VOMS
user requests a certificate (once in every two-three years)
user sends the requests to the CA, which sends back the signed certificate
conversion to browser digestable PKCS12 format
registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!)
generats a proxy certificate (24 hours lifetime)
host/service requests a certificate
host/service sends the requests to the CA, which sends back the signed certificate
retrival of the trusted CA certificates and their CRLs (automatically updated every night/week)
generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week)
user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently)
Real life example:
The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country.
The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life.
gridmap-file
VO-VOMS
GSI

18. 1. VO affiliation (AccessControlBase)
Job Submission
low frequency
high frequency
host cert
information system CE
user
1. VO affiliation (AccessControlBase)
user cert
4. CEs for VOs in authz?
WMS
VO credential is used by the resource broker to pre-select available CEs.
3. job submission
proxy
user requests a certificate (once in every two-three years)
user sends the requests to the CA, which sends back the signed certificate
conversion to browser digestable PKCS12 format
registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!)
generats a proxy certificate (24 hours lifetime)
host/service requests a certificate
host/service sends the requests to the CA, which sends back the signed certificate
retrival of the trusted CA certificates and their CRLs (automatically updated every night/week)
generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week)
user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently)
Real life example:
The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country.
The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. VO
authz
MyProxy server
2. cert upload

19. authentication & authorization info
Running a Job
VO credential for authorization and mapping on the CE.
LCAS: authorization based on (multiple) VO/group/role attributes
LCMAPS: mapping to user pool and to (multiple) groups
default VO = default UNIX group
other VO/group/role = other UNIX group(s)
host cert
MyProxy server CE
cert (long term)
voms-proxy-init
WMS
proxy
user requests a certificate (once in every two-three years)
user sends the requests to the CA, which sends back the signed certificate
conversion to browser digestable PKCS12 format
registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!)
generats a proxy certificate (24 hours lifetime)
host/service requests a certificate
host/service sends the requests to the CA, which sends back the signed certificate
retrival of the trusted CA certificates and their CRLs (automatically updated every night/week)
generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week)
user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently)
Real life example:
The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country.
The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. VO
2. job start
authz
1. cert download
authentication & authorization info
LCAS/ LCMAPS

20. Requirements analysis (EDG 2.1)
Only consider EDG requirements here (longer term aims: see D7.7)
Success 
Mostly satisfied 
Not satisfied 
FS= fully, PS=partially, NS=not… satisfied
“Partially” means not all WPs and/or not all languages
Number FS PS NS
Authentication 13 11 1
Authorization 23 8 9 6
Confidentiality 14 3 10
Non-Repudiation
Usability
Interoperability 2
Other areas 15 4
Total 74 28 22 24

21. Requirements - comments
Authentication
The EDG PKI is a major success
Except for 1 “NS” (revocation in < 10 minutes)
Authorization
Another major success of the project
But not all components are fully deployed and/or configured
“NS” requirements are related to
Assigning job priorities and pre-checking fine-grained access (WP1)
Authorization of resources rather than users (WP10)
Confidentiality
“NS” requirements are related to (mainly WP10)
Encryption/decryption and fine-grained access control to files/keys
Concealing information about users and audit data
The DataGrid design and implementation is aimed at meeting all requirements and prototyping secure services
towards industrial strength

22. Bio-medical confidentiality
Requires fine-grained AuthZ on files and encryption keys (in RMC)
A solution is described in D7.6 design document
Many components implemented and deployed
Shown to work independently
Sufficient to fulfil some application requirements
Only partial integration into EDG release 2.1 was possible
Difficult to integrate security into existing systems
Difficult priority decisions were taken by the project management
Stability more important than functionality
We have successfully integrated fine-grained AuthZ in Job submission
fine-grained AuthZ on SE and RM not yet deployed/configured
Medium-grained AuthZ (group level) on files is achievable
But fine-grained AuthZ requires more development and integration

23. Lessons learned Be careful collecting requirements
In hindsight, the D7.5 requirements were rather ambitious
The expectations of the applications were documented but there was not sufficient analysis of the difficulty of integration
Security must be an integral part of all development
from the start
Larger scope SCG started late (but as defined in the TA)
Building and maintaining “trust” between projects and continents takes time
Integration of security into existing systems is complex
There must be a dedicated activity dealing with security
EGEE planning has already benefited from our experience

24. Future work Authentication Authorization Restricted delegation
Continue and expand the EDG PKI
Secure credential management: online services, SmartCards
Faster and more robust certificate revocation, e.g. OCSP
Authorization
Fuller use of VOMS AuthZ credentials
Mutual AuthZ: VOs should approve resources and services
Convergence with GGF standards (XACML, SAML, …)
Restricted delegation
Confidentiality
Integrate and deploy the proposed solution for WP10
Build on DataGrid design and components for industrial strength
PKI/SSL authentication, standards-based authorization, ws-security,…

25. Exploitation Authentication Security Policy issues
The CA infrastructure will continue
Discussions started with DEISA and SEEGRID
EGEE will manage the EDG PKI in a new EU PMA
LCG driving the requirements for global physics authentication
Grid CAs to be registered in new TERENA CA repository (TACAR)
eInfrastructure and eIRG meetings (Ireland) to consider this topic
A general EU Grid PKI infrastructure?
DataGrid people will continue in EGEE and GGF
Security Policy issues
DataGrid people already active in defining LCG policy and procedures
Important input to EGEE and eIRG

26. Exploitation (2) Authorization Publication of the work is ongoing
EDG components and people will continue in EGEE, LCG and other projects
VOMS is part of LCG-2
The HEP applications need roles and groups
Integration with SlashGrid, ACLs (GACL) and GridSite
Joint work with UK GridPP, using VOMS and working with PERMIS team
Work in GGF security area groups will continue
EDG providing reference implementations in OGSA-AuthZ
WS-security, VOMS, LCAS, GridSite, SlashGrid etc
XML policy, XACML, VOMS Attribute Certificates, SAML
Will continue to drive and track standards
Publication of the work is ongoing

27. Summary Authentication Authorization Future work & exploitation
We have built a large Grid PKI used by many EU projects
strong links to North America and Asia
support for global applications
Authorization
DataGrid has made major contributions in this area
Established the VO as an important security domain
Future work & exploitation
Much still to be done
For example in bio-medical confidentiality
The people will continue in EGEE and elsewhere
DataGrid security architecture, design and components will be used