[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