OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


Subject: Re: [ws-sx] Encryption with a key known to both parties


Hi Ruchith,

Let me take a crack at this referencing the WS-SecurityPolicy Examples
document that is currently under review in the ws-sx TC:

    
http://www.oasis-open.org/committees/download.php/26176/ws-sp-usecases-examples-draft-17-07.doc

In section 2.2.2 of that documented is a use case called "(WSS1.0) Mutual
Authentication with X.509 Certificates, Sign, Encrypt", which I think fairly
closely matches the use case you are referring to, with one exception, that
I will try to explain.

First of all the use case #4 from the interop doc you ref should be 
considered
an "AsymmetricBinding" because the protection is primarily from the 
initiator
and recipient X.509 certificates which are used to sign the Body in both the
request and response. In addition, the example 2.2.2 shows that the 
initiator
should include the X.509 cert (line 1373 (P008)), but the recipient 
should not
(line 1383 (P017)), which also matches the interop use case #4.

Use case 2.2.2 also in its input and output policies (lines 1415 (P047) -
1439 (P070)) matches the use case #4 by requiring the Body to be
encrypted (lines 1422(P054), 1435(P066)).

The only thing that is not explicitly covered is that there is an out of 
band
mutually agreed upon session key (<xenc:KeyName>SessionKey</xenc:Keyname>)
in the use case #4.

Because this is a non-standard key and reference mechanism there is
no WS-SP Token Type to refer to it. However, one might consider
it an "IssuedToken" where the "Issuer" is whatever mutually agreed
upon entity produced this token. In this case you might consider
adding a SupportingTokens element to the Policy after the
end of the AsymmetricBinding element between lines 1399(P038)
and 1400 (P039) such as:

 <sp:SupportingTokens>
    <wsp:Policy>
       <sp:IssuedToken>
          <sp:Issuer>SomeMutuallyAgreedURL</sp:Issuer>
          <sp:RequireExternalReference/>
       </sp:IssuedToken>
       <sp:EncryptedParts>
          <sp:Body/>
       </sp:EncryptedParts>
    </wsp:Policy>
  </sp:SupportingTokens>

I believe the RequireExternalReference can be taken to mean
that the token used to encrypt the Body is going to be identified
by some reference mechanism (the mutually agreed on key name).
In the above example the Issuer element would be primarily used
so that both parties understand the context to interpret the
external reference.

Hopefully this is helpful.

    Thanks,
    Rich Levinson



Ruchith Fernando wrote:
> Hi Folks,
>
> Is it possible to express "Scenario #4 Session Key" (the client and the
> service uses a random symmetric key that has been previously agreed)
> described in this [1] document with WS-SecurityPolicy?
>
> I guess we should use SymmetricBinding but how can we express the
> Protection/EncryptionToken?
>
> Thanks,
> Ruchith
>
> 1.
> http://svn.apache.org/repos/asf/webservices/wss4j/trunk/specs/wss-interop2-draft-06.pdf
>
>   


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