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

Wed Jan 16 17:05:52 CST 2008

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

*****************************************************************