Re-thinking
Grid Security Architecture
Yuri Demchenko
SNE Group, University of Amsterdam
Presenting joint work by
Y. Demchenko, C. de Laat, O. Koeroo, D. Groep

E-Science 2008 Conference
10-12 December 2008, Indianapolis, USA

Outline• Background and motivation• OGF: Grid definition and Grid types
 Use case: Grid enabled multidomain Network Resource Provisioning• OGF Standardisation in Grid Security• Use case: Pilot Job submission and execution in Computer/Cluster
Grids• Two basic security models (TCB and OSI/Internet)
 Retrospective overview• Suggested research problems and ideas in Grid Security

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_2

Background and motivation• Experience and result of more than 5 years working on Grid
security Developing, researching, studying, plumbing, fixing Trying to understand all diverse technologies in Grid and Grid security
 Three major projects DataGrid, EGEE, Phosphorus + cooperation with

OSG and Globus• Open Grid Forum (OGF) standardisation contribution (as time andtravel budget allows) Standardisation is the key for Grid interoperability
 Clear gap between (more advanced) practice and (lagging)standardisation• There are not many research on Grid security except someparticular issues of general security
 Is this area not attractive or too complex for academia?

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_3

Gap between standardisation and practice• Standardisation is the key for Grid interoperability• Grid standardisation is coordinated and supported by Open Grid Forum However, some kind of volatility in Grid standardisation• Current standardisation in Grid is narrowly focused on minimum
necessary standards for interoperability
 OGSA standard defines only Grid Security Services model Standardisation is slow and time consuming
 GIN (Grid Interoperability Now) WG at OGF made a good contribution

to resolving urgent issues in 3 years :-)• Large Grid project and infrastructures such as EGEE and OSG are
solving interoperability based on mutual agreement basis
 Practical needs and deadlines produce ad-hoc and stop-gap solutions
 Very limited possibilities to do standardisation and research work

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_4

Evolution of the Grid definition“Anatomy of the Grid” actually described the goal of this new technology at that time:• “Grid systems and applications aim to integrate, virtualise, and manage resources
and services within distributed, heterogeneous, dynamic “virtual organizations”

Open Grid Services Architecture v1.5 (OGSA) (GFD.80, 2006)• “A system that is concerned with the integration, virtualization, and managementof services and resources in a distributed, heterogeneous environment that
supports collections of users and resources (virtual organizations) acrosstraditional administrative and organizational domains (real organizations)”
GFD-I.113 – Technical strategy for OGF 2007-2010, the Grid definition is extended• “Scalable, distributed computing across multiple heterogeneous platforms,
locations, organisations”• Characteristics and goals of Grids in general defined as
Dynamic resource provisioning Resource pooling and sharing Management of Virtualised Infrastructure Self-monitoring and improvement
 Highest quality of service
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_5

Grid types (GFD-I.113) and Security issues• Cluster Grids – that have predominantly homogeneous structureand focused on shared use of high performance computing
resources.
 Problem: Bridging open WS/Grid environment and protected UNIX

executing environment• Collaboration Grids – that are targeted at supporting
collaborative distributed group of people over multiple domains andinvolving heterogeneous resource Problem: Dynamic task/project oriented inter-domain/multi-domainusers and resources association and security context management• Data Center Grids – are actually adding provider specific aspects
in managing resources, users, their associations and supporting
whole provisioning life-cycle
 Customer centric security for dynamically provisioned resources Securing remote (to user) virtualised workspace service environment

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_6

Multidomain Network Resource Provisioning in/for Grid

•

Agent
A
R

IDC/AAA

IDC/AAA

IDC/AA
A

PDP

PDP

PDP

PAP

P
User
Client

PAP

TVS

TVS

TVS
PEP

DC/NRPS

DC/NRPS

DC/NRPSNE

NRPS – Network Resource Provisioning
SystemDC – Domain Controller
IDC – Interdomain Controller
e-Science 2008, 10-12 December 2008

