RE: [ws-sx] Issue 78 Rationale and New Proposal

[Martin Gudgin <mgudgin@microsoft.com>]

Hal,

Please find below an amended proposal for replacement text for section 8 (actually prepared by Jan, but he's on vacation this week).

Regards

Gudge

-------------

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.

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 or from an RST or RSTR, 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 unless there is a prior agreement between the involved parties to use message-specific referencing mechanism.

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.

----------------

> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: 27 July 2006 17:43
> To: ws-sx@lists.oasis-open.org
> Subject: [ws-sx] Issue 78 Rationale and New Proposal
>
> 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
>