- ogsa-authz-wg - lists.ogf.org

Security and related activities at OGF24: an overview
by David Groep 29 Aug '08

29 Aug '08

OGF24: Bustling with Security Activities In a mere few weeks OGF24 will be held in Singapore. A compact meeting, it is packed with quite a few interesting security and related sessions. If you did not plan to come, maybe these still entice you to travel to Singapore: A jointly coordinated session with GIN will focus on how to restrict delegation. In the GIN grid deployments restricting what somebody (or a process can do) is gaining prominence, and how to design such restrictions when delegating credentials (both when using proxies and in a SAML context) is something the GIN group wants to know. One hand this of course includes the syntax and technical mechanisms, and based on current standards and developments this might be addressed in the short term. But how to interpret such restrictions in a common way? If a policy is defined to restrict access to a service or service method, will the implementations of such a service react in a similar way? This session should lead the way for a new working (or research?) group to address these topics. Also at OGF24, the OGSA-AuthZ WG will be discussing the feedback received on the "Functional Components of Grid Service Provider Authorisation Service Middleware" document, which has completed its public comment on August 28th, and the "Use of XACML Request Context to Obtain an Authorisation Decision" (completed PC on Aug 13), and review the ongoing comments of the remaining proposed recommendations: - Use of SAML to retrieve Authorization Credentials - WS-TRUST and SAML to Access a Credential Validation Service This suite of four documents provides a complete view on the internals of authorization, and your contributions are welcome to ensure that the documents reflect your needs. As a follow-up to the Firewall Issues RG, a new working group "Firewall Virtualization for Grid Applications" has been started to standardize a set of service definitions for a virtualized control interface into firewalls and other mid-boxes allowing the grid applications to securely and dynamically request application/workflow-specific services from those devices, for the duration of the service. The CA Operations WG, jointly with the IGTF, organises a full-day workshop focussing on a wide range of authentication and identity management issues. On the technical side these include the definition of signing namespace constraints by relying parties, guidelines for auditing CAs, authentication service profiles, and the profile defining trust in higher-level CAs. More on the policy side, issues such as risk assessment and incident response in the IGTF community, and the management of revocation will be discussed. The Levels of Authentication Assurance (LoA) RG merged with CAOPS in OGF23, with the document "A Gap Analysis of Current LoA Definitions vs. LoA Requirements in e-Science/Grid Context" available for discussion. For the operational security side: have a look at the BoF on Intrusion detection in Grid Computing for security issues in grid computing networks and proposed the possible solutions using Intrusion detection/prevention systems. Lastly, you have probably realised that the vacant spot left by Blair Dillaway as security AD (whose term ended in March) has still not been filled. To remedy this very unfortunate situation, please think hard about who you consider to be a suitable candidate (and that may be yourself!), and contact the OGF NOMCOM or the chair Neil Chue Hong directly. See http://www.ogf.org/nomcom/ for details about the NOMCOM process and for an application form. A healthy security area and the security activities in OGF merit a full complement of security ADs to ensure continuity past 2009! I hope to see many of you in Singapore. Best Regards, David Groep. -- David Groep ** Nikhef, Dutch National Institute for Sub-atomic Physics,PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

1 0

Comment of XACML profile
by David Chadwick 08 Aug '08

08 Aug '08

Dear WG We have a feature missing from the XACML profile that is in the WS-Trust profile. We need to make these two profiles consistent so that whether the PEP is talking to the CVS followed by the PDP, or the PDP only (which talks to the CVS), the PEP should be able to obtain the same level of service in both cases. What is missing in the XACML profile is the ability to pass references (meta info) to the PDP to tell it where to pick up the user's attributes from. This feature is present in the WS-Trust profile in Section 6. <SubjectAttributeReferenceAdvice>. Tom has already made some valuable comments on this feature which the group need to discuss and resolve. My new comment is that whatever is agreed for the final WS-Trust specification should also be incorporated into the XACML profile as well so that the PEP can obtain an equivalent level of service by either route. regards David ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

comments: GWD-R-P
by Tom Scavo 08 Aug '08

08 Aug '08

The document entitled "Use of XACML Request Context to Obtain an Authorisation Decision" contains the following error. On page 5, this document specifies use of the URI urn:oasis:names:tc:SAML:1.1:assertion but the above URI does not exist. The OASIS Security Services Technical Committee specifies the use of urn:oasis:names:tc:SAML:1.0:assertion for both SAML V1.0 and SAML V1.1. Tom Scavo

2 1

Public comment
by David Chadwick 07 Aug '08

07 Aug '08

Dear WG dont forget that all four documents are now out for public comment. These are: 1. Functional Components of Grid Service Provider Authorisation Service Middleware (pub 6 April 08) 2. Use of WS-TRUST and SAML to access a Credential Validation Service (pub 9 July 08) 3. Use of XACML Request Context to Obtain an Authorisation Decision (pub 31 Mar 08) 4. Use of SAML to retrieve Authorization Credentials (pub 7 April 2008) We plan to finish the resolution of all comments during the next month, and to finish them off at the Singapore meeting regards David ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

Fwd: [tc-announce] Public Review of WS-Trust v1.4, WS-SecureConversation v1.4, and WS-SecurityPolicy v1.3
by Tom Scavo 24 Jul '08

24 Jul '08

[sorry for cross-posting] ---------- Forwarded message ---------- From: Mary McRae <mary.mcrae(a)oasis-open.org> Date: Thu, Jul 24, 2008 at 8:46 AM Subject: [tc-announce] Public Review of WS-Trust v1.4, WS-SecureConversation v1.4, and WS-SecurityPolicy v1.3 To: members(a)lists.oasis-open.org, tc-announce(a)lists.oasis-open.org Cc: ws-sx(a)lists.oasis-open.org To OASIS members, Public Announce Lists: The OASIS Web Services Secure Exchange (WS-SX) TC has recently approved the following specifications as Committee Drafts and approved the package for public review: WS-Trust Version 1.4 WS-SecureConversation Version 1.4 WS-SecurityPolicy Version 1.3 The public review starts today, 24 July 2008, and ends 23 September 2008. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. Please feel free to distribute this announcement within your organization and to other appropriate mail lists. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ws-sx. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at: http://lists.oasis-open.org/archives/ws-sx-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification documents and related files are available here: WS-Trust Version 1.4 Editable Source (Authoritative): http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/cd/ws-trust-1.4-spec-cd-01.d… PDF: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/cd/ws-trust-1.4-spec-cd-01.p… HTML: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/cd/ws-trust-1.4-spec-cd-01.h… Schema: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/cd/ws-trust.xsd WS-SecureConversation Version 1.4 Editable Source (Authoritative): http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/cd/ws-securecon… tion-1.4-cd-01.doc PDF: http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/cd/ws-securecon… tion-1.4-cd-01.pdf HTML: http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/cd/ws-securecon… tion-1.4-cd-01.html Schema: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconv… ion-1.3.xsd WS-SecurityPolicy Version 1.3 Editable Source (Authoritative): http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/cd/ws-securitypolic… -spec-cd-01.doc PDF: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/cd/ws-securitypolic… -spec-cd-01.pdf HTML: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/cd/ws-securitypolic… -spec-cd-01.html Schema: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/cd/ws-securitypolic… OASIS and the Web Services Secure Exchange (WS-SX) TC welcome your comments. --------------------------------------------------- Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae(a)oasis-open.org web: www.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: tc-announce-unsubscribe(a)lists.oasis-open.org For additional commands, e-mail: tc-announce-help(a)lists.oasis-open.org

1 0

Fwd: [tc-announce] Public Review of WS-Trust v1.3 Errata - 15 day review
by Tom Scavo 07 Jul '08

07 Jul '08

FYI ---------- Forwarded message ---------- From: Mary McRae <mary.mcrae(a)oasis-open.org> Date: Sat, Jul 5, 2008 at 10:42 PM Subject: [tc-announce] Public Review of WS-Trust v1.3 Errata - 15 day review To: members(a)lists.oasis-open.org, tc-announce(a)lists.oasis-open.org Cc: ws-sx(a)lists.oasis-open.org To OASIS members, Public Announce Lists: The OASIS Web Services Secure Exchange TC has recently approved the following errata as a Committee Draft and approved the package for public review: WS-Trust 1.3 The public review starts today, 6 July 2008, and ends 21 July 2008. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ws-sx. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/ws-sx-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: Existing Standard: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html Standalone Errata: Editable Source: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-errata-cd-01.… PDF: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-errata-cd-01.… HTML: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-errata-cd-01.… Merged Errata: Editable Source: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-errata-c…. doc PDF: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-errata-c…. pdf HTML: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-errata-c…. html The schema files are available at: Existing Standard: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.xsd Corrected Schema: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-errata-cd-01.… OASIS and the WS-SX TC welcome your comments. --------------------------------------------------- Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae(a)oasis-open.org web: www.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: tc-announce-unsubscribe(a)lists.oasis-open.org For additional commands, e-mail: tc-announce-help(a)lists.oasis-open.org

1 0

Minutes
by David Chadwick 14 Jun '08

14 Jun '08

Dear All the minutes of the OGF 23 meeting have been posted to gridforge and can be found here http://forge.gridforum.org/sf/go/doc15254?nav=1 The final profile (WS-Trust) has also been posted and can be found here http://forge.gridforum.org/sf/go/doc15253?nav=1 All that remains now for this WG group to do is to resolve the comments on our 4 published documents, preferably by the OGF 24 Singapore meeting regards David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

2 2

WS-Trust CVS profile
by David Chadwick 12 Jun '08

12 Jun '08

Dear All please find attached the final draft version of the WS-Trust SAML profile for accessing a credential validation service. This is now ready for public comment if Greg would be so kind as to progress it. This protocol profile is the last document in our current series, and marks the final deliverable of the OGSA Authz WG. Since grid forge seems to be almost permanently unavailable, I am taking the liberty of emailing the document to the list and the OGF editor so that you have it now for review. I will insert it into grid forge once a reliable service has been resumed. If the OGF editor, Greg, can put this document on public review ASAP, to join the other docs that are currently there, this will allow everyone to have a complete set of Authz specifications for review at the same time. If you have any comments on any of any of the drafts please send them to the list for resolution regards David ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

Re: [OGSA-AUTHZ] [gridshib-user] SAML Assertions with namespace prefix - SAMLAssertionPushPIP fails
by David Chadwick 13 May '08

13 May '08

Hi Tom Tom Scavo wrote: > On Sun, May 11, 2008 at 7:45 AM, David Chadwick <d.w.chadwick(a)kent.ac.uk> wrote: >>> The SAML assertion is holder-of-key >>> while the AC is (essentially) sender-vouches. >> Actually the SAML assertion is also sender vouches, because the sender >> vouches for the attributes that are in the assertion. So does it really >> matter, given that the sender is vouching for the attributes, that it >> can also vouch for the subject name. To me, it does not. If I trust you >> to say what my attributes are, I must also trust you to say who I am (or >> what my ID is). > > I don't disagree with you, David, but the fact remains that the SAML > token issued by VOMS (according to the profile) is holder-of-key, not > sender-vouches. If we bind the SAML token to a proxy certificate and > present the latter to a resource provider, the holder-of-key subject > confirmation on the SAML token is not met, and so the RP is obliged to > discard the SAML token. Actually this is not true. The RP is not obliged to do anything. The RP is the root of trust and can decide to ignore all the advice of the AA, and decide to accept anything it wants to. Here is a real life example. Safeway (the AA) issue discount coupons ($5 off for $50 spend) to users of its stores, and the coupons state quite categorically "only to be used in Safeway stores, not exchangeable ....etc". But if you take the coupon to WalMart (the RP) they will honor the coupon and give you $5 off your $50 shopping. The RP is free to ignore anything the AA says, since it is the RP. Of course the AA will not take any responsibility for this, but then the RP does not mind. regards David > > I suggest we take the rest of this discussion over to the OGF AuthZ-WG > mailing list since that is where this problem must be addressed. > > Tom > > -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

holder-of-key or sender-vouches SAML token?
by Tom Scavo 13 May '08

13 May '08

There's a problem with the Attribute Exchange Profile it seems. If you bind a VOMS-SAML token to a SOAP message and authenticate via WS-Security SAML Token Profile, everything is fine because the key bound to the SAML token is the same key presented to the RP. However, if you bind a VOMS-SAML token to a proxy certificate, there are problems since the key presented to the RP is different than the key bound to the SAML token, and so the holder-of-key subject confirmation on the assertion is not satisfied. An RP is obliged to reject the SAML token in that case. Here's an example of a SAML token with holder-of-key subject confirmation: http://www.globus.org/mail_archive/gridshib-user/2008/05/msg00011.html Now a VOMS AC is essentially a security token with sender-vouches subject confirmation, so I wonder if the VOMS-SAML assertion should have sender-vouches subject confirmation as well. Alternatively, the proxy certificate could be constructed such that its key is the same key bound to the EEC. In that case, the SAML holder-of-key subject confirmation requirement would be met since all the bound keys (EEC, proxy, SAML) are the same. Thoughts? Tom

3 6