•
•

PEP

NE

Service
(AAA)
plane

PAP

PEP

NE

AAA

Dest
Host
*
Grid
Resr

Control
plane

Appli- Network
catio planenCommon Grid/Netw
provisioning modelInterdomain
AuthN/AuthZ
Dynamic security
association forprovisioned
resources

Provisioning sequences•••

Agent (A)Polling (P)Relay (R)AAA – AuthN, AuthZ, Accounting Server
PDP – Policy Decision Point
PEP – Policy Enforcement Point
TVS – Token Validation Service
KGS – Key Generation Service

Re-thinking Grid Security Architecture

Slide_7

Practical Grid Security –Authentication, Delegation and Trust Management• Grid is for sharing computing resources and other resources in the distributed
heterogeneous environment by means of resource and user virtualisation
Grid Security is built around Virtual Organisations (VO) Using Web Services Security as a base• Authentication in the Grid is based on PKI and can use different (user) credentials(PKI, SAML, Kerberos tickets, password, etc.)• Authorisation is based on VO attributes
Simple AuthZ session management by using Proxy or Short Lived Creds (CLC) together
with CRL• Delegation (restricted and full)Job submission in Grid environment requires (credentials) delegation
 Implemented using X.509 Proxy Certificate (Proxy or PC)
 Proxy is generated by the user client based on user master PKC or Proxy Limited delegation chain (typically not more than 10)• Trust is an important component of PKI based AuthN and Delegation
Trust relations are represented by a certificate chain
 Typical Proxy Certs chain
PKC (DN1, CA) => PC (DN2, (ACa) , PKC) => PPC (DN2, (ACb) , PC) => …
 International Grid Trust Federation GridPMA – http://www.gridpma.org/
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_8

Standardisation in Grid Security by OGF (AuthN/AuthZ)• OGSA Security Profile 2.0 (GFD.138), also known as “OGSA Express
Authentication Profile”• Enable discovery of common security mechanisms and define
extendibility points to accommodate new mechanisms, credentials, etc.

• Secure Communication Profile 1.0 (GFD.132)• Extends WS-I Basic Security Profile and WS-SecurityPolicy 1.2• Provides a framework for writing instant policies for WS/SOAP Message
Level Security (MLS)• Secure Addressing Profile 1.0 (GFD.131)• Format for secure End-Point Reference (EPR)• Group of standards produced by OGSA Authz WG• AuthZ service components and basic operational models• Protocols and messaging WS-Trust, SAML-XACML• VOMS Attribute Certificate and SAML profiles• Ongoing/started work

• Define requirements to AuthN service, including Levels of Assurance(LOA) - Levels of Authentication Assurance Research Group (LOA-RG)

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_9

Pilot Jobs and gLExec on Worker Node (WN)

On success: the site will set the uid/gid to the new user’s job
On failure gLExec will return with an error, and pilot job can terminate or obtain other user’s
job

Source: presentation by David Group at EGEE AH meeting – 20-22 Feb 2008
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

10
Slide_10

Pilot Jobs and gLExec on WN - Abstraction
PilotJob
User

AuthN

UserJob

AuthZ

SCAS

glexecGW

LCAS/
LCMAPS

glexecWN

LCAS/
LCMAPSSCAS – Site Central AuthZ Service
GW – WN gateway

Make pilot job subject to normal site policies for jobs
VO submits a pilot job to the batch system•

the VO ‘pilot job’ submitter is responsible for the pilot behavior•

this might be a specific role in the VO, or a locally registered ‘special’ user at each site

Pilot job obtains the true user job, and presents the user credentials and the job(executable name) to the site (gLExec) to request a decision on a cooperative basis

Preventing ‘back-manipulation’ of the pilot job•••

make sure user workload cannot manipulate the pilot
project sensitive data in the pilot environment (e.g. not revealing job and user ID)
Fare resource sharing if multiple user jobs

Pilot job scenario implemented using policy obligations
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

11
Slide_11

