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

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

Just a reminder about the upcoming call at 3pm PST.

Plus, I've created a template that we may want to use for the use case description:

"http://www.mcs.anl.gov/~franks/draft-ggf-ogsa-security-usecase-01.doc";.

which follows the same format/template as used for the OGSA use case docs.

(...next time I'll put it on the "official site"...)

Regards, Frank.


Frank Siebenlist wrote:

> 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