Draft XACML/SAML Protocol Profile
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@switch.ch, http://www.switch.ch
Hi Chad, your work aims at satisfying the same need of one the current WG draft, Use of XACML Request Context to Obtain an Authorization Decision, last version at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-auth... One difference is that this one states only that the SAML V2.0 Profile for XACLM V2.0 is used for carrying the message, while yours go deeper into details and mandate to using the SAML SOAP Binding. I think this suits also the WG specification, and this is exaclty what the SAML Profile for XACML was meant to, to leverage protocols and bindings that SAML have, why XACLM doesn't. The other requirements seems to me sounding as well. Please keep us informed of your efforts, so that we can exhange experiences and find a convergence. David, as the main author of the XACML spec, do you think Chad's doc requirements can be received in your doc? I really hope so, since I'm implementing those too:). Actually, when we speak of web services, most of the time is assumed you'll be using SOAP over HTTP, but I think it's worth be clear in a spec. Another thing, what about a WSDL? We are publishing one, though non normative, in the Attribute Exchange Profile. In general, I think WSDL helps adoption a lot, so it may be a good idea having one in. What do you think? Chad, needless, your comemnts on the WG doc are also very much appreciated. Valerio On Mon, 2007-12-03 at 06:54 -0800, Chad La Joie wrote:
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.
Hi Valerio and Chad Valerio Venturi wrote:
Hi Chad, your work aims at satisfying the same need of one the current WG draft, Use of XACML Request Context to Obtain an Authorization Decision, last version at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-auth... One difference is that this one states only that the SAML V2.0 Profile for XACLM V2.0 is used for carrying the message, while yours go deeper into details and mandate to using the SAML SOAP Binding. I think this suits also the WG specification, and this is exaclty what the SAML Profile for XACML was meant to, to leverage protocols and bindings that SAML have, why XACLM doesn't.
I agree. Where there are different options that are not pinned down sufficiently tightly in the existing drafts, then we should be adding additional text in order to ensure interworking.
The other requirements seems to me sounding as well. Please keep us informed of your efforts, so that we can exhange experiences and find a convergence. David, as the main author of the XACML spec, do you think Chad's doc requirements can be received in your doc?
I have no problems with this. After all this is meant to be the WG spec that is reached by common consensus. So if most people in the WG want these additions they will be adopted. I really hope so, since I'm
implementing those too:). Actually, when we speak of web services, most of the time is assumed you'll be using SOAP over HTTP, but I think it's worth be clear in a spec.
agreed. It is always good to explictly spell out all assumptions, since years later different people with different assumptions can read the spec and then misinterpret it.
Another thing, what about a WSDL? We are publishing one, though non normative, in the Attribute Exchange Profile. In general, I think WSDL helps adoption a lot, so it may be a good idea having one in. What do you think?
Chad, needless, your comemnts on the WG doc are also very much appreciated.
I second that. We need to know which bits you agree with and which bits you dont, or which bits are not explicit enough regards David
Valerio
On Mon, 2007-12-03 at 06:54 -0800, Chad La Joie wrote:
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.
-- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
Okay, I'll look at the document in more detail. I believe I already mentioned to Valerio that I think there is benefit to having two separate documents, one for the protocol and one for the attributes. This allows parts to be updated more easily and, if written properly, would allow the attributes spec to be cited by things unrelated to XACML but still wanting to the attributes you define. I'll note the SAML profile document has both protocol and attribute profiles in it. The TC botched I much of the attribute profile text and now there's errata that basically says to ignore whats in the SAML profile document, in regards to attributes, and refer to a set of other documents that are now available or in progress. Seems like avoiding the even the chance of having to do that is a good thing. David Chadwick wrote:
Hi Valerio and Chad
Valerio Venturi wrote:
Hi Chad, your work aims at satisfying the same need of one the current WG draft, Use of XACML Request Context to Obtain an Authorization Decision, last version at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-auth...
One difference is that this one states only that the SAML V2.0 Profile for XACLM V2.0 is used for carrying the message, while yours go deeper into details and mandate to using the SAML SOAP Binding. I think this suits also the WG specification, and this is exaclty what the SAML Profile for XACML was meant to, to leverage protocols and bindings that SAML have, why XACLM doesn't.
I agree. Where there are different options that are not pinned down sufficiently tightly in the existing drafts, then we should be adding additional text in order to ensure interworking.
The other requirements seems to me sounding as well. Please keep us informed of your efforts, so that we can exhange experiences and find a convergence. David, as the main author of the XACML spec, do you think Chad's doc requirements can be received in your doc?
I have no problems with this. After all this is meant to be the WG spec that is reached by common consensus. So if most people in the WG want these additions they will be adopted.
I really hope so, since I'm
implementing those too:). Actually, when we speak of web services, most of the time is assumed you'll be using SOAP over HTTP, but I think it's worth be clear in a spec.
agreed. It is always good to explictly spell out all assumptions, since years later different people with different assumptions can read the spec and then misinterpret it.
Another thing, what about a WSDL? We are publishing one, though non normative, in the Attribute Exchange Profile. In general, I think WSDL helps adoption a lot, so it may be a good idea having one in. What do you think? Chad, needless, your comemnts on the WG doc are also very much appreciated.
I second that. We need to know which bits you agree with and which bits you dont, or which bits are not explicit enough
regards
David
Valerio
On Mon, 2007-12-03 at 06:54 -0800, Chad La Joie wrote:
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.
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- 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@switch.ch, http://www.switch.ch
Chad La Joie wrote:
Okay, I'll look at the document in more detail.
I believe I already mentioned to Valerio that I think there is benefit to having two separate documents, one for the protocol and one for the attributes.
Its more than just attributes. Obligations also need to be standardised. Perhaps CRUD actions as well. This allows parts to be updated more easily and, if written
properly, would allow the attributes spec to be cited by things unrelated to XACML but still wanting to the attributes you define.
Agreed. This has been discussed by the WG. Its all a question of timing. If the attributes/obligations etc can come quickly after the protocol profiles this will be fine, but if it takes years then it would be too long. regards David
I'll note the SAML profile document has both protocol and attribute profiles in it. The TC botched I much of the attribute profile text and now there's errata that basically says to ignore whats in the SAML profile document, in regards to attributes, and refer to a set of other documents that are now available or in progress. Seems like avoiding the even the chance of having to do that is a good thing.
David Chadwick wrote:
Hi Valerio and Chad
Valerio Venturi wrote:
Hi Chad, your work aims at satisfying the same need of one the current WG draft, Use of XACML Request Context to Obtain an Authorization Decision, last version at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-auth...
One difference is that this one states only that the SAML V2.0 Profile for XACLM V2.0 is used for carrying the message, while yours go deeper into details and mandate to using the SAML SOAP Binding. I think this suits also the WG specification, and this is exaclty what the SAML Profile for XACML was meant to, to leverage protocols and bindings that SAML have, why XACLM doesn't. I agree. Where there are different options that are not pinned down sufficiently tightly in the existing drafts, then we should be adding additional text in order to ensure interworking.
The other requirements seems to me sounding as well. Please keep us informed of your efforts, so that we can exhange experiences and find a convergence. David, as the main author of the XACML spec, do you think Chad's doc requirements can be received in your doc? I have no problems with this. After all this is meant to be the WG spec that is reached by common consensus. So if most people in the WG want these additions they will be adopted.
I really hope so, since I'm
implementing those too:). Actually, when we speak of web services, most of the time is assumed you'll be using SOAP over HTTP, but I think it's worth be clear in a spec. agreed. It is always good to explictly spell out all assumptions, since years later different people with different assumptions can read the spec and then misinterpret it.
Another thing, what about a WSDL? We are publishing one, though non normative, in the Attribute Exchange Profile. In general, I think WSDL helps adoption a lot, so it may be a good idea having one in. What do you think? Chad, needless, your comemnts on the WG doc are also very much appreciated. I second that. We need to know which bits you agree with and which bits you dont, or which bits are not explicit enough
regards
David
Valerio
On Mon, 2007-12-03 at 06:54 -0800, Chad La Joie wrote:
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.
-- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
Well, if there is even a chance that one part one be done when the other is I'd say that was pretty much the only reason you needed to split them. David Chadwick wrote:
Chad La Joie wrote:
Okay, I'll look at the document in more detail.
I believe I already mentioned to Valerio that I think there is benefit to having two separate documents, one for the protocol and one for the attributes.
Its more than just attributes. Obligations also need to be standardised. Perhaps CRUD actions as well.
This allows parts to be updated more easily and, if written
properly, would allow the attributes spec to be cited by things unrelated to XACML but still wanting to the attributes you define.
Agreed. This has been discussed by the WG. Its all a question of timing. If the attributes/obligations etc can come quickly after the protocol profiles this will be fine, but if it takes years then it would be too long.
-- 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@switch.ch, http://www.switch.ch
David Chadwick wrote:
Chad La Joie wrote:
Okay, I'll look at the document in more detail.
I believe I already mentioned to Valerio that I think there is benefit to having two separate documents, one for the protocol and one for the attributes.
Its more than just attributes. Obligations also need to be standardised. Perhaps CRUD actions as well.
This allows parts to be updated more easily and, if written
properly, would allow the attributes spec to be cited by things unrelated to XACML but still wanting to the attributes you define.
Agreed. This has been discussed by the WG. Its all a question of timing. If the attributes/obligations etc can come quickly after the protocol profiles this will be fine, but if it takes years then it would be too long.
Yes, same problems that for the attributes and the attribute exchange profile. And not a straightforward solution. The problem here is more complicated, because while agreeing on a format for VO attributes won't take much, agreeing on identifiers for obligations, actions, and whatelse seems a hard work. But that mean also that probably putting them now in a specification is premature, and we cannot claim to have consensus on those, while for the protocol we are at agood point. What about extracting them to an appendix, may be in form of examples? Would that be a good trade off? Valerio
regards
David
I'll note the SAML profile document has both protocol and attribute profiles in it. The TC botched I much of the attribute profile text and now there's errata that basically says to ignore whats in the SAML profile document, in regards to attributes, and refer to a set of other documents that are now available or in progress. Seems like avoiding the even the chance of having to do that is a good thing.
David Chadwick wrote:
Hi Valerio and Chad
Valerio Venturi wrote:
Hi Chad, your work aims at satisfying the same need of one the current WG draft, Use of XACML Request Context to Obtain an Authorization Decision, last version at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-auth...
One difference is that this one states only that the SAML V2.0 Profile for XACLM V2.0 is used for carrying the message, while yours go deeper into details and mandate to using the SAML SOAP Binding. I think this suits also the WG specification, and this is exaclty what the SAML Profile for XACML was meant to, to leverage protocols and bindings that SAML have, why XACLM doesn't.
I agree. Where there are different options that are not pinned down sufficiently tightly in the existing drafts, then we should be adding additional text in order to ensure interworking.
The other requirements seems to me sounding as well. Please keep us informed of your efforts, so that we can exhange experiences and find a convergence. David, as the main author of the XACML spec, do you think Chad's doc requirements can be received in your doc?
I have no problems with this. After all this is meant to be the WG spec that is reached by common consensus. So if most people in the WG want these additions they will be adopted.
I really hope so, since I'm
implementing those too:). Actually, when we speak of web services, most of the time is assumed you'll be using SOAP over HTTP, but I think it's worth be clear in a spec.
agreed. It is always good to explictly spell out all assumptions, since years later different people with different assumptions can read the spec and then misinterpret it.
Another thing, what about a WSDL? We are publishing one, though non normative, in the Attribute Exchange Profile. In general, I think WSDL helps adoption a lot, so it may be a good idea having one in. What do you think? Chad, needless, your comemnts on the WG doc are also very much appreciated.
I second that. We need to know which bits you agree with and which bits you dont, or which bits are not explicit enough
regards
David
Valerio
On Mon, 2007-12-03 at 06:54 -0800, Chad La Joie wrote:
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.
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
Hi All It is obvious that we cannot agree on the full set of useful attributes, actions, obligations etc in any short space of time. We will need operational experience with a number of applications, in order to determine what needs to be standardised. So the document that does this will take a year or two to produce. It might even be several documents. However, we do have experience of using some of these already. So the approach I took in the current draft was to document the minimum useful subset, get these out now, and then do the rest over a longer timeframe. This is not the first time I have experience of doing this sort of thing. Back in the 1980s we did the same thing with X.500. In the base standard we put a set of commonly usable attribute types, object classes, structure rules etc. and then over a longer time frame several Internet RFCs were written that specified other standard attribute types object classes etc. The definition of EduPerson schema was a continuation of this and took years to produce (like watching paint dry was the comment of one of the authors). So I think it would be folly to not include any attributes etc in the current protocol specs, since I dont expect such a separate document to produced in a short time frame. Putting the definitions in separate sections or Annexes to the main protocol spec is fine. This is simply document re-structuring and does not effect its contents. regards David Valerio Venturi wrote:
David Chadwick wrote:
Chad La Joie wrote:
Okay, I'll look at the document in more detail.
I believe I already mentioned to Valerio that I think there is benefit to having two separate documents, one for the protocol and one for the attributes.
Its more than just attributes. Obligations also need to be standardised. Perhaps CRUD actions as well.
This allows parts to be updated more easily and, if written
properly, would allow the attributes spec to be cited by things unrelated to XACML but still wanting to the attributes you define.
Agreed. This has been discussed by the WG. Its all a question of timing. If the attributes/obligations etc can come quickly after the protocol profiles this will be fine, but if it takes years then it would be too long.
Yes, same problems that for the attributes and the attribute exchange profile. And not a straightforward solution. The problem here is more complicated, because while agreeing on a format for VO attributes won't take much, agreeing on identifiers for obligations, actions, and whatelse seems a hard work. But that mean also that probably putting them now in a specification is premature, and we cannot claim to have consensus on those, while for the protocol we are at agood point. What about extracting them to an appendix, may be in form of examples? Would that be a good trade off?
Valerio
regards
David
I'll note the SAML profile document has both protocol and attribute profiles in it. The TC botched I much of the attribute profile text and now there's errata that basically says to ignore whats in the SAML profile document, in regards to attributes, and refer to a set of other documents that are now available or in progress. Seems like avoiding the even the chance of having to do that is a good thing.
David Chadwick wrote:
Hi Valerio and Chad
Valerio Venturi wrote:
Hi Chad, your work aims at satisfying the same need of one the current WG draft, Use of XACML Request Context to Obtain an Authorization Decision, last version at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-auth...
One difference is that this one states only that the SAML V2.0 Profile for XACLM V2.0 is used for carrying the message, while yours go deeper into details and mandate to using the SAML SOAP Binding. I think this suits also the WG specification, and this is exaclty what the SAML Profile for XACML was meant to, to leverage protocols and bindings that SAML have, why XACLM doesn't.
I agree. Where there are different options that are not pinned down sufficiently tightly in the existing drafts, then we should be adding additional text in order to ensure interworking.
The other requirements seems to me sounding as well. Please keep us informed of your efforts, so that we can exhange experiences and find a convergence. David, as the main author of the XACML spec, do you think Chad's doc requirements can be received in your doc? I have no problems with this. After all this is meant to be the WG spec that is reached by common consensus. So if most people in the WG want these additions they will be adopted.
I really hope so, since I'm
implementing those too:). Actually, when we speak of web services, most of the time is assumed you'll be using SOAP over HTTP, but I think it's worth be clear in a spec.
agreed. It is always good to explictly spell out all assumptions, since years later different people with different assumptions can read the spec and then misinterpret it.
Another thing, what about a WSDL? We are publishing one, though non normative, in the Attribute Exchange Profile. In general, I think WSDL helps adoption a lot, so it may be a good idea having one in. What do you think? Chad, needless, your comemnts on the WG doc are also very much appreciated.
I second that. We need to know which bits you agree with and which bits you dont, or which bits are not explicit enough
regards
David
Valerio
On Mon, 2007-12-03 at 06:54 -0800, Chad La Joie wrote:
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.
-- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
On Tue, 2007-12-04 at 15:08 +0000, David Chadwick wrote:
Hi Valerio and Chad
Valerio Venturi wrote:
Hi Chad, your work aims at satisfying the same need of one the current WG draft, Use of XACML Request Context to Obtain an Authorization Decision, last version at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-auth... One difference is that this one states only that the SAML V2.0 Profile for XACLM V2.0 is used for carrying the message, while yours go deeper into details and mandate to using the SAML SOAP Binding. I think this suits also the WG specification, and this is exaclty what the SAML Profile for XACML was meant to, to leverage protocols and bindings that SAML have, why XACLM doesn't.
I agree. Where there are different options that are not pinned down sufficiently tightly in the existing drafts, then we should be adding additional text in order to ensure interworking.
The other requirements seems to me sounding as well. Please keep us informed of your efforts, so that we can exhange experiences and find a convergence. David, as the main author of the XACML spec, do you think Chad's doc requirements can be received in your doc?
I have no problems with this. After all this is meant to be the WG spec that is reached by common consensus. So if most people in the WG want these additions they will be adopted.
By the way, is PERMIS implementing the protocols using SOAP over HTTP or something else? What about authentication? Valerio
Valerio Venturi wrote:
By the way, is PERMIS implementing the protocols using SOAP over HTTP or something else?
SOAP over HTTP. I think this was an unwritten assumption that we made. What about authentication? I will need to check. We have used both mutual SSL and GSI with proxies David
Valerio
-- ***************************************************************** 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@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 Chadwick wrote:
Valerio Venturi wrote:
By the way, is PERMIS implementing the protocols using SOAP over HTTP or something else?
SOAP over HTTP. I think this was an unwritten assumption that we made.
Infact I assumed that. Just to be 100% sure.
What about authentication?
I will need to check. We have used both mutual SSL and GSI with proxies
Thanks for the info. Valerio
Hi Chad, 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 So the obvious question is why did you change the language regarding <saml:Issuer>? 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)? Finally, the restriction on lines 178--180 seems to contradict sections 6.1 and 7 of the SAML-XACML profile. Why restrict carte blanche the proxying of the <saml:Assertion> by the requester? Not only does that contradict the SAML-XACML profile but it's clearly out of scope for your use case. Tom On Dec 3, 2007 9:54 AM, Chad La Joie <chad.lajoie@switch.ch> wrote:
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@switch.ch, http://www.switch.ch -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
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.
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.
Finally, the restriction on lines 178--180 seems to contradict sections 6.1 and 7 of the SAML-XACML profile. Why restrict carte blanche the proxying of the <saml:Assertion> by the requester? Not only does that contradict the SAML-XACML profile but it's clearly out of scope for your use case.
There is no contradiction here and there is no proxying. Instead, this simply states that if an attribute authority provides attributes that party can't then pass them around to others. I know you're in favor of this model, I am not. For those that aren't subscribed to one of the many lists on which this issue has been brought up, let me outline the basics. These assertions carry potentially sensitive information about a user. Most attribute authorities contain the ability to control the release of this information on a per-party basis (i.e. A can see/request the sensitive information but B may not). A service which passed the information it received onto another service circumvents the attribute authority and its policies. It's interesting that Tom brings up proxying. I heard many a discussion about this exact same problem, in regards to proxy credentials, at the last two middleware design meetings I attended. There are ways to securely allow one service to impersonate a user to another service, but it requires the active participation of the entity(ies) responsible for the user. Circumventing these entities may be much easier but it isn't secure. -- 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@switch.ch, http://www.switch.ch
On Dec 10, 2007 12:37 AM, Chad La Joie <chad.lajoie@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
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@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@switch.ch, http://www.switch.ch
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:
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
On Dec 10, 2007 12:37 AM, Chad La Joie <chad.lajoie@switch.ch> wrote: 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
-- ***************************************************************** 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@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 *****************************************************************
Hi all, it looks to me that most of the doubts are not on integrity and confidentiality in themselves, but about considering them more important than authentication. Is assuring that something you don't know where is coming from wasn't altered important? The case of policy requests you mentioned is even more critical than authz decision request. A malicious authz decision allow access once, a malicious policy may allow access plenty of times. What about having two SHOULD? It's more or less the same for confidentiality. Valerio 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@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
Valerio Venturi wrote:
Hi all, it looks to me that most of the doubts are not on integrity and confidentiality in themselves, but about considering them more important than authentication. Is assuring that something you don't know where is coming from wasn't altered important? The case of policy requests you mentioned is even more critical
I meant that Chad has mentioned, it was in a previous mail 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. Valerio
Valerio Venturi wrote:
Hi all, it looks to me that most of the doubts are not on integrity and confidentiality in themselves, but about considering them more important than authentication. Is assuring that something you don't know where is coming from wasn't altered important?
I would say it is not important in general. Since you dont know where the message is coming from, then it is effectively coming from "Joe Public" ie. anyone. Since it is coming from anyone, then it can potentially contain anything. It really does not matter whether the message has been altered or not if it can contain anything. One blob is the same as another blob. The recipient has to evaluate the value of the message based solely on its contents. Thus if the message is a policy, and anyone can send a policy, then providing the syntax is correct, it does not matter what the policy contents are or if the policy has been altered or not during transfer since anyone could send me any valid policy. The only instance I can think of that integrity and anonymity is important is electronic voting systems, where the message contents have a very limited set of values, and changing the value is important. But even then, integrity on its own is not enough. The recipient has to know that the sender was entitled to sent the message, so there has to be an authenticity check as well as an integrity check. So authenticity is still important even if this case. Note however that authenticity does not mean identification. You may know that the vote is an authentic vote, but not the identity of the voter. The case of policy requests you mentioned is even
more critical than authz decision request. A malicious authz decision allow access once, a malicious policy may allow access plenty of times.
agreed. This means that it is essential that the PDP check the authenticity of the sent message, and integrity on its own is pointless (as noted above) regards David
What about having two SHOULD? It's more or less the same for confidentiality.
Valerio
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@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
-- ***************************************************************** 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@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 *****************************************************************
Hi Chad comments on your integrity and confidentiality discussion Chad La Joie wrote:
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.
I dont believe this is the case. On the contrary, I think that if a message is not authentic then it cannot be trusted. In other words, authenticity is more important than integrity or confidentiality. A message might not have been tampered with (integrity), but if the recipient does not know who has sent it then it cannot be trusted. It could be a genuine spoof message with integrity from an attacker. In the case of a message sent to a PDP, it could be a request for access sent by an attacker who is trying to discover the contents of the policy by bombarding the PDP will lots of requests. Unless the PDP knows that the message has come from the trusted PEP (i.e. authenticity) then the PDP should not respond. Secondly confidentiality adds nothing with respect to trust. All confidentiality provides is assurance that noone else read it. But that does not confer trust in the message. A recipient can receive a message from anyone that was encrypted to his public key (confidentiality), but that does not confer trust in the message. Anyone could have sent it, and the message could have integrity. But so what. The important thing is to know who sent it. In conclusion, authenticity provides both integrity and proof of who sent it, and both of these are needed in order to trust the message. Regards David
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.
Finally, the restriction on lines 178--180 seems to contradict sections 6.1 and 7 of the SAML-XACML profile. Why restrict carte blanche the proxying of the <saml:Assertion> by the requester? Not only does that contradict the SAML-XACML profile but it's clearly out of scope for your use case.
There is no contradiction here and there is no proxying. Instead, this simply states that if an attribute authority provides attributes that party can't then pass them around to others. I know you're in favor of this model, I am not.
For those that aren't subscribed to one of the many lists on which this issue has been brought up, let me outline the basics. These assertions carry potentially sensitive information about a user. Most attribute authorities contain the ability to control the release of this information on a per-party basis (i.e. A can see/request the sensitive information but B may not). A service which passed the information it received onto another service circumvents the attribute authority and its policies.
It's interesting that Tom brings up proxying. I heard many a discussion about this exact same problem, in regards to proxy credentials, at the last two middleware design meetings I attended. There are ways to securely allow one service to impersonate a user to another service, but it requires the active participation of the entity(ies) responsible for the user. Circumventing these entities may be much easier but it isn't secure.
-- ***************************************************************** 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@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 *****************************************************************
Hi Chad concerning passing attribute assertions between entities Chad La Joie wrote:
For those that aren't subscribed to one of the many lists on which this issue has been brought up, let me outline the basics. These assertions carry potentially sensitive information about a user.
correct, so in this case they should be encrypted for the SP which is the ultimate destination of the assertion. Most attribute
authorities contain the ability to control the release of this information on a per-party basis (i.e. A can see/request the sensitive information but B may not). A service which passed the information it received onto another service circumvents the attribute authority and its policies.
This is not always so. For example, B may request the attribute assertion from the AA in order to forward it to A (the SP). In this case the AA will return the assertion to B, encrypted for A to read. B is given the assertion to pass onto A, but B cannot read it, so there is no circumvention of the AA's policy in this case. 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@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 *****************************************************************
participants (4)
-
Chad La Joie -
David Chadwick -
Tom Scavo -
Valerio Venturi