December 2007 - ogsa-authz-wg

Implementations
by David Chadwick 05 Apr '08

05 Apr '08

Dear WG I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA). The information that would be useful for the group is Profile being implemented: Organisation doing the implementation: Contact details: Short description: (the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG) 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 *****************************************************************

7 36

VO SAML Attribute Profile
by Valerio Venturi 15 Feb '08

15 Feb '08

Hi, following (with an embarassing delay) Tom Scavo's mail on defining a SAML profile for VOMS attribute, I'm posting a document Krzysztof Benedyczak and I was editing with initial thoughts on the matter. I'm not uploading it to gridforge until it's more complete than it is now. If the issue raise interest and we manage to agree on a document, we may ask Blair and DavidG about a possible recommendification, though I think that not being in the current charter make it difficult. Let's see, the discussion is anyway usefull. I profit to wish everybody a nice holiday. Valerio

7 33

Fwd: [security-services] Public Review of SAML Specifications
by Tom Scavo 04 Feb '08

04 Feb '08

FYI OASIS has announced a 60-day public review period for a group of five specifications being considered by the SSTC. Three of those specifications involve attributes. Of particular interest to this group is the SAML V2.0 Deployment Profiles for X.509 Subjects, which underlies the OGSA Attribute Exchange Profile (a new version of which Valerio uploaded to gridforge this morning). Also of interest is the SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems, which supports the same use case as the SAML V2.0 Deployment Profiles for X.509 Subjects but has a different emphasis. Of course your comments are encouraged. Note that the OASIS TC process requires that all comments be given full consideration before the specification can proceed in committee. Thanks, Tom Scavo NCSA ---------- Forwarded message ---------- From: Mary McRae <mary.mcrae(a)oasis-open.org> Date: Dec 10, 2007 11:30 PM Subject: [security-services] Public Review of SAML Specifications To: members(a)lists.oasis-open.org, tc-announce(a)lists.oasis-open.org Cc: OASIS SSTC <security-services(a)lists.oasis-open.org> To OASIS members, Public Announce Lists: The OASIS Security Services (SAML) TC has recently approved the following specifications as Committee Drafts and approved each of the following five (5) specifications for public review: 1. SAMLv2.0 HTTP POST "SimpleSign" Binding 2. Identity Provider Discovery Service Protocol and Profile 3. SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems 4. SAML V2.0 Deployment Profiles for X.509 Subjects 5. SAML V2.0 LDAP/X.500 Attribute Profile The public review starts today, 11 December 2007, and ends 9 February 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=security. 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=security. 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/security-services-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: 1. SAMLv2.0 HTTP POST "SimpleSign" Binding Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.html 2. Identity Provider Discovery Service Protocol and Profile Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… dt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… df HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… tml Schema: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… df 3. SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.html 4. SAML V2.0 Deployment Profiles for X.509 Subjects Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.html Schema: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… .xsd 5. SAML V2.0 LDAP/X.500 Attribute Profile Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. html OASIS and the Security Services (SAML) 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 from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

1 1

Draft XACML/SAML Protocol Profile
by Chad La Joie 18 Dec '07

18 Dec '07

For part of some EGEE work that I'm involved in I came up with a profile, in draft form currently, for the XACML over SAML protocol defined within the OASIS XACML working group. Valerio suggested that I make it available to this working group for possible adoption in your efforts. The draft can be found here: http://switch.ch/grid/support/documents/xacmlsaml.pdf The basic goal of the document is to restrict possible options into a baseline subset such that discreet implementations might inter-operate. I think Valerio's summary of the document, as follows, is good: - requirement for using the SAML SOAP binding as in SAMLBind - requirement for having mutual authentication between the requester and the responder - some requirements on the elements usage - requirements on authN, integrity and confidentiality Note this document is only about interoperability at the protocol level, it does not speak to the other necessary item here which is a profile for the information (attributes) within the XACML request/response context. I know that individuals here have already been working on such a document. Comments are welcome to the document. We will be going forward with an immediate implementation of this draft for the EGEE work, but that should only be taken as a reflection of a constrained timeline for a short-term project, not as an indication that the profile is already as good as possible. -- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie(a)switch.ch, http://www.switch.ch

4 20

[Fwd: Re: Draft XACML/SAML Protocol Profile]
by Chad La Joie 12 Dec '07

12 Dec '07

Sorry, didn't send this to the whole list. -------- Original Message -------- Subject: Re: [OGSA-AUTHZ] Draft XACML/SAML Protocol Profile Date: Wed, 12 Dec 2007 14:59:03 +0100 From: Chad La Joie <chad.lajoie(a)switch.ch> Organization: SWITCH To: David Chadwick <d.w.chadwick(a)kent.ac.uk> References: <475418B0.5050003(a)switch.ch> <ea2af9bd0712091902p1b5547efv2d25c40e2b6b535c(a)mail.gmail.com> <475CD07F.1050307(a)switch.ch> <ea2af9bd0712100636l7f2c4ce4je88a6ecdd01194f2(a)mail.gmail.com> <475D6EF7.504(a)switch.ch> <475EBFCE.5030300(a)kent.ac.uk> No, no confusion. I was referring to a very specific requirement, integrity, which is orthagonal to authentication. It happens that the most common mechanism we use for confidentiality and integrity, SSL/TLS, *may* also provide a means for authenticating the client as well. It is not required and it not doing does not change the integrity properties of that mechanism. David Chadwick wrote: > Hi Chad > > from your long response I do believe that you are confusing integrity > with authenticity. Can you tell me which integrity mechanism you are > thinking of that provides message integrity without any ability for the > recipient to determine who the sender is. > > regards > > David > > Chad La Joie wrote: >> Let me address confidentiality and integrity requirements separately. >> >> XACML authorization decision requests *and* responses may carry XACML >> request contexts. These contexts can contain sensitive information >> about individuals. Such information can not be distinguished by >> requester/responder software. The only way then to ensure the >> protection of such information is to always require that some form of >> confidentiality be in place. This is also why the requester/responder >> is not allowed to forward assertion onto parties for which it was not >> intended. >> >> Likewise the policy response may contain sensitive information, in >> most cases the sensitivity will likely stem from the ability to >> examine and exploit the policy under which the PDP will operate, but >> other issues may be present as well. While we certainly hope that >> deployers won't have holes in their policies, the complexity of XACML >> makes it likely that such holes will occur. Providing all the >> information necessary for an attacker to take advantage of such holes >> posses an unnecessary risk; a risk that is easily mitigated by >> confidentiality requirements. >> >> Integrity is required within the authorization decision request so >> that an attacker can not manipulate the content of the request in >> order to produce a positive authorization decision. While a PEP may >> be able to detect this if the XACML request context is returned by the >> PDP it is unlikely that the context will be returned in the response. >> The authorization decision response needs to be protected because the >> response may simply be a "yes" or a "no". The PEP has no way to >> determine if the message was changed in transit. Also, note, that >> even if the responder did return the request context, allowing the PEP >> to verify that the request was not altered, such a check is >> meaningless without response integrity checking. >> >> An integrity mechanism is required on a policy request to prevent a >> third party from intercepting the request and altering the policy >> requirements such that a more lax policy is returned. It is required >> on the response to prevent that the policy itself from being altered. >> >> Tom Scavo wrote: >>> On Dec 10, 2007 12:37 AM, Chad La Joie <chad.lajoie(a)switch.ch> wrote: >>>> Tom Scavo wrote: >>>>> I'm sure you know this but if you change all the normative language >>>>> regarding <saml:Issuer> from SHOULD to MUST, you essentially end up >>>>> with the Assertion Query/Request Profile in section 6 of the SAML V2.0 >>>>> Profiles spec: >>>>> >>>>> http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>> Yes, it's supposed to be very similar to the query/request profile. >>>> >>>>> So the obvious question is why did you change the language regarding >>>>> <saml:Issuer>? >>>> The responder needs to know who is making the request. >>> Well, this is straightforward query, so your profile can (and probably >>> should) build on the Assertion Query/Request Profile (which requires >>> <saml:Issuer>). In that case, the profile reduces to little more than >>> section 3. >>> >>>>> Overall, your profile is a curious blend of more restrictive / less >>>>> restrictive language with respect to the profiles it depends on. The >>>>> stated requirements on <saml:Issuer> are an example of the latter. >>>>> The security requirements in section 3 seem to be an example of the >>>>> former. In particular, I find it odd that integrity and >>>>> confidentiality are MUSTs, yet authentication is SHOULD. Can you say >>>>> a few words about that (beyond what's already written in the >>>>> document)? >>>> Why would you find it odd that security requests/responses require >>>> integrity and confidentiality mechanisms? They are required because >>>> not >>>> doing them makes the request/response completely untrustwothy. >>>> >>>> In regards to authentication, this one I went back and forth on. I >>>> personally think the requester and responder should always be mutually >>>> authenticated, but I could imagine cases where deployers had a more lax >>>> view, especially on the policy request. So, I just left it as a SHOULD >>>> so that individual deployments could choose not to do it, if they >>>> wanted. >>> Section 6.1 of [SAMLSecure] addresses the security implications of the >>> SAML SOAP Binding. In addition, section 3.1.2 of the SAML Bindings >>> specification [SAMLBind] provides further security guidelines >>> regarding SAML bindings. Taken together, these security >>> considerations adequately address this use case, I think. Additional >>> requirements with respect to integrity and confidentiality have not >>> been justified. >>> >>> Tom >> > -- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie(a)switch.ch, http://www.switch.ch -- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie(a)switch.ch, http://www.switch.ch

1 0

OGSA Attribute Exchange Profile new version uploaded
by Valerio Venturi 11 Dec '07

11 Dec '07

Hi all, I've uploaded to gridforge the new version of the OGSA Attribute Exchange Profile, which is 1.2. The major changes from the previous versions are - added namespaces declaration for the wsdl in appendix A, made up according to GFD.84. - added examples in appendix b There are still some issues to sort out - the 'naming' in the introduction, as in the exchange between David and Tom on this list - the requirements for using attributes according to the XACML attribute profile I've only add a comment on the second issue, and had no taken any decision yet. I suggest that we wait for other opinion that WG's members may have, and then decide accordingly. I suggest to do the same also for the introduction and the needs for clarifying the relations to concepts as IdP, AA. Instead of editing the doc, add a comment and post it to the list. We would avoid having a plenty of different version on gridforge. If we cannot reach an agreement by mail, I suggest that people interested in the discussion have a phone conf. Probably early in January would be the best. Valerio

1 1

VOMS Attribute Profile
by Tom Scavo 03 Dec '07

03 Dec '07

A relatively simple way to implement an Extended Mode X.509 Attribute Query/Responder or Extended Mode X.509 Attribute Self-Query/Responder (both server-side components) is to deploy a Shibboleth Attribute Resolver in front of a VOMS attribute store. To do this, I would need to understand the VOMS schema (which I don't, but I assume I could look this up somewhere) but more importantly I'd need to know how to map a VOMS attribute to SAML. We've talked about this some on this list, but my question is: Is there a document that describes how to map a VOMS attribute to SAML? I suspect there is no such thing, so it seems we need a VOMS Attribute Profile for SAML, that is, a document that shows how to map VOMS attributes to SAML attributes. The structure of that profile would follow the attribute profiles in section 8 of the SAML V2.0 Profiles specification: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf At first I thought there should be a section on VOMS attributes in the OGSA Attribute Exchange Profile, but the more I think about it, the more I think it should be separate. Thoughts? Tom Scavo NCSA

5 9

Latest profile specs
by David Chadwick 02 Dec '07

02 Dec '07

Dear All I have just uploaded the updated the XACML and WS-Trust specs as described at the OGF21 meeting to source forge. I have also updated the architecture document to reflect the latest changes. Pointers to the latest 4 docs are in my other email to Tom. The next task is to homogenise the terminology so that they use consistent terminology throughout the entire set. 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 4