OSI-Security vs TCB Security – Multi-layer vs Multi-levelsecurity
Open Systems and Internet
Open Systems Interconnection (OSI)
Security Architecture•

ISO7498-2/X.800 – Multilayer Security

Independently managed interconnected
systemTrust established mutually or via 3rd party
PKI and PKI based AuthN and key exchange
Concept of the Security Context

Trusted Computing Base (TCB)
Uses Reference Monitor (RM) concept proposed by
J.P.Anderson in 1972
RM property provides a basis for Multi-Level
Security (MLS)•••

Complete mediation
Isolation
Verifiability

MLS models – Bell-LaPadula, Biba, Clark-Wilson

Audit file

CA

Trust
relations
via 3rd party

Objects

Users

Reference
Monitor(policy)
Security kernel,
database

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_12

X.800/OSI Security –Layers vs Services vs Mechanisms

Similar model should be probably
proposed for the WS SOAP based
security services and mechanisms
Upper layers (above application) canbe defined for WS/SOA messaging
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_13

From OSI/Internet to SOA/WSA Security Model
X.800 Security Architecture for Open Systems Interconnection for CCITT applications.
ITU-T (CCITT) Recommendation, 1991
• ISO 7498-2:1989 Information processing systems -- Open Systems
Interconnection -- Basic Reference Model -- Part 2: Security Architecture
Web Services Security Roadmap (2002)• http://www.ibm.com/developerworks/library/specification/ws-secmap/
OGSA Security Model Components (2002-2006)• GFD.80 - OGSA version 1.5,
Section 3.7 Security Services• Re-states Web Services
Security roadmap
WS-Security stds specify
using SOAP header for
security related issues• Considered as orthogonal
to major service

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_14

Developing Consistent Grid Security Architecture –Suggested Issues for Research• Complex Resource Provisioning (CRP) model• AuthZ and Security session and inter-domain security context
management• Policy Obligations – bridging two fundamental security models
 Re-factoring policy-based access control to policy-based object

management• Define/extend security zones model Including AuthN, (Delegation,) AuthZ, (AuthZ Session,) gLExec/Unix• Extending User Controlled Security Domain in Virtualised
Workspace Service (VWSS) with TCPA Leverage Trusted Computing Platform Architecture (TCPA) for basic

Grid use cases, in particular for securing remote virtual execution
environment• Identity Based Cryptography for interdomain trust managementand “trusted introduction”
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_15

Complex Resource Provisioning (CRP) Model
Two use case of the general Complex Resource Provisioning (CRP)• On-demand Network Resource Provisioning• Grid Computing Resource – Distributed and heterogeneous
3 major stages/phases in CRP operation/workflow• Reservation consisting of 3 basic steps
 Resource Lookup
 Resource composition (including options) Component resources reservation (in advance), including combined

AuthZ/policy decision, and assigning a global reservation ID (GRI)• Deployment – reservation confirmation and distributing
components/domain configuration (including trusted keys)• Access (to the reserved resource) or consumption (of the consumable
resource)

Now considering two other stages: “decommissioning” and “relocation”• Topic for future research and discussions• Will allows integrating resource provisioning into the upper layer
scientific workflow in more consistent way
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_16

AuthZ session and Inter-domain security context
management• Type of context and required functionality
 Obligations
 Identity mapping Delegation
 Evidence/context/provenance Support inter-domain advance reservation– With the new proposed pilot token concept (primary use for NRP)

• Current Grid security model/middleware uses Proxy certificate for
implicit session management
 Contains embedded VOMS AC and has limited validity time

• Can be implemented with such mechanisms as
 Proprietary AuthZ ticket and/or token
 SAML credentials

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_17

Proprietary AuthZ ticket format for extended security
context management – Main elements
Required functionality to support
multidomain provisioning scenarios• Allows easy mapping to SAML and
XACML related elements

Allows multiple Attributes format(semantics, namespaces)
Establish and maintain Trust relations
between domains• Including Delegation

