[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] RE: [security-services-comment] FW: Comments onWS-Security Profi le For SAML
Dipak, Thanks for your comments and careful reading of the draft. Here is my response. --------------------------------------- [comment] 1. Line #64-67: The objective statement should be changed to reflect "inclusion of assertions" instead of "attachment of assertions." This might cause some confusion to readers with SOAP attachments. On line #421, even the draft uses "inserts". [/comment] Agreed, inclusion is preferable to attachment and will be updated in the next re-spin. [comment] 2 (Part a) If we need to include other tokens like X.509 certificate along with SAML assertion or assertion identifier, is there anything this profile should talk about? I don't know what it could be but I am raising a concern. This might be a reason not to talk integrity of the whole SOAP message and limit this draft to the integrity of SAML assertion only. [\comment] The WS-Security draft describes formats for including X.509 certificates in a SOAP message. We address this issue only in the context of the HolderOfKey and SenderVouches security models. [comment] 2 (Part b) At the same time, it would be nice if the tokens can be classified according to the functionality; authentication, attribute, authorization, weak authentication. I am not able to think some strong use case for this but lets say, you have a series of intermediaries and there are multiple <wsse:security> sections with one <wsse:security> with no Actor attribute and one <wsse:security> section for each intermediary. So now each intermediary has to find out which assertions are available for it to consume (notice that there are two <wsse:security> blocks for any intermediary to consume). If the information about the assertion type can be provided somehow, it might expedite the processing at the intermediaries. [\comment] I am open to discussion on this point but not yet convinced. Essentially, each intermediary has to analyze the contents of the wsse security element "addressed" to it via the actor attribute. How does your proposal change or simplify this processing model? [comment] 3. Line #169. "AssertionIDReference" value is a reference to AssertionID and not AssertionID itself. [\comment] Agreed. We will use the term "AssertionIDReference" consistently in the next draft. [comment] 4. Line #171. The error response might occur as receiver is trying to get the assertion for a particular AssertionIDReference. This communication might not be SOAP message exchange, why the error has to be wsse:SecurityTokenUnavailable. This error should be handled at SAML level, the lower level message layer should be left to the applications to decide. [\comment] I think there maybe a misunderstanding here which could be addressed by improving the language in this line. The specific means that the receiver uses to dereference AssertionIDReferences (and its subsequent failure) is out-of-scope for us and plays no role here. The issue instead is the interaction between sender and receiver. The sender has sent a SOAP message to a receiver; the message includes a AssertionIDReference; the receiver is unable to resolve the AssertionIDReference. What should the receiver do? We propose that the receiver MUST return a wsse:SecurityTokenUnavailable message to the sender. Otherwise, how will the sender understand why the receiver was unable to process the message? [comment] 5 (Part 1) In "HolderOfKey" format, the first thing I try to imagine, what kind of use case it can be where subject and sender are same. In my opinion, this makes sense where the business transaction (business payload) is of low criticality in terms of trust. For example, a "subject" might want to send a "quote request" to a "business partner". As in the "HolderOfKey" format, subject can add the "assertion" to any kind of document, the low trust business transactions make sense. [\comment] I am not really sure why this case should be considered a "low trust business transaction". Maybe it does not fit into the business models of interest to you? Instead, HolderOfKey provides a powerful end-to-end security model for interaction between an "unknown" sender and a receiver via third-party introduction (SAML assertions). The use of the sender's digital signature and its validation by the receiver, guarantees that (a) sender = subject (b) message integrity of the composite SOAP + SAML assertion message has been maintained. Notice also that there is NO requirement that sender and receiver participate in a trust relationship (e.g., have knowledge of secret or public keys). This is in contrast to the SenderVouches case. This has significant impact on simplifying deployment. [comment] 5 (Part 2) This makes me think about some concerns: a. If the assertion is signed by the issuer, what extra value you get, if even the sender (same as subject) also signs it. Can't you check the integrity of the assertion signed by the issuer? So why the inclusion of digital signature by the sender over the assertion is MUST? If the sender signs the message, why is it a MUST to additionally sign the assertion? b. In case, where sender is including assertion reference, it makes sense for sender to sign it. Why should this paper talk about the integrity of whole SOAP message? This paper should be limited to the integrity of SAML assertions. If the integrity of the SOAP message is mandatory for, it should be delegated to the WS Security framework. [\comment] First, there is no GENERAL requirement that whenever SAML assertions are included in a SOAP message, there must also be an additional digital signature "binding" the assertion to the document. Instead, lines 175-180 describe security considerations that should be taken into account at a receiver. The main threat is a MITM attack. Such an attacker may modify the message by inserting or removing assertions or changing the payload. Notice that this remains an issue even if assertions and business payloads are separately signed. For example, an attacker may remove signed assertions from the message or replace them with different assertions. The recipient will have no way of figuring out this change in message contents. This motivates the need for a signature across both assertions and payload. As a side-effect, of course, this also means that integrity of the payload is also assurred. [comment] 6. (part I) In "SenderVouches" format, what kind of use case it can be where subject and sender may be different. In my opinion, this makes sense where the business transaction (business payload) is of high criticality in terms of trust. For example, a "subject" might want to send a "purchase order" to a "business partner". In this case, sender gets the assertions (signed by issuer) and it inserts these assertions into message header (for a business transaction message requested by the subject). This is same as Maker/Checker mechanism in banking industry. As the access to these business messages (which can be controlled by some policy based mechanism) will allow only certain entities, not everybody can add their signatures to these business messages. [\comment] I am generally in agreement with your comments. Notice that one major difference between HolderOfKey and SenderVouches is that in the latter, the sender and receiver are required to have a trust relationship. So there is an additional deployment burden. [comment] 6. (part II) Here it makes sense for the sender to apply its signature to assertion. The rationale behind this is that "sender entity" is a known business partner to the receiver. Again, why should this paper talk about the integrity of whole SOAP message? This paper should be limited to the integrity of SAML assertions. [\comment] This case is exactly very similar to the HolderOkKey case. There is the threat of a MITM attack that must be dealt with. Again, signing is not mandatory but then the receiver must make a determination of (1) authenticate the sender by some means (2) sender has the right to send assertions found within the message. [comment] 7. A web service may demand authentication/authorization statements in the form of SAML assertions from the sender of a message. This makes it important for the sender, to know what security elements are expected by the receiver. TBD: How should this information be standardized, should it be included in the WSDL documents? [\comment] In the SAML approach an assertion can contain statements of various types. The issue of restricting the statement types returned within a SAML assertion is handled within the SAML protocol using the <RespondWith> element. So these issues are resolved at the protocol level and not at the profile level. [comment] 8 Line #386, the schema should point to "http://schemaS.xmlsoap.org/soap/envelope/" [\comment] Agreed ! - prateek >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC