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: 

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