RE: "binding" assertions to business payloads

[Philip Hallam-Baker <pbaker@verisign.com>]

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

Phillip Hallam-Baker (E-mail).vcf