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

["Jan Alexander" <janalex@microsoft.com>]

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