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

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

I am assuming that the application or other layer such as WS-RM can make
a request to obtain the STR value corresponding to some sort of use. For
example, "an identity to protect a sequence" "an identity to protect
application data." In the case of a SCT, I assume there is same way to
cause the security layer to do the handshake to create a secure
conversation and hand back a value which will be the reference to the
SCT.

Hal

> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
> Sent: Thursday, August 03, 2006 3:14 PM
> To: Hal Lockhart
> Cc: ws-sx@lists.oasis-open.org
> Subject: Re: [ws-sx] Issue 78 Rationale and New Proposal
> 
> Hal,
> 
> Before getting into a broader discussion of your proposal and the
> embedded STR approach as a whole, here is a simple question:
> Where is the information about the distinguished security token to be
> used to secure the subsequent message exchange found?
> 
> Is it in the security layer or the application layer? In other words,
> how does the application (or RM layer in your note below)
> know which security  token to embed as an STR within the message?
> 
> Your text below implies that the application (includes RM) layer has
> knowledge of security tokens appropriate for different destinations
> (EPRs I guess). Was that your intent? Or is there some assumption
about
> the availability of this information
> from the security layer ("I need to send a message to EPR foo, please
> provide me with an appropriate STR").
> 
> - prateek
> 
> >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
> >
> >
> >
>