Ensure Integrity of the AuthZ decision• Keeps AuthN/AuthZ context• Allow Obligated Decisions (e.g.
XACML)

Confidentiality• Creates a basis for user-controlled
Secure session

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_18

Policy Obligations in Grid – Bridging two security concepts• Policy obligations and access control in Grid
 Account mapping, quota assignment, usable resource
 Environment setup/configuration• Policy Obligation is one of the policy enforcement mechanisms• Obligations enforcement scenarios
 Obligations are enforced by PEP at the time of receiving obligated AuthZ

decision from PDP Obligations are enforced at later time when the requestor accesses theresource or service– Require use of AuthZ assertions/tickets/(restricted proxy?)
 Obligations are enforced before or after the resource or service

accessed/delivered/consumed• XACML policy obligations


Obligations are a set of operations that must be performed by the PEP in
conjunction with an authorization decision [XACML2.0]

 PEPs that conform with XACMLv2.0 are required to deny access unless they

understand and can discharge all obligations returned by PDP• Obligations in policy based management – applied to managed object
 Obligated policy decision & Provisional policy decision Ponder policy language and framework

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_19

Proposed Obligations Handling Reference Model
Resource Site
ServReq(Srv,Oblig2)
ServReq(Srv,An,Az)

1

AzReq(Srv,Subj,Act))

Service/Resource

20

AuthZ Gateway(AuthZ Handler)

Resource
ObligHdlr(OH-R)

19

Rsr Environm,
state

AzResp(Dcsn,Oblig2)

2

PEP

17
18

Obligation
Handler(OH-PEP)

State DB
(UsageController)

16
CVS(extern)

XACMLAzResp(Dcsn,Oblig1)

Context
Handler

XACMLAzReq(S,R,A,E)

3

4

5

WSDL AuthZ PT(SOAP/SSL)

SAMLXACMLReq(S,R,A,E)

SAMLXACMLResp(Decsn,Oblig)

Site Central AuthZ
Service (SCAS)

14

6
SAML-XACMLRRXACMLAzResp(Dcsn,Oblig1)

7
PIP(Ctx Hdlr)

XACMLAzReq(S,R,A,E)

Obligation0 = tObligation=> Obligation1 (“OK?”, (Attributes1 v
Environments1))=> Obligation2 (“OK?”, (Attributes2 v
Environments2))=> Obligation3 (Attributes3 v Environments3)

Note. Obligation1 handling at the SCAS or PDP
side allows stateful PDP/SCAS.

SAML-XACML
RR

15

Generic AuthZ service model

12
13

Obligation
Handler(OH-PDP)State DB
(UsageController)

PEP – Policy Enforcement Point
PDP – Policy Decision Point
PAP – Policy Authority Point
OH – Obligation Handler
CtxHandler – Context Handler(S, R, A, E) – components of the AuthZ request(Subject, Resource, Action, Environment)

11 XACMLAzResp(Dcsn,Oblig0)

8

9

PDP

PAP
10

e-Science 2008, 10-12 December 2008

XACMLPolicy(Target(S,R,A,E),
Rules(S,R,A,E),
Oblig0)Re-thinking Grid Security Architecture

Slide_20

Resource Zone Security model for Grid/Web
Services
Zone RN

Zone RA

Zone R1

IdentP
TA/BA

AzTickt SrvReq

Requestor(User)
SystemZone RAA

FW

Appl
Srvr/
ContnrResource/Service Site

AuthN

AuthZ

User
DB

PEP

AttribAttrA

Zone R0

PDP

Resource
IF/Agent(SRM)

Resource/
Service(DSE)(Access
Control
List)

PAP

PAP

Data

SrvResp AzTickt

Local
FileSyst

UserDB

Internet/Network
AccessSite AuthN(Identity/Attributes)

Site AuthZ(Policy Enforcement)

Resource IF/GW
Resource Manager

Resource(Local File System)

Goal: Consistent Grid systems design and analysis (and e.g. threats analysis)• Defines security zones for the resource/service and user/client
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_21

