RE: "binding" assertions to business payloads

[Kelvin Beeck <kelvin.beeck@talkingblocks.com>]

Prateek,

> 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

Agreed - my only concern is that the authenticated entity may not be the
only valid "holder" of the assertion that is able to bind the assertion to a
payload.

>
>
> >>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.
> >>>
> >>
> >>
> >>>>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> security-services-request@lists.oasis-open.org
>