GGF OGSA SEC WG History & Status

advertisement
GGF OGSA SEC WG History & Status
Presentation Edited and Modified:
Alan J Weissberger
Data Communications Technology
ajwdct@technologist.com
OGSA SEC WG [OGSA= Open Grid Services Architecture]
Co-chairs: Nataraj Nagaratnam, IBM, USA
Marty Humphrey
University of Virginia, USA
GGF9 WG session: Oct 7, 2003, Chicago, Illinois
www.ggf.org
OGSA SEC WG Charter
•“Enumerate and address the Grid Security requirements
in the context of the OGSA”
•“Leverage… WS-Security… and… WS Security Roadmap”
Primary outcome:
 doc
#1: The Security Architecture for Open Grid Services
 doc #2: OGSA Security Roadmap
•Secondary outcome:
 Creation
of new GGF WGs to address “gaps” identified by #2
•Synergistic with other efforts (e.g., OASIS, W3C)???
• But…no incorporation of IETF Security specs (IP Sec or
SSL), no recognition of IEEE 802.1X or knowledge of
IEEE 802.1 Link Security!
www.ggf.org
[GGF6] OGSA Security WG Methodology
1st WG meeting at GGF6 (Oct 2002)
•What requirements are unique/necessary in Grids?
•Do the Architecture/Roadmap cover these?
 If
not, how to extend documents?
•What components need to be built based on these requirements?
•Are any specifications not listed? [AW: IP Sec, SSL, LinkSec?]
•Are any of these “boxes” actively being constructed outside of the
GGF?
 What are these? Where are these? Who are building them?
•Which of the (inactive/pending) boxes are urgent?
 Based on the identified set of specifications that we need to work on, try to
prioritize the list and come up with a dependency/deliverable graph
 Suggest spinning off workgroups based on specs identified to be started
under GGF
www.ggf.org
Current/proposed specs
Building on the WS/ SOAP Foundation
AW Note: This is the IBM-MSFT WS Roadmap for
Security Protocols. Only WS-Security is a standard.
WS-Secure
Conversation
WS-Federation
WS-Authorization
This is a
composable
Architecture
WS-Policy
WS-Trust
WS-Privacy
“only use what
you need”
SOAP Foundation
www.ggf.org
time
WS-Security
OASIS
standard
OGSA Security Components
Intrusion
Detection
Secure
Conversations
Credential and
Identity Translation
(Single SignOn)
Access Control
Enforcement
Audit &
Non-repudiation
Anti-virus
Management
Service/End-point
Policy
Mapping
Rules
Authorization
Policy
Privacy
Policy
Policy Expression and Exchange
User
Management
Key
Management
www.ggf.org
Bindings Security
(transport, protocol, message security)
Trust Model
(authorization,
privacy,
federation, etc)
Secure Logging
Policy
Management
Building Blocks
AppServer
security
Exploiters
Security services
(TBD)
AuthnService
Federation layer
Policy layer
Message Security
Web services
standards
XML security
standards
Protocol layer
security
Platform resource
security
www.ggf.org
Platform (OS)
security
AttributeService
AuthzService
...
AuditService
WS-Authorization
WS-Policy
WS-Trust
xenc:
EncryptedData
ds:
Signature
SOAP
WSDL
XML
Encryption
IIOP
https
CSIv2
Solaris
WS-Privacy
...
...
SecurityToken
Linux
...
XKMS
...
AIX
WS*L
WS-Routing
Assertion
Language
HTTP
NT
(on top of app server)
WS-SecureConversation
WS-Federation
XML
Signature
Application security
OS/400
JMS
(MQ)
z/OS
XACML
Roadmap: Proposed Specs. (1)
Category
Specifications
Naming
OGSA Identity
OGSA Target/Action Naming
OGSA Attribute and Group Naming
Transient Service Identity Acquisition
Translation between
Security Realms
Identity Mapping Service
Generic Name Mapping
Policy Mapping Service
Credential Mapping Service
Authentication
Mechanism Agnostic
OGSA Certificate Validation Service
OGSA-Kerberos Services
Pluggable Session
Security
GSSAPI-SecureConversation
Pluggable Authorization
Service
OGSA-Authorization Service
www.ggf.org
Proposed
Specs.
(2) (2)
Roadmap:
Proposed
Specs.
Category
Specifications
Authorization Policy
Management
Coarse-grained Authorization Policy
Management
Fine-grained Authorization Policy
Management
Trust Policy
Management
OGSA Trust Service
Privacy Policy
Management
Privacy Policy Framework
VO Policy Management VO Policy Service
Delegation
www.ggf.org
Identity Assertion Profile
Capability Assertion Profile
Proposed
Specs.
(3) (3)
Roadmap:
Proposed
Specs.
Category
Specifications
Firewall Friendly
OGSA Firewall Interoperability
Security Policy
Expression and
Exchange
Grid Service Reference and Service Data
Security Policy Decoration
Secure Service
Operation
Secure Service’s Policy and Processing
Service Data Access Control
Audit and Secure
Logging
OGSA Audit Service
OGSA Audit Policy Management
www.ggf.org
Web Services Security Progress Since GGF6
(Oct 2002)
•
Dec 18, 2002: WS-Policy, WS-PolicyAttachment, WSPolicyAssertions, WS-SecurityPolicy, WS-Trust, WSSecureConversation from IBM-MSFT

•
•
July 2003: WS-Federation
OASIS WS SEC docs for public review (Sept 9)

•
•
•
WS-Policy 1.1 et. al. May 28
SOAP Message Security, Username Token Profile, X.509 Cert
Token Profile
XACML ratified as OASIS Open Standard
SAML v1.1 (Sept, 2003)
WS-I creates Basic Profiles for Web Services
www.ggf.org
OGSA SEC WG progress(?) since Oct 2002
•Need to let non-GGF activities progress….
(AW: this is a tacit acknowledgement that there has been
no progress since 1st WG Meeting- Oct 2002)
•Focus is on Authorization (OGSA AuthZ WG)
•OGSA SEC WG is “idle” at the moment= hibernating now
•How to get the OGSA SEC WG active again?
•Should they consider IEEE 802.1 Link Sec?
www.ggf.org
AW: What is missing/ wrong?
1. Dependence on a set of WS consortium specs for
Security protocols. Only one of those has been
Worked in OASIS; others may never be submitted to
an open standards body for peer review and approval
2. What if Grid data types are not compatible with
WS encoding format (SOAP/XML messages)? For
example: floating point numbers, binary data, medical
images, real time video, storage area network data, etc
3. No consideration of when to use IP Sec, SSL, IEEE
802.1x, or even knowledge of IEEE 802.1 Link Security
4. No assumptions as to whether the LAN/MAN link, which
connects servers, is secure or has been authenticated.
www.ggf.org
How to get Link Sec->OGSA Sec WG?
•Objective: Include 802.1 Link Sec in WG “Bindings
Security” (see OGSA Security Components slide) as 1st
layer of transport (below IP and WS bindings- HTTP,
SMTTP, MIME, etc). Defer on IPSec and SSL.Security
Components
•How to do this? [Assuming WG goes into active mode]
- Could establish a liaison between IEEE 802 and GGF
- Convey IEEE 802.1 position on need to consider
LinkSec in Grid network environment
•Individuals may participate in GGF WGs at no charge
- Join email reflector and create a new thread(s)
- Participate in conference calls and interim meetings
•Grid Forge web site will get you to all GGF WGs
http://forge.gridforum.org/
www.ggf.org
Download