Client/Requestor Security Zones model for
Grid/Web Services
Zone X

Zone D

Zone C

Zone B

Zone A
Requestor Site Services

Ext Creds
Storage

Req/User
Client/Proxy

Browser/
Application
ServerResource/
Service

Local
Creds
Storage

User Pswd

Temp
Creds
Storage(Cache)Cache(Cookie,
applets,
etc)

Init Pswd
X.509
PKCertExternal Creds
Storage

Local Creds
Storagee-Science 2008, 10-12 December 2008

X.509
PKCertProxy/Client(Temp/Proxy
Creds Storage)

Cache
Cookie/SessionID
Applets

Internet Zone

Re-thinking Grid Security Architecture

Slide_22

Extending User Controlled Security Domain in Virtualised
Workspace Service (VWSS)
Different sides of the Security and Trust• Modern paradigm of remote distributed services and digital content providing
makes security and trust relations between User and Provider more complex• User and Service Provider – two actors concerned with own Data/Content security
and each other System/Platform trustworthiness• Two other aspects of security/trust
Data stored vs Data accessed/processed System Idle vs Active (running User session)High-tech industry use case – Can we trust running analysis on the competitor’s facility?
• Sharing and/or offering unique/complex analytical instruments is limited by not
sufficient protection of the instrument’s hosting environment• Analysis may need to be done on highly confidential specimens• How to make remote environment trusted by even competitors

User
Trust(worthiness)
Security
e-Science 2008, 10-12 December 2008

ProviderSystemSystemData

Data

Re-thinking Grid Security Architecture

Slide_23

Trusted Computing Platform Architecture (TCPA)
Promoted by the Trusted Computing Group (TCG)• Basis for building and managing controlled secure environment for
running applications and processing (protected) content
 https://www.trustedcomputinggroup.org/home• Standards for trusted network, client, server and mobile agent• TMP software stack (TSS) defines API’s for remote access, Identity
Mngnt, PKI, Secure e-mail, file/folder encryption, etc.
• Can be considered as a TCB implementation for distributed computing
environment

TCPA components••••

Trusted Platform Module (TPM)“Curtained memory” in the CPU
Security kernel in the OS and security kernel in each application
Back-end infrastructure of online security servers maintained by hardware
and software vendors

Trusted Network Connect (TNC) – to enforce security policies
before and after endpoints or clients connect to multi-vendor
environment
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_24

User-controlled Virtual Workspace Service (VWSS-UC) –Proposed 3 layer model
PC Platform
TPM

CPU

Grid Virtual WSS(VL)

User Applic Env

TA1
VM/VWSSTA2(UC Appl)

TA0
(TPM)
OS
Hosting
platfrm

VM
Ware

VM1

Applic(UC Srv)

VMn

Applic(UCSrv)

(Xen)

Me
mo
ry
I/O-Network

TA#(UserClient)ApplicUser Client
SrvReqAn/Az
GtewayTPM

AzTicket
Security
Gateway

AuthZSession

WSSReqWssTicket
WSSSession•Trust Anchors: T0 (TPM) – TA1 (VM/VWSS) – TA2 (Application) – TA# (User)•WVSS session and Application AuthZ sessions
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_25

PKI vs Identity Based Cryptography (IBC)
Uses publicly known remote entity’s identity as a public key to send encrypted
message or initiate security session• Idea was proposed by Shamir in 1984 as an alternative to PKI and implementation
by Dan Boneh and Matthew K. Franklin in 2001
• Identity can be email, domain name, IP address• Allows conditional private key generation

Requires infrastructure different from PKI but domain based (doesn’t require
trusted 3rd party outside of domain)• Parties may encrypt messages (or verify signatures) with no prior distribution ofkeys between individual participants• Private key generation service (KGS)
Generates private key to registered/authenticated users/entities
 To operate, the PKG first publishes a master public key, and retains the corresponding
