RE: "binding" assertions to business payloads

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

Kelvin,

the core issue is really of message integrity (this is sort of pointed
out in Philip's note). There needs to be some way to ensure that the
assertion hasn't gotten separated from the payload. One way (Philip's
suggestion) is to carry the hash of the payload in the assertion; another
way, (my original suggestion) is to carry the public key of the entity
"holding" the assertions. In the latter case, the composite package must
also be signed.

The key issue here is that signing alone isnt enough; the 
assertion itself must somehow carry additional information for 
there to be an authentic binding to a payload. 

- prateek


>>I am only new to this committee, and although I have tried to 
>>catch up on
>>previous posts I hope I am not going over old ground ;).
>>
>>> >>> In order to avoid an MITM attack, it seems necessary that the
>>> >>> assertion should include Ravi's public key (or more generally
>>> >>> <dsig:keyinfo>) within the assertion. When the composite
>>> >>> package arrives at the recipient, she can validate
>>> >>> the signature using the public key found within the
>>> >>> assertion. This ensures that only the
>>> >>> original ``holder'' of the assertion could have bound it to
>>> >>> the payload.
>>
>>There seems to be some confusion on who is signing what 
>>assertions. The
>>point of cryptographically signing a document is not only to 
>>ensure that the
>>document has not been tampered with, but also that you trust 
>>the party that
>>has signed it and therefore the assertion itself. In the 
>>example given, Ravi
>>obtained an authentication assertion identifying himself and 
>>his role in
>>company X. Clearly this assertion cannot be signed by Ravi himself,
>>otherwise Ravi could assert any identity or role that he wished! The
>>assertion needs to be signed by the party that made it (ie the
>>authentication service). Any subsequence service that trusts the
>>authentication service should accept the assertion.
>>
>>Now in terms of binding the authentication assertion with the business
>>payload, I do not believe it is the responsibility of the 
>>specification to
>>describe how the combined SAML + business payload is 
>>packaged. For example,
>>there is already a proposed specification that describes how 
>>a SOAP document
>>can be signed http://www.w3.org/TR/SOAP-dsig/. If that 
>>document contained an
>>SAML assertion as a header, then it assertion is by default 
>>tied to the
>>payload. The point is that if you want to define bindings to existing
>>enveloping frameworks, then I think that it is the 
>>responsibility of that
>>framework to define how to sign the payload.
>>
>>As a side note, I think it is also a possiblitity that Ravi 
>>himself may not
>>sign the combined payload - this may be done by some other 
>>service that Ravi
>>has presented his authentication assertion to (ie a back 
>>office, heads down
>>transaction model). In this scenarion, Service A sends the message to
>>Service B and attaches Ravi's authentication assertion. Now 
>>this issue is
>>whether Service B trusts Service A to send a purchase order. 
>>The advantage
>>of this model is that it is easier to eliminate the MITM 
>>attack which you
>>described, as Service A can have a server certificate (a service based
>>peer-to-peer model).
>>
>>Cheers,
>>
>>_________________________
>>Kelvin Beeck
>>www.talkingblocks.com
>>San Francisco, CA
>>
>>> -----Original Message-----
>>> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
>>> Sent: Monday, May 07, 2001 1:22 PM
>>> To: 'Philip Hallam-Baker'; ''oasis sstc' '
>>> Cc: 'security-bindings@lists.oasis-open.org'
>>> Subject: RE: "binding" assertions to business payloads
>>>
>>>
>>>
>>> >>2) Alice gets the PO countersigned by a party that has (largely)
>>> >>unrestricted signature powers. [Probably a cryptographic
>>> >>signing unit in a
>>> >>secure facility].
>>> >>
>>> >>At this point what is effectively being created is an
>>> >>authorized purchase
>>> >>order.
>>>
>>> 	[PM] I am uncomfortable with the term "authorized purchase
>>> 	order". No action has been authorized; in my example,
>>> Ravi obtained
>>> 	an assertion that described his employment status and
>>> classification
>>> 	from an asserting party. It is up to the message recipient to
>>> authorize
>>> 	any action based on the business payload.
>>>
>>
>>
>>>>