Issue 78 Rationale and New Proposal

["Hal Lockhart" <hlockhar@bea.com>]

Problems with the Use of Local References to ID Attributes in STRs which
annotate <CreateSeq> or other applications or infrastructure services.

Summary

The use of local ID references to bind a particular Token to a WS-RM
Sequence makes it difficult to design a cleanly layered implementation
of WS-RM with WS-Security (specifically WS-SecCon). The basic reason for
this is that the ID is message-specific, whereas the layers need to
continue to communicate and compare Token references over many messages.
The problem is relatively obvious on the sending side, but equally
problematic on the receiving side.

My Assumptions

Security and RM (and Applications) are implemented as distinct layers
with a clean interface between them. There are distinct implementations
of the sending and receiving components of each. Messages and associated
data (in an unspecified internal format) pass from one layer to the
next. The processing order on the send side is first Application, then
RM, then security. On the receiving side messages are processed first by
security.

The interface between RM and security on the send side is something like
this. The SOAP message is passed along with indications of what portions
of the message should be signed and encrypted with what tokens. 

The interface on the receive side is similar. Security replaces any
encrypted data with cleartext and passes along the message along with
indications of what was signed and what was encrypted using what tokens.
Security verifies signatures and checks for expirations, but the RM
layer must determine if the right things have been signed with the right
tokens.

The idea is that Applications and services such as RM know What to sign
(and encrypt) and Security knows How to sign.

Use of a local ID on send side

On the sending side, the problem with using a local ID is that since the
security header has not yet been constructed, the Application or RM
layer cannot determine what ID to use. Their are various kludged
solutions to this, like some sort of id naming convention, but these
kinds of approaches are likely to just cause unexpected bugs in existing
applications as messages get more complex with more services and
applications. 

Use of a local ID on the receive side

A local ID is just as much of a problem on the receive side. What the
RMD has to do is process the <CreateSeq> and save the reference so it
can later determine that all of the messages in the sequence have been
signed using the proper token. But if the STR contains a reference to a
local ID, the RMD has to dig thru all the tokens which were passed up by
the Security layer and determine (if it can) which one of them is being
pointed to. Then it has to create and save some kind of
message-independent reference to use later. How much easier if a
message-independent pointer is used in the first place!

Recommended Approach

In the case of an SCT, the simple solution is to use the
<wsc:Identifier> whenever the application or another infrastructure
service needs to reference it. This is supposed to be globally unique
and therefore will be the same in every message. Using it makes life
easy on both the send and receive side.

The RST & RSTR Problem

One objection raised to my proposal that references to an SCT from
outside of the <Security> Element MUST use the <wsc:Identifier> (and not
a wsu:Id) is that a RST may reference a Token that is in the Security
header. It is claimed that in this case it is easier to use a wsu:Id. I
don't really understand why this should be so, but let us examine the
cases.

First consider an RSTR. Since the Token is being sent from the STS for
use by the client, I can see no case in which the STS would use that
Token to identify itself or integrity protect the message. It is barely
possible that the Token might be used to encrypt parts of the message.
However, since the STS needs to establish an encryption key with the
client in order to protect secrets associated with the SCT, this case
seems marginal at best. (The discussion below about Perfect Forward
Secrecy also applies here.)

Now consider the RST. WS-SC defines 4 operations: Issue, Amend, Renew
and Cancel. Obviously an Issue request will never reference the SCT
since it does not exist yet. 

In the case of Amend, WS-SC does not specify what Authentication is
required. In the case of Renew, it says the original claims must be
re-authenticated. If the SCT has expired, its key must not be used to
authenticate. The examples for Amend and Renew both show signatures
which use both the long term Token and the SCT.

In the case of Cancel, WS-SC says that the client must provide PoP of
the SCT secret. The example shows only one signature, which uses the
SCT.

It seems to me that the Principle of Perfect Forward Secrecy suggests
that the long term Identity be used in all these cases to authenticate
the client. That way if the SCT secret is compromised, the request will
still be protected. (If the long term secret is compromised, all bets
are off anyway.) I don't understand why a Cancel requires specifically
PoP of the SCT secret.

The <IssuedTokens> Element

In section 4.4 of WS-Trust an element called IssuedTokens is defined.
This is intended to be a top level element in the SOAP header which
contains tokens referenced from different protocols, e.g. RST/RSTR and
WSS. It is not entirely sure what problem this element is supposed to
solve, but curiously WS-SC does not use it at all. I suggest that either
a) WS-SC specify that when tokens are referenced both in the Security
element and the RST, they be put in an IssuedTokens element or b) the
IssuedTokens element be dropped from WS-Trust.

Using wsc:Identifier vs. wsu:Id

It has been asserted that using a wsu:Id to reference an SCT is somehow
easier than using a wsc:Identifier. It has also been asserted that
referencing the same token in two different ways somehow causes
problems. I do not really understand either of these. First note that
the wsc:Identifier is required and thus if one wanted to use one
mechanism exclusively, it would be the better choice. Further, if the Id
is not present or conflicts with another Id in the message, it will need
to be added or changed. This is an extra step and in some scenarios
would break the issuer's signature.

The only reason I can think that using two different reference
mechanisms might cause a problem is in determining if two references are
to the same token or different ones. It seems to me that implementations
will have to be able to make this determination anyway. For example, the
same token might be labeled with different Id's in different messages.

Revised Proposal

Based on these considerations I propose replacing section 8 with:

-----
For a variety of reasons it may be necessary to reference a Security
Context Token. These references can be broken into two general
categories: references from within the <Security> element to a token
also within the <Security> element, generally used to indicate the key
used in a signature or encryption operation and references from other
parts of the SOAP envelope, for example to specify a token to be used in
some particular way. References within the <Security> element can
further be divided into reference to an SCT found within the message and
references to a SCT not present in the message.

The Security Context Token does not support references to it using key
identifiers or key names.  All references MUST either use an ID (to a
wsu:Id attribute) or a <wsse:Reference> to the <wsc:Identifier> element.

{Question: when the <wsc:Identifier> element value is used, is it
necessary to also specify the <wsc:Instance> element value, if present
to disambiguate the key?}

References using an ID are message-specific. References using the
<wsc:Identifier> element value are message independent.

If the SCT is referenced from within the <Security> element and from an
RST or RSTR, the SCT MUST be placed in a <IssuedTokens> element at the
top level in the SOAP Header. The <IssuedTokens> element SHOULD appear
prior to the <Security> element. It is RECOMMENDED that these references
be message independent, but these references MAY be message-specific.

When an SCT located in the <Security> element is referenced from outside
the <Security> element, a message independent referencing mechanisms
MUST be used, to enable a cleanly layered processing model.

When an SCT is referenced from within the <Security> element, but the
SCT is not present in the message, (presumably because it was
transmitted in a previous message) a message independent referencing
mechanism MUST be used.

When an SCT located in the <Security> element is referenced from within
the <Security> element, a message-specific referencing mechanism MAY be
used.


[examples]
----

Note the second paragraph is copied from lines 144-146. I suggest
deleting these.

----

I also have suggested that the rules for Authentication of Amend, Renew
and Cancel requests be changed. I will open a new Issue for these
changes.

Hal