master private key (referred to as master key).
 Given the master public key, any party can compute a public key corresponding to theidentity ID by combining the master public key with the identity value.
• Exchange inter-domain trust management problem to intra-domain trust
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_26

Identity Based Cryptography (IBC) infrastructure operation
when distributing token keys in multidomain NRPUses intra-domain trust
relation in exchange tosimpler inter-domain
trust management

Intra-domain Trust
IBC
KGS
IDC/AAA
PAP

GRI

PDP

T

IBC
KGS
IDC/AAA
PAP

PDP

GRI

T

IBC
KGS
IDC/AAAPAP GRI

PDP

IDC/
AAA

Service
(AAA)
plane

T
Dest
Host

User
Client

PEP

PEP

PEP

DC/NRPS

DC/NRPS

DC/NRPS

NE

NE

NE

Control
plane

Appli- Network
cation plane IBC KGS are setup

TrustInter-domain key
distribution

e-Science 2008, 10-12 December 2008

Simplifies key management
problemAllows flexibility indeploying/configuring
intra-domain network
path/infrastructure
Used at deployment stage

PKI CA

Re-thinking Grid Security Architecture

independently but
publish their publicparameters

Slide_27

Summary and Future Research• Taxonomy of the Grid security issues• Authorisation session and security context management
framework and mechanisms• Security zones model• Contributing to OGF standardisation• Adding new features to Grid middleware and AuthZ frameworks
 GAAA-TK as a basis (developed by University of Amsterdam,

currently in the framework of the EU Phosphorus project)• Security models in Grid and Cloud Computing
 Just as a matter of fashion :-)e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_28

Grids and/vs Clouds – Unconference discussion
The following major issues identified
1. Who is concerned?
Developers, and not managers

2. Clouds are suitable for individuals tasks and Grids are natively
developed to support collaboration and resources and users
federation
3. Grid uses security/trust model with “zero” risk, and Clouds accept“non-zero” risk model because of inherited payment cards
security• Data are part of the Grid infrastructure but not seen as a part of
Cloudse-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_29

Additional materials• Obligations in other AuthZ and policy based management
frameworks• Multi-layer vs Multi-level security models• Identity Based Cryptography

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_30

What’s beyond AuthN/Z services - Application vs Security
service view
• Authentication – first/initial step in accessing a system or handling service
request Creating process, invoking service or object
 Retrieving user attributes
 In general, creating security context for further command/service execution• Authorisation
 Applied to user commands/actions, or managed objects
 Starting/executing

process/job/request
 Creating AuthZ session and AuthZ context– Attribute mapping and policy Obligations• Managing security and AuthZ context
 User AuthZ session – e.g. web browser cookie
 Process environment – e.g. Unix processes environment
 Managed Object property – e.g. job, running code permissions, agents

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_31

Obligations in other AuthZ and policy based management
frameworks
XACML policy obligations definition is originated from the two otherconcepts• Provisional Authorisation model by Kudo (implemented in the IBM’s
XACL) Includes Provisional AuthZ Module (PAM) and Request Execution Module(REM)
 PAM can authorise a request provided the requestor or system (actually REM)
will take some security actions, defined as “provisional actions” prior to therequest execution, e.g. presenting additional credentials, signing privacy
statements, logging events, etc.

• Obligation policies (by Sloman) are defined together with Authorisation
policies as part of the policy based management in distributed systems
 Obligation policies provide simpler way of enforcing state-based policies overmanaged objects– Stateful part of the management policies can be implemented as obligation policies
 Requires trusted manager (that can be treated similar to the Reference

Monitor concept in the Trusted Computing Base (TCB)) Provisions and obligations concepts have been further developed by Bettini etale-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_32

