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


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



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


Powered by eList eXpress LLC