RE: [security-services-comment] FW: Comments on WS-Security Profi leFor SAML

["Mishra, Prateek" <pmishra@netegrity.com>]

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







 







>>