Identity Based Cryptography (IBC) - Operation
Four algorithms form a complete IBE system (asproposed by Dan Boneh and Matthew K.
Franklin):
Setup: This algorithm is run by the PKG one
time for creating the whole IBE environment.
• The master key is kept secret and used
to derive users' private keys, while thesystem parameters are made public. It
accepts a security parameter k (i.e.
binary length of key material) andoutputs:• A set P of system parameters, including
the message space and ciphertext
space M and C, a master key Km(master) .
Extract: This algorithm is run by the PKG whena user requests his private key.
• It takes as input P, Km and an identifier
ID={0,1} and returns the private key D
for user ID.
• Requires strong authentication and outof IBE model scope
Encrypt: Takes P, a message m={M} and
ID={0,1} and outputs the encryption c={C}.
Decrypt: Accepts d, P and c={C} and returns
m={M}e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_33

Multi-Level Security Models
Bell–LaPadula (BLP) data confidentiality model•No write down - No read up

Biba model data and control system Integrity•

No write up - No read down

Clark – Wilson data and process/operations integrity policy (for reliablebusiness operation)• Data and processes integrity criteria





•

Defines enforcement rules E1 – E4 and certification rules C1-C5 forprocedures and entities•

Authentication of all user accessing system
Audit – all modifications should be logged
Well-formed transactions
Separation of duties

TP – transformational procedure and IVP – integrity verification procedure
CDI – constrained data item and UDI - unconstrained data Item

Use as a basis for OS security/integrity policy (e.g., Windows, Linux)

e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_34

Multi-layer vs Multi-level security models
Multi-layer security means thefollowing:
1) layers are defined according to
the OSI reference model, i.e.
data layer, network, transport,
application, what can be mapped
into e.g. network element/node,router/network, application
2) security services and security
mechanisms are defined in sucha way that they can be applied to
network/security layers
independently/orthogonally. Thismeans e.g. that many (thesame) security services can beused at the different networking
layersInternet/network services,client/server, Web services,
service–oriented applications
use multi-layer security model.

e-Science 2008, 10-12 December 2008

Multi-level security means the following:
1) Security levels are defined as:• object/document/resource security
classification level, e.g. public, secret, top
secret, and• subject/user/requestor clearance level thatallows access to this resources.

2) the system corresponds to the Trusted
Computing Base (TCB) model and uses
centralised security management model (akaReference Monitor (RM) in TCB). This can be
explained as similar to OS security.

• RM regulates the access of subjects to objects
on the basis of their security parameters: theaccess privileges (security clearance) ofsubjects, and the protection attributes(classification level) of objects.

3) In application to networked/distributed
applications this means that all traffic iscompletely encrypted and labeled/tokenised,
there is very strict and well defined procedure
for managing and establishing keys.
Typical examples of MLS are operating systemsecurity, military applications’ security.
Re-thinking Grid Security Architecture

Slide_35

Obligations Handling Stages
Obligation0 = tObligation => Obligation1 (“OK?”, (Attributes1 v Environments1))=> Obligation2 (“OK?”, (Attributes2 v Environments2))=> Obligation3 (Attributes3 v Environments3)
Obligation0 – (stateless or template)Obligations are returned by the PDP in a form as they are written in the policy. Theseobligations can be also considered as a kind of templates or instructions, tObligation.
Obligation1 and Obligation 2
Obligations have been handled by Obligation handler at the SCAS/PDP side or at the PEPside, depending on implementation. Templates or instructions of the Obligation0 are
replaced with the real attributes in Obligation1/2, e.g. in a form of “name-value” pair.
• The result of Obligations processing/enforcement is returned in a form of modified
AuthzResponce (Obligation1) or global Resource environment changes• Obligation handler should return notification about fulfilled obligated actions, e.g. in aform of Boolean value “False” or “True”, which will be taken into account by PEP orother processing module to finally permit or deny service request by PEP.
• Note. Obligation1 handling at the SCAS or PDP side allows stateful PDP/SCAS.
Obligation3
Final stage when an Obligation actually takes effect (Obligations “termination”). This is doneby the Resource itself or by services managed/controlled by the Resource.
e-Science 2008, 10-12 December 2008

Re-thinking Grid Security Architecture

Slide_36