[ggf-ogsa-sec-wg] OGSA security use cases and requirements discussions: Monday, May3, 3pm PST

[Frank Siebenlist <franks@mcs.anl.gov>]

Dear colleagues,

We would like to start a series of telcons to discuss a number of security 
related use cases that we face in the Grid community, which have not been 
addressed adequately through available standards and solutions.

The idea is that the outcome of these discussions will be documented such that a 
summary could be integrated in the OGSA Architecture document and a more 
extended version could possibly be used by dedicated working groups as a 
stepping stone to provide real solutions.

The first telcon will be on Monday, May 3, 3-5pm PST.

The dial-in number for Monday is +1-866-639-4741 (Free) and
+1-574-935-6703 (Toll) and PIN is 8980700.

This is a time slot normally used by the OGSA working group. Any scheduling of 
follow-on telcons will happen on that call or on the mailing lists.

The first telcon will be used to discuss the format of deliverables, short 
discussion of the suggested topics, enlisting of volunteers to focus and work on 
a certain topic, scheduling of next telcons, etc.

For follow-on discussions, we suggest that all emails are cross-posted to both 
the ogsa-wg (ogsa-wg@ggf.org) and ogsa-security (ogsa-sec-wg@gridforum.org) 
mailing lists as we want to ensure/encourage the participation of 
non-security-geeks who can keep "us" on the right track.

The following is a strawman for topics that can be addressed during this effort. 
Note that none of this is cast in stone, all is open for discussion, while 
suggestions for additional topics are more than welcome.

The following is a list of brief descriptions of security related use cases that 
we would like to explore with the security focus/design team over the coming months:

--------------------------------------------------------------------------------

1* No long-term secrets on the workstations plus two factor authentication

A number of deployment sites have the policy that no long-term secrets are 
allowed to be stored on the workstation. Furthermore, 2-factor authentication 
is/will-be mandated.
This requires authentication protocols based on password and One-Time-Password 
schemes.
What are the available solutions? What kind of crypto-protocol to use for shared 
secrets? What kind of ws-protocols are suitable? What is lacking and requires 
attention?


2* Simplified configuration of user credentials, trust-roots, base-policy, etc.

The configuration of workstations and servers is too complicated. Users are 
required to go through too many error-prone steps.
There are efforts that will use username/password authentication to bootstrap 
the complete setup/provisioning of credentials/trust-roots/base-policy.
How would/should this work? What are the limitations? Maybe this has to be done 
per VO?


3* (High speed) Firewall Traversal

Firewall, NATs, and other network hurdles make it difficult for requesters to 
reach services inside, and application-level routing elements seems needed.
Furthermore, for high speed connections, the firewalls have to be opened on the 
transport level.
The WS-protocols lack standardized soap-level routing. WSRF and WS-Addressing 
are "silent".
We need a detailed understanding of the access policy that allows traffic to 
traverse these routers which may each have their own policy restrictions.


4* Centralized Path Validation

The validation and interpretation of certificates and the associated 
configuration of trust-roots is a big issue for deployments and operation.
Many different kinds of certs (x.509, proxy-certs) with zillions of options, 
different chains and bridges, different sets of trust-roots that change over 
time, different revocation policies and mechanisms, etc.
In what cases does it make sense for a site to centralize the the path 
validation processing, and how much can be done?


5* Communication of authentication credentials

Authentication information can be exchanged when parties interact, like with 
SSL/TLS. In some cases, you would like to optimize and have the security 
information, like certs, communicated before the interaction.
What are the options to communicate? How to decorate the EPR?
This doesn't have to be "secure", because we do a separate authorization step - 
in what cases could we combine those?


6* VO life-cycle management and interactions within a VO-context

VOs are created, destroyed, have owners, and require the management of users, 
resources and authorization policy on a per VO basis.
What common, core services can be identified?
As was observed during discussions, requesters and services may be part of 
multiple VOs at the same time, and the context of the VO determines the 
applicable policies for the interaction.
How do we communicate that context? How protocol specific is that? How would it 
fit-in with the WSRF ?


7* ???

--------------------------------------------------------------------------------

Note that any participation in the telcons and discussions will be translated in 
a willingness to roll up your sleeves to actively help to document these use 
cases and requirements...

Hope to talk to you on Monday!
Regards, Frank Siebenlist and Takuya Mori.

--
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory