[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Use-Case and Proposed Solution for i010 (long)
Thanks, Jan, that works for me and provides the flexibility required to accomodate the use-case. I agree that with this addition we can close the issue. - prateek >[PM] Yes, thats reasonable. That was the main concern here. I do think >that some additional language is needed in section 9.1. How about adding >something like the following after 1718: > >The requestor MAY provide proof of possession of the key associated with >the OnBehalfOf identity by including a signature in the RST security >header. Additional signed supporting tokens describing the OnBehalfOf >context MAY also be included within the RST security header. >[\PM] > >I would modify the proposed text slightly: > >The requestor MAY provide proof of possession of the key associated with >the OnBehalfOf identity by including a signature in the RST security >header generated using the OnBehalfOf token that signs the primary >signature of the RST (i.e. endorsing supporting token concept from >WS-SecurityPolicy). Additional signed supporting tokens describing the >OnBehalfOf context MAY also be included within the RST security header. > >How does this sound to you? > >[PM] ><snip> > >It is a separate issue how the STS or any consumer is going to resolve >all of these identities and make its judgements. >But that problem isnt peculiar to the use-case; its a general problem >with the WSS 1.x specifications. >[\PM] > >Yes I agree that this is out of scope of WS-SX and WS-Trust in >particular. > >It seems to me that we are both in agreement that your scenario can be >done without changing the semantics of OnBehalfOf element, right? > >Are you OK to change issue 10 to add the proposed text into section 9.1 >after line 1718 and be done with it? > >Thanks, >--Jan > >-----Original Message----- >From: Prateek Mishra [mailto:prateek.mishra@oracle.com] >Sent: Monday, March 13, 2006 11:54 AM >To: ws-sx@lists.oasis-open.org >Cc: Jan Alexander; Darren Platt >Subject: Re: [ws-sx] Use-Case and Proposed Solution for i010 (long) > > > > >>After reading the document it seems to me that your scenario can be >> >> >done > > >>by using the current WS-Trust specification without requiring any >>changes. >> >> >> >> >> > >[PM] >OK, that would be great. My interest is in making sure that the use-case > >is accommodated, with or without changes to the spec. >[\PM] > > > >>Here is how I would do that using the current specs: >> >>I would use WS-SecurityPolicy endorsing supporting token concept >>(additional token inside the wsse:Security header that is used to sign >>the primary message signature); the endorsing token will represent the >>on-behalf-of party; this token will then be linked from within >>OnBehalfOf RST element using STR. >> >> >> >> >> >[PM] > >Making a little diagram here: > > SOAP< > Header< Intermediary token and signature1; Endorsing >token and signature2 over signature1> > Body<...OnBehalfOf(STR reference to endorsing token) >...> > > > >Right? > >Suppose we make this a little more explicit. Lets assume that the >OnBehalfOf identity is expressed by a X.509 certificate and an >associated private-public key pair. > >Then we have: > > SOAP< > Header<Intermediary token and signature1; BST(X.509) and >signature2 over signature1> > Body< ..OnBehalfOf(STR-Direct Reference to BST(X.509))..> > > >[\PM] > > > >>By using endorsing supporting token to represent on-behalf-of party, >> >> >the > > >>initiator proves the possession of the endorsing supporting token's key >>by signing the primary message signature with it. >> >> >> >> >> >[PM] Yes, thats reasonable. That was the main concern here. I do think >that some additional language is needed in section 9.1. How about >adding something like the following after 1718: > >The requestor MAY provide proof of possession of the key associated with > >the OnBehalfOf identity by >including a signature in the RST security header. Additional signed >supporting tokens describing the OnBehalfOf >context MAY also be included within the RST security header. > > >[\PM] > > > >>Because the endorsing signature is contained in message wsse:Security >>header, it is not necessary to extend the OnBehalfOf element to allow >>signatures in it. >> >>The advantage of this approach is that it uses existing concepts >> >> >defined > > >>by WS-SecurityPolicy to represent the on-behalf-of party; it does not >>define a new way to represent and authenticate it. >> >> >> >> >> >[PM] I agree this is a good idea. [\PM] > > > >>Regardless of this, I would push back on your proposal in section >> >> >3.2.2. > > >>in your document, because I have security concerns regarding this >>proposal. By signing only reference(s) to on-behalf-of tokens, you >> >> >don't > > >>bind those tokens and the signature to the message instance. Therefore >>an attacker can take those out and use them in different message and >> >> >the > > >>information in OnBehalfOf will still be valid. Please note that >>endorsing token approach does not have this weakness, since the >>endorsing signature signs the primary message signature, therefore it >>cannot be used with any other message. >> >> >> >[PM] This is a suggestion or a starting point only. I take your point >that it is vulnerable to certain threats as stated. [\PM] > > > >>It is not clear to me why are you proposing to allow multiple >>STRs/tokens inside OnBehalfOf element. Your scenario does not seem to >>require this and I cannot find any other which would require using >>multiple tokens to identify on-behalf-of party. Can you please help me >>understand why do you think this is necessary? >> >> >> > >[PM] > >If you look at the use-case document (flow 1a and 2), there are two >tokens that describe the application security context: a signed >supporting token describing the user and a HR signing token, together >with a signature. This captures the notion that the HrApp >is acting on behalf of Joe. > >I actually believe your solution would support this as well. Re-doing >the SOAP diagram we now have: > > SOAP< > Header<Intermediary token and signature1; >SupportingToken; BST(X.509) and signature2 over (signature1 and >Supporting Token)> > Body< ..OnBehalfOf(STR-Direct Reference to BST(X.509))..> > > > >Does that work for you? > >It is a separate issue how the STS or any consumer is going to resolve >all of these identities and make its judgements. >But that problem isnt peculiar to the use-case; its a general problem >with the WSS 1.x specifications. > >[\PM] > > >References: >*Use-Case and Proposed Solution for i010 <msg00108.html> >http://www.oasis-open.org/archives/ws-sx/200602/msg00108.html >* > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]