Re: [ws-sx] Use-Case and Proposed Solution for i010 (long)

[Prateek Mishra <prateek.mishra@oracle.com>]

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