OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC