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: Issue 108: Potential attack when using RST parameters from a targetsite - WS-Trust part

Issue 108


From: Jan Alexander
Sent: Friday, August 25, 2006 9:19 AM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: New Issue: Potential attack when using RST parameters from a target site - WS-Trust part




The issues coordinators will notify the list when that has occurred.


Protocol:  ws-trust




Artifact:  spec / schema


Type: design


Title: Potential attack when using RST parameters from a target site



When requestor inserts parameters into an RST request which come from a third party – for example relying party policy – there is a potential for an attack. Currently both requestor RST parameters and third party RST parameters are mixed together as a direct children of the wst:RequestSecurityToken element. This prevents STS to differentiate the RST parameters based on their source. This means that both kinds of RST parameters are trusted in the same way by the STS. This can open a potential attack vector because the third party is given control over the content of the RST message that the requestor sends to the STS and the STS cannot detect which parameters came from which source in order to determine how much it should trust a particular RST parameter.


To mitigate the attack the RST should differentiate between parameters originated by the requestor and parameters not originated by the requestor.


Related issues:

Same issue; WS-SecurityPolicy part


Proposed Resolution:

We introduce a new parameter container within the RST which holds parameters not originated by the requestor in the section 3.1 of WS-Trust specification:



If specified, this optional element contains zero or more valid RST parameters (except wst:SecondaryParameter) for which the requestor is not the originator.


The STS processes parameters that are direct children of the wst:RequestSecurityToken element.  If a parameter is not specified as a direct child, the STS MAY look for the parameter within the wst:SecondaryParameters element (if present).  The STS MAY filter secondary parameters if it doesn't trust them or feels they are inappropriate or introduce risk (or based on its own policy).


Note that an alternate approach is to decorate RST parameters but this makes processing more complex because of potential instancing issues and may not be possible due to schema issues for RST extensions (requiring additional wrapper elements anyway). 



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