Issue 108: Potential attack when using RST parameters from a targetsite - WS-Trust part

[Marc Goodner <mgoodner@microsoft.com>]

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

 

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. 

 

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

 

Protocol:  ws-trust

 

http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/17403/ws-trust-1.3-spec-ed-01-r08.pdf

 

Artifact:  spec / schema

 

Type: design

 

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

 

Description:

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:

 

/wst:RequestSecurityToken/wst:SecondaryParameters

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).