RE: "binding" assertions to business payloads

[Krishna Sankar <ksankar@cisco.com>]

Philip et al,

	I agree that Case (1) is a SAML application. But the e-mail said it is out
of scope which I disagreed. Thanks for clarification.

> > > Case (1) is out of scope since it is simply another purchase order.

	BTW, purchase order is just an example. So dismissing it as a purchase
order specific is not going to help. The point is, element level (or more
generally block level) assertions in business documents. As we all know,
currently there are no "assertions" in business documents, just attributes.
The assertion, in a very loose manner, is the whole document. Hopefully we
could evangelize the assertions concept at block level.

cheers

> -----Original Message-----
> From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Monday, May 07, 2001 9:52 AM
> To: 'Krishna Sankar'; Heather_Hinton@tivoli.com; Philip Hallam-Baker
> Cc: 'Mishra, Prateek'; Philip Hallam-Baker; ''oasis sstc' ';
> security-bindings@lists.oasis-open.org
> Subject: RE: "binding" assertions to business payloads
>
>
> If the application simply obtains a SAML assertion and on that basis
> re-issues the purchase order with a new sig it is simply a standard SAML
> application with no need to make special provision. The purchase order
> specific issues would be dealt with in the purchase order spec - i.e. 'out
> of SAML scope'.
>
> It would only be case 2 that would involve a significantly different
> application of SAML.
>
> Sorry if my phrasing was confusing.
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
>
>
> > -----Original Message-----
> > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > Sent: Monday, May 07, 2001 12:39 PM
> > To: Heather_Hinton@tivoli.com; Philip Hallam-Baker
> > Cc: 'Mishra, Prateek'; Philip Hallam-Baker; ''oasis sstc' ';
> > security-bindings@lists.oasis-open.org
> > Subject: RE: "binding" assertions to business payloads
> >
> >
> > Hi all,
> >
> > 	As far as I know, RosettaNet is silent on authorization.
> >
> > 	The RNO has the signature of the sender which *could*
> > aid case (2). But
> > usually the signature (and encryption) is for achieving the
> > security across
> > the wire and possibly for non-repudiation and *not* for authorization.
> >
> > 	Re Prateek's point, I would say Case (1) is more in
> > line with our charter.
> > We could help standards like RosettaNet to add this
> > capability to "normal"
> > purchase orders.
> >
> > cheers
> >
> > > -----Original Message-----
> > > From: Heather_Hinton@tivoli.com [mailto:Heather_Hinton@tivoli.com]
> > > Sent: Monday, May 07, 2001 9:19 AM
> > > To: Philip Hallam-Baker
> > > Cc: 'Mishra, Prateek'; Philip Hallam-Baker; ''oasis sstc' ';
> > > 'security-bindings@lists.oasis-open.org'
> > > Subject: RE: "binding" assertions to business payloads
> > >
> > >
> > > It occurs to me that the example given below is covered by
> > the RosettaNet
> > > standards. I will see if I can find anything there that is
> > of interest. In
> > > the meantime, check out www.rosettanet.org
> > >
> > > heather
> > >
> > > Heather Hinton,
> > > Senior Security Architect
> > > Tivoli SecureWay
> > > IBM Corporation
> > > hhinton@tivoli.com
> > > (tel) +1(512)436-1538
> > >
> > >
> > > Philip Hallam-Baker <pbaker@verisign.com> on 05/07/2001 10:11:31 AM
> > >
> > > To:   "'Mishra, Prateek'" <pmishra@netegrity.com>, Philip
> > Hallam-Baker
> > >       <pbaker@verisign.com>, "''oasis sstc' '"
> > >       <security-services@lists.oasis-open.org>
> > > cc:   "'security-bindings@lists.oasis-open.org'"
> > >       <security-bindings@lists.oasis-open.org>
> > > Subject:  RE: "binding" assertions to business payloads
> > >
> > >
> > >
> > >
> > > This type of 'Purchasing workflow' type application
> > involves pieces that
> > > are
> > > out of scope but is definitely important.
> > >
> > >
> > > The way I would see the workflow going is as follows
> > >
> > > Alice creates a purchase order
> > >
> > > <PO>
> > >    <Item>Paperclips
> > >    <Qty>1000
> > >    <Amount>1,992 USD
> > > <Signature>
> > >    <Alice>
> > >
> > >
> > > There are two ways that this PO could then be authorized
> > >
> > > 1) Query to see if Alice is Authorized to purchase 1000
> > paperclips at the
> > > stated price. This will by necessity involve some complex
> > policy/business
> > > logic.
> > >
> > > <SAML>
> > >    ...
> > >    <Claims>
> > >       <Subject>
> > >          [Alice...]
> > >       <Object>
> > >          <Resource>[Purchase up to $5000]
> > >    <Conditions>
> > >       [Online check she is not overspent]
> > >
> > > 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. 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.
> > >
> > > 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. The consistent means of specification
> > would be as a
> > > link
> > > with a cryptographic digest - perhaps reusing the XML
> > signature manifest
> > > package.
> > >
> > > Alternatively since the entire assertion is signed the
> > Authorization could
> > > restate the purchase order as an advice element.
> > >
> > >      Phill
> > >
> > >
> > >
> > > Phillip Hallam-Baker FBCS C.Eng.
> > > Principal Scientist
> > > VeriSign Inc.
> > > pbaker@verisign.com
> > > 781 245 6996 x227
> > >
> > >
> > > > -----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
> > > >
> > >
> > >
> > > (See attached file: Phillip Hallam-Baker (E-mail).vcf)
> > >
> >
>
>