Hi Hiro I am actually at the NIST PKI workshop in Washington this week, and fly home on Thursday night. So I will be travelling from about lunchtime on Thursday (Eastern Time). Here is an update for you. I have nearly finished a couple of docs to present to the next GGF OGSA meeting to replace the current OGSA-SAML profile. One is based on XACML and is a PDP-PEP interface. The other is based on WS-Trust/SAML and is a PIP(CVS)-PEP interface. The existing OGSA-SAML spec is an interface to a combinded PIP(CVS)/PDP, but as we know it has severe limitations. regards David Hiro Kishimoto wrote:
Hi Alan, David, Von and Mary,
Is it possible to have one hour joint call between OGSA-AuthZ WG and OGSA-WG next Thursday, April 6? OGSA-WG will have a F2F meeting next week in San Francisco Bay Area and Frank Siebenlist will lead this security session on Thursday.
https://forge.gridforum.org/projects/ogsa-wg/document/2006Apr-OGSA-F2F-agend...
I would like to proceed with our previous discussion in January. Please have a look into attached meeting minutes from Jan 19 joint call.
If David can make it, we can talk 1-2pm PDT (= 9-10pm UK = 5-6am JST) same as January.
Please let me know your availability and agenda items you want to discuss.
Thanks in advance,
------------------------------------------------------------------------
OGSA January 2006 Interim Meeting =================================
Location: Sunnyvale, CA Date: 19/1/2006, afternoon
* Attendees
Hiro Kishimoto Dave Snelling Jem Treadwell Andreas Savva Fred Maciel Darren Pulsipher Chuck Spitx Fred Brisard Ravi Subramaniam Dave Berry Steve McGough Neil Chue Hong Takuya Mori Frank Siebenlist Jay Unger
Bridge: Alan Sill David Chadwick
Notes: Andreas Savva
See also Security agenda ppt: https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-security-session/...
* Security - OGSA AuthZ joint discussion
- "Use of SAML" document finished public comment with no comments - Many people have looked at it. One minor change and expect it to be published, but not sure when. - OGSI Authorization Requirements: 1 comment - Attributes ?
- Charter revision - Looked at revised charter - Hiro explained procedure for getting approval: circulate within WG and if happy with level of support send to ADs; otherwise do a BoF. - New charter output: 2 new versions - Authorization document - (The attributes document is not mentioned) - The milestones are not clear.
- Everyone is doing their own solution in the authorization area; no attempt to reach consensus on a common approach. Perhaps this is the reason why some of the docs received no comments. It is a problem but there is no solution.
- There is real difficulty with getting buy-in from major grid projects. Even if they say ok on the charter it does not mean they will contribute actively.
- Takuya has contacted NAREGI. Alan also asked about PRAGMA. Takuya agreed to contact PRAGMA as well.
- There is a Grid Interop at the next GGF16. Alan unfortunately canot make GGF16.
- Hiro's issue: how to combine security protocols (authorization) with service invocation? - Cannot tell people how to do authorization. Also do not want to create refined schemas because the semantics attached to the schema by different organizations may be different. - So focus not on attribute description but on the information about what are the required attributes by the services. (Analogy with card tokens; tokens are different but using a token may be a common point.) - Attribute information is dependent on the issuer. The proposal is not to try to map attributes between schemas but just to facilitate the exchange of what schemas are supported and can be used for authentication. - If no attribute mapping is attempted then cross-site auditing or logging isn't possible. - It is out of scope of OGSA AuthZ
* Security - Review of Basic Security Profile -- Secure Channel
- Just doing secure channel (point to point) and looking towards end-to-end (MLS) eventually. Performance of MLS is an issue. (Also need a way to describe policy and name entities and ...) - Note that this is point-to-point and not host-to-host.
- There is a bigger problem that needs solving (...) and this [profile] is the first step towards that goal (a bootstrap step).
- This profile says nothing about what is an authenticated entity. It may be a next step.
Action: To add an example of how the keyinfo exchange (core) is used with the secure channel profile
Action: Since Secure Channel should be composed with a Core it should not expose the BasicSecurity claim. Only Core should do that.
Update and aim for a final call by the end of the month
* Security - Review of Basic Security Profile - Core
- 1.2: This profile is not extending the WS-I Basic Profile - 1.2: Generalize the statement discussing the security profiles that can be combined with this profile.
- Agreed that this profile will not expose an anonymous channel claim URI. An anonymous channel profile should be defined as a separate document. - The important point is that it can be done with the current document structure. It may be left to the people who want it to actually do it. - Need to expose the extensibility elements in referenced specs - Need to address (at some point) how information on what features are required or supported.
* Future plans
Discussed plans for security design team and prioritized work:
- 1 Work on a Security architecture - 2 How to combine security functions (security context) with functional interfaces. - 3 MLS profile - 4 Issues raised by OGSA-Data wg and collaboration
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************