[OGSA-AUTHZ] comments on "OGSA Attribute Exchange Profile Version 1.2"

Wed Jan 16 17:11:32 CST 2008

That's a good suggestion, David.

Unless anyone has objections, I will produce version 1.3 of this
document.  I'll take into account both Blair's and David's comments.
Valerio, is that okay with you?

Tom

On Jan 16, 2008 6:05 PM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> Hi Tom
>
> Tom Scavo wrote:
> > Okay, I don't feel too strongly about this, so David's suggestions are
> > fine with me.  If I may make two points:
> >
> > 1. If we leave the normative statement re the XACML Attribute Profile
> > in this document, then it can't be converted to an informational
> > document as suggested by Blair.  I don't have a problem with that, I'm
> > just pointing it out.
> >
> > 2. An attribute that satisfies the XACML Attribute Profile can satisfy
> > other profiles simultaneously.  In particular, an attribute can
> > satisfy both the XACML Attribute Profile and the X.500/LDAP Attribute
> > Profile (see the last example in section 8 of SAML2Prof).  I don't
> > think we have to say anything about this in the document, I just
> > wanted to mention it.
>
> This is a good point that you make, and i think it should be made in the
> document as a footnote such as
>
> Note. An attribute can simultaneously satisfy the XACML Attribute
> Profile and other profiles as well such as the X.500/LDAP Attribute
> Profile. This specification does not prejudice such profiling.
>
> regards
>
> David
>
>
>  > Profile
>
> >
> > Tom
> >
> > On Jan 16, 2008 5:17 PM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> >> Hi All
> >>
> >> Valerio Venturi wrote:
> >>> Hi all,
> >>>
> >>> On Sun, 2008-01-13 at 10:26 -0500, Tom Scavo wrote:
> >>>> On 1/10/08, Blair Dillaway <blaird at microsoft.com> wrote:
> >>>>> A few comments and questions on this draft:
> >>>> Thanks for the feedback, Blair.  Please see the comments below.
> >>>>
> >>>>> 1)      This spec effectively says that all necessary protocols and
> >>>>> encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509,
> >>>>> SAMLPRof).  If that's the case, and there's no substantive profiling
> >>>>> required, it may be more appropriate to make this an informational document.
> >>>> I tend to agree with you.
> >>> It make sense.
> >>>
> >>>>> 2)      The only 'profiling' statement seems to be a requirement that SAML
> >>>>> Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST
> >>>>> and SAML to access a CVS" requires this, it is good for consistency.
> >>>>> However, comments in the doc indicate some disagreement on whether this a
> >>>>> requirement.
> >>>> I was the one who inserted that comment in the doc and I still feel
> >>>> that way.  If all we're interested in is attribute exchange (and
> >>>> that's precisely what this document is about), then the desired
> >>>> attribute profile (if any) is mostly irrelevant.
> >> I tend to disagree with Tom. This is a profile document that we are
> >> writing, to aid interworking. Given that it is a profile, then it cannot
> >> be irrelevant which attribute profile is used. We should standardise on
> >> one. The XACML one is the most appropriate one. If you want to use
> >> another attribute profile, then you can write a second and different
> >> attribute exchange profile document.
> >>
> >> Alternatively if you allow multiple profiles to be used here, then the
> >> CVS will need to be told which profile is being used in order to convert
> >> the assertions into the XACML attributes for use by the PDP. So
> >> flexibility in this profile means more work by the CVS to map from
> >> different profiles into XACML attributes.
> >>
> >>
> >>> The reason why it was there in the first place, was exactly the one
> >>> Blair mentioned, easier compatibility with the other specifications of
> >>> the WG.
> >> Also it aids interworking, and cuts down implementation options. That is
> >> the purpose of a profile.
> >>
> >> After the discussion, I tended to agree with Tom, that the
> >>> choice may be left to developers. Probably a warning that using
> >>> attributes that are convertible to XACML (so are those compliant to the
> >>> XACML Attribute profile) woudl make interopration wiht other spec easier
> >>> should be in a overall architectuire document.
> >> If we are writing an interoperability profile then we should eliminate
> >> as many options as possible. That is the purpose of profiles. If you
> >> leave the choice open, you do a dis-service to users and implementors
> >> alike who will find that their implementations wont interwork or have to
> >> write more code to cater for different formats.
> >>
> >>
> >>>> I think the normative statement in section 4.1 about the XACML
> >>>> Attribute Profile can be removed altogether.
> >> I disagree
> >>
> >>   In that case, your
> >>>> suggestion in (1) above is even more relevant.
> >>>>
> >>>>> If it changes, I think you should justify the difference in
> >>>>> the two specs.
> >>>> I don't think removing the normative language regarding the XACML
> >>>> Attribute Profile leads to an inconsistent family of specifications.
> >>>> On the contrary, removing this restriction makes this specification
> >>>> more usable in general.
> >> But that is not the purpose of this (or any) profile. A profile is
> >> designed to restrict usage, not generalise it. Base standards are
> >> generic, profiles are very specific.
> >>
> >>
> >>>>> 3)      Given the reliance on [SAMLX509], it seems this spec is geared
> >>>>> toward environments relying on X.509 principal authentication. If so, you
> >>>>> might want to make that clear in the introduction.
> >>>> The use case outlined in [SAMLX509] is pretty clear about this, but
> >>>> yes, it can perhaps be mentioned in the introduction to the OGSA
> >>>> Attribute Exchange Profile.
> >>> Agreed.
> >>>
> >>>>> 4)      Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal
> >>>>> with attribute retrieval. It would be good clarify how this spec fits into
> >>>>> the model used in the other WG specs (i.e., Section 3 of the latter spec) to
> >>>>> aid readers in understanding where each is intended to be used.
> >>>> Yes, I agree, especially if we choose to convert this to an
> >>>> informational document as you suggest.
> >>> There's the Functional Components document for that.
> >> I agree. We dont want to duplicate the functional components document
> >> too much in the profiles. Rather we should simply point the reader to
> >> the Functional Components document.
> >>
> >>
> >> You're suggesting
> >>> that a brief review of that be done also in the other specs? Infact, the
> >>> requets decision specs has an architecture overview. I thin that having
> >>> the architecture once in the architectire document may suffice. This is
> >>> also one concerns that others have, to include an architecture overview
> >>> in the specifics specs.
> >>>
> >>>>> You may also
> >>>>> want to provide a brief rationale for why the SAML protocol is appropriate
> >>>>> for this spec while WS-Trust is appropriate in the latter.
> >>>> I'm not sure what form this rationale would take.  What alternatives
> >>>> to SAML attribute query are there?  Moreover, I don't think it's
> >>>> appropriate for this spec to rationalize choices in the other spec.
> >>> The protocols are different. WS-Trust is used because you need to send an assertion to the service
> >>> and get an assertion back. SAML attribute queries cannot do that. But
> >>> I'll leave David comments on that.
> >> WS-Trust is converting from credentials (signed assertions) into XACML
> >> attributes for use by the PDP, according to a set of policy rules that
> >> are under the control of the resource provider.
> >>
> >> The SAML attribute queries are designed to fetch the signed assertions
> >> from remote attribute authorities, which are under the control of a
> >> privacy policy set by the attribute authority. The resource provider has
> >> little or no control over this.
> >>
> >> regards
> >>
> >> David
> >>
> >>
> >>>>> 5)      I was surprised to see no discussion of mutual authentication,
> >>>>> integrity, and confidentiality. The OASIS specs do mention various ways of
> >>>>> handling message security, but I don't believe they mandate any specific
> >>>>> security mechanisms.
> >>>> [SAMLX509] mandates mutual authentication and suggests possible ways
> >>>> to achieve integrity and confidentiality.  If you have comments or
> >>>> concerns about the security requirements in [SAMLX509], I encourage
> >>>> you to submit your comments to OASIS while [SAMLX509] remains in its
> >>>> Public Review period (through Feb 9):
> >>>>
> >>>> http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html
> >>>>
> >>>> Also, you may want to review the proposed "SAML V2.0 Attribute Sharing
> >>>> Profile for X.509 Authentication-Based Systems," which has
> >>>> significantly stronger security requirements than [SAMLX509].
> >>>>> Within grids, I would have thought people would want a
> >>>>> message security interop profile all implementers would agree to support.
> >>>> In that case, you may prefer the security requirements of the "SAML
> >>>> V2.0 Attribute Sharing Profile for X.509 Authentication-Based
> >>>> Systems."  I really would like to hear your reactions to that profile
> >>>> (but, please, direct your comments to OASIS, not here).
> >>>>
> >>>> I would be interested in hearing other opinions regarding the security
> >>>> requirements in [SAMLX509], and whether they are adequate for  the
> >>>> OGSA Attribute Exchange Profile.  If not, we have two choices: 1) send
> >>>> comments to OASIS regarding [SAMLX509] and wait to see how the SSTC
> >>>> responds, or 2) insert the desired security requirements in the OGSA
> >>>> profile.  Of course if we add more normative language to the OGSA
> >>>> profile, we won't be able to convert it to an "informational"
> >>>> document, but that's okay, I guess.
> >>> I think the requirements in SAMLX509 are appropiate. But a similar
> >>> discussion was made for the authz decision spec, without reaching a real
> >>> agreement.
> >>>
> >>> Valerio
> >>>
> >>>
> >>> --
> >>>   ogsa-authz-wg mailing list
> >>>   ogsa-authz-wg at ogf.org
> >>>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> >>>
> >> --
> >>
> >> *****************************************************************
> >> 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 at 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
> >>
> >> *****************************************************************
> >>
> >
>
> --
>
>
> *****************************************************************
> 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 at 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
>
> *****************************************************************
>