Issue 12: Encoded wresult

Issue 12

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Wednesday, October 10, 2007 1:53 PM
To: wsfed@lists.oasis-open.org
Subject: [wsfed] New Issue: Encoded wresult

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.

Title: Encoded wresult

Protocol: wsfed

Artifact: spec

Type: design

Description:

There are two reasons why the next version of WS-Federation should support an optional requestor-advertised wresult encoding scheme.

1. The current encoding is inefficient

Transmitting the RSTR “unencoded” in effect institutes two different encodings:

· First, the RST must be encoded for inclusion in an HTML attribute in the HTML form. This results in every quotation mark expanding to the HTML entity ", which for those of you keeping count expands one character to six. There are generally a lot of quotes in an XML document like a SAML token.

· Typically, the client will process the HTML form into a urlencoded HTTP POST. This process requires that many of the XML-related characters in the RSTR (including <, :, >, =, ") be expanded to three characters each (%3c, %3a, %3e, %3d, %22). XML is filled with such characters.

An XML document is likely to incur greater overhead due to this expansion than required by a simple Base64 transform (which has 1/3 overhead). The base64 would still be subject urlencoding for the HTTP POST, but only one common character (+) would require escaping (=, also requiring escaping, is only used for trailing padding).

If desired, we could take this further and also allow the use of the deflate algorithm on the octet stream before base64-encoding, which would both reduce the overall size and result in a more efficient base64-encoding (since the octets of the raw XML document are likely to use only 7 bits).

2. The current encoding may look like an XSS attack

Simple XSS detection mechanisms look for HTML-like data originating from form posts or URL parameters. Because WS-Federation calls for no other encoding scheme for the XML, simple XSS detectors are likely to detect WS-Federation wresult parameters as potential attacks. It would be unconscionable to create a security protocol that undermined relying party web developers attempts to protect their site form cross-site scripting.

There are widely deployed web platforms that by default employ such a cross-site scripting detector. With the current encoding scheme any website running on these platforms wishing to act as a WS-Federation relying party must disable cross-site scripting detection. This seems bad.

Proposal:

In outline we should address this as follows.

This should be additive to the current passive requestor section, it must not break existing implementations.

Define an appropriate encoding, suggest Base64.

Define an optional encoding parameter for use by the requestor to indicate the encoding in use, default should be current behavior (unencoded).

Define a nested assertion to the passive binding to indicate the encoding.

Define a fault for encoding not supported.

wsfed message