RE: "binding" assertions to business payloads

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

Hi,

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.
>




>
>
> >>The Authorization statement then wants to either 1) restate the
> >>original 'Alice' purchase order or 2) cryptographically bind
> >>to it, e.g. via
> >>a MAC.
> >>
> >>Case (1) is out of scope since it is simply another purchase order.
>
> 	[PM] I generally agree that case (1) takes us into somewhat
> different
>      territory. The bindings group charter is focussed on packaging
>      SAML assertions carried with standard formats such as
> SOAP, MIME,...
>
> >>
> >>Case (2) is potentially in scope and certainly merits a proof of
> >>extendability.
> >>
> >>I think the case implies that the <Subject> of the
> >>authorization would be
> >>the purchase order.
>
>    [PM] I disagree with this statement. The subject of the assertion
> obtained
>    by Ravi thru an authentication step is some form of "name"
> for Ravi.
> There is a
>    need for a link between the assertion to the "action"
> requested by Ravi
> but
>    it would appear to be a distinct field within the assertion.
>
>
> >>The consistent means of specification
> >>would be as a link
> >>with a cryptographic digest - perhaps reusing the XML
> >>signature manifest
> >>package.
>
>    [PM] I am broadly in agreement here, except that I would need to
>    get a better feeling for the details of this design.
>
>    One concern here, is that the assertion may be unnecessarily over
> identified
>    with the business payload. In my example below, the
> assertion obtained by
>    Ravi did not have any dependency on a specific payload. Instead, it
>    had a (proposed) dependency on Ravi's public key. It could
> therefore
>    be re-used by Ravi and packaged together with many
> different business
>    messages.
>
>
> >>
> >>Alternatively since the entire assertion is signed the
> >>Authorization could
> >>restate the purchase order as an advice element.
> >>
>
>    [PM] This approach would present difficulties in the general case
>    when the payload is something other than an XML fragment,
> for example,
>    a MIME package.
>
>
> - prateek
>
>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> >>> Sent: Sunday, May 06, 2001 9:38 PM
> >>> To: 'Philip Hallam-Baker '; ''oasis sstc' '
> >>> Cc: 'security-bindings@lists.oasis-open.org'
> >>> Subject: "binding" assertions to business payloads
> >>>
> >>>
> >>> One issue discussed in the bindings group con-call
> >>> this past week is that of providing an authentic binding between
> >>> assertions and business payloads. The following scenario
> >>> is driven off use-case 3 from the requirements document:
> >>>
> >>> End-user Ravi utilizes an authentication service
> >>> and obtains assertions ("Ravi is an employee of
> >>> Company X at the supervisor level")
> >>> which he packages with a business
> >>> payload ("Buy 100 paper clips") to create a composite package.
> >>> One way to ensure authenticity is to have Ravi sign the composite
> >>> package with his private key. When the recipient receives the
> >>> package, the recipient can check to see if the package has
> >>> been tampered with. If not, the recipient can scrutinize the
> >>> assertions and appropriately process the business payload.
> >>>
> >>> The concern here is with a MITM attack: attacker John intercepts
> >>> the package and packages the assertion with a completely
> >>> different payload ("Buy 1000 computers"), signs the composite
> >>> package and forwards it to the recipient.
> >>>
> >>> 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.
> >>>
> >>> It is not clear to me how this is handled
> >>> within the current assertion structure. Obviously,
> >>> this issue is fairly key to the bindings group; some
> >>> clarification is required in this space.
> >>>
> >>>
> >>> - prateek
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------
> >>> To unsubscribe from this elist send a message with the single word
> >>> "unsubscribe" in the body to:
> >>> security-services-request@lists.oasis-open.org
> >>>
> >>
> >>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> security-services-request@lists.oasis